[MDEV-17104] redefinitions of struct DL_info from /usr/include/dlfcn.h in include/my_global.h Created: 2018-08-31  Updated: 2023-01-22  Resolved: 2023-01-22

Status: Closed
Project: MariaDB Server
Component/s: Compiling
Affects Version/s: 10.3.9, 10.4, 10.5, 10.6, 10.7, 10.8, 10.9, 10.10, 10.11
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Noel Kuntze Assignee: Sergei Golubchik
Resolution: Incomplete Votes: 0
Labels: None
Environment:

Arch Linux, gcc8


 Description   

The struct DL_info is already defined in /usr/include/dlfcn.h, but then redefined in the mariadb source's /include/my_global.h file. This causes compilation to abort due to fatal errors.

One gets lots of these:

In file included from /tmp/thermi-makepkg/mariadb/src/mariadb-10.3.9/strings/strings_def.h:21,                               
                 from /tmp/thermi-makepkg/mariadb/src/mariadb-10.3.9/strings/ctype-euc_kr.c:29:                              
/tmp/thermi-makepkg/mariadb/src/mariadb-10.3.9/include/my_global.h:1092:54: error: conflicting types for 'Dl_info'
 
 typedef struct { const char *dli_fname, dli_fbase; } Dl_info;                                   
                                                      ^~~~~~~                                                                
In file included from /tmp/thermi-makepkg/mariadb/src/mariadb-10.3.9/include/my_global.h:1082,                               
                 from /tmp/thermi-makepkg/mariadb/src/mariadb-10.3.9/strings/strings_def.h:21,                               
                 from /tmp/thermi-makepkg/mariadb/src/mariadb-10.3.9/strings/ctype-euc_kr.c:29:                               
/usr/include/dlfcn.h:94:3: note: previous declaration of 'Dl_info' was here                                     
 } Dl_info;                                                                                                            
   ^~~~~~~



 Comments   
Comment by Elena Stepanova [ 2018-09-02 ]

I assume all major versions are affected, since the definition exists everywhere, but I didn't try to compile anything on arch linux. so I'm keeping the affected version as initially reported.

Comment by Veevay Gahoka [ 2022-11-27 ]

I immediately encountered this issue, when I tried to compile MariaDB 10.11. How do you guys compile if it is not fixed? What is the secret sauce?

Comment by Sergei Golubchik [ 2022-11-27 ]

No secret source, everything is public. You can go to buildbot.mariadb.org, click on any build, and see how exactly that build was compiled.

Now, if it fails for you, you must be doing something differently. What is the complete cmake line that you've used?

Comment by Veevay Gahoka [ 2022-11-27 ]

> click on any build, and see how exactly that build was compiled

Why do you think it is easy to find the invocation line for cmake there? I am probably stupid, I couldn't.

> you must be doing something differently

Yeah, that's why I am asking about your secret sauce.

> What is the complete cmake line that you've used?

    cmake -LA -Wno-dev -G Ninja \
 
        -DCMAKE_CXX_FLAGS="-march=native -mtune=native" \
 
        -DCMAKE_C_FLAGS="-march=native -mtune=native" \
 
        -DCMAKE_BUILD_TYPE=Release \
 
        -DCMAKE_INSTALL_PREFIX=${GCC_PREFIX} \
 
        -DCMAKE_CXX_COMPILER=g++ \
 
        -DCMAKE_C_COMPILER=gcc \
 
        -DWITH_EMBEDDED_SERVER=ON \
 
        ../mariadb

Comment by Veevay Gahoka [ 2022-11-27 ]

Whatever, never mind, I found out what one has to do to compile MariaDB. One has to pass "DHAVE_DLOPEN=ON -DHAVE_DLADDR=ON" to cmake. However, redifinition of DL_info is a clear bug.

Comment by Sergei Golubchik [ 2022-11-27 ]

Why do you think it is easy to find the invocation line for cmake there? I am probably stupid, I couldn't.

because I was doing it for so long that I no longer remember how it feels to see that interface for the first time. Sorry.
One way of doing it would be to click on Grid View or Builds > Builders. Then click on any build, for example, 3728, and then stdio from the Compile step shows the command that was used:

sh -c 'cmake . -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_C_COMPILER_LAUNCHER=ccache -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER_LAUNCHER=ccache -DCMAKE_CXX_COMPILER=g++ -DPLUGIN_TOKUDB=NO -DPLUGIN_MROONGA=NO -DPLUGIN_SPIDER=NO -DPLUGIN_OQGRAPH=NO -DPLUGIN_PERFSCHEMA=YES -DPLUGIN_SPHINX=NO  && make -j7 package'

it's apparently a small build, disabling many plugins. There are others that don't do that.

One has to pass "DHAVE_DLOPEN=ON -DHAVE_DLADDR=ON" to cmake

No, one doesn't have to. cmake is supposed to detect that automatically. You can force the result of the dlopen/dladdr check manually, as you said above, but you should never need to do that.

I've just run cmake using your exact command line and both dlopen and dladdr were found correctly. There must be something else to it.

Check your CMakeFiles/CMakeError.log file, it might contain clues. Or attach it to the issue and we'll look at it.

Comment by Veevay Gahoka [ 2022-11-28 ]

Thank you for the feedback. It sounds like it might be a CMake bug. I'll investigate and report.

Generated at Thu Feb 08 08:33:56 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.