- Forum
- UNIX/Linux Programming
- Gcc looking for lib dl in the wrong dire
Gcc looking for lib dl in the wrong directory during 32bit configure execution.
Hello. I am currently trying to do a 32bit build of Mesa and a Wine build (that requires a lot of 32bit stuff)
And in both I faced these error messages when configure arrived at the X support testes:
For me it seems that it is not finding the correct (32bit) lib dl. And that makes perfect sense, since I installed the 32bit libc in /media/34GB/Glibc. So I proceeded to do what I did before when other 32bit so files from glibc where required: To create a sym link for them from their install dir to the /usr/lib32 dir that I created to solve this kind of situation.
Except that it did not work. For Mesa, I was able to circumvent the issue by also using PKG_CONFIG_PATH (instead of just using CPPFLAGS and LDFLAGS to point to X11 include and lib dirs) and passing the .pc file for it (and all the required pc files that x11.pc and x11-xcb.pc requires). Unfortunately wine does not uses PKG_CONFIG_PATH for X11 library detection, so this trick won't work here.
It seemed a matter of looking for in the wrong place (/usr/lib instead /usr/lib32)
On another lib dl issue, this only related to Mesa install, the tests for libdl fail:
Interestingly, the second test complains of exactly of what mentioned before, looking for the libraries in the wrong dir:
I was able to circumvent this one by creating a sym link to libdl.so in /usr/lib32. However the checking for dlopen keeps happening. config.log says:
This is not an ending error, but I am afraid it could cause problems in the correct working of Mesa libraries by other applications in the future.
So I have two errors related to lib dl, both that appeared to be related with the search for it happening in the wrong dirs. However, the error messages are different than the ones I expected, the ones that showed up in the test for dlopen and that I was able to fix by just creating a sym link from libdl dir to /usr/lib32.
So I am unsure about the reasons and open to any suggestions to fix the issue
And in both I faced these error messages when configure arrived at the X support testes:
|
|
For me it seems that it is not finding the correct (32bit) lib dl. And that makes perfect sense, since I installed the 32bit libc in /media/34GB/Glibc. So I proceeded to do what I did before when other 32bit so files from glibc where required: To create a sym link for them from their install dir to the /usr/lib32 dir that I created to solve this kind of situation.
Except that it did not work. For Mesa, I was able to circumvent the issue by also using PKG_CONFIG_PATH (instead of just using CPPFLAGS and LDFLAGS to point to X11 include and lib dirs) and passing the .pc file for it (and all the required pc files that x11.pc and x11-xcb.pc requires). Unfortunately wine does not uses PKG_CONFIG_PATH for X11 library detection, so this trick won't work here.
It seemed a matter of looking for in the wrong place (/usr/lib instead /usr/lib32)
On another lib dl issue, this only related to Mesa install, the tests for libdl fail:
|
|
Interestingly, the second test complains of exactly of what mentioned before, looking for the libraries in the wrong dir:
|
|
I was able to circumvent this one by creating a sym link to libdl.so in /usr/lib32. However the checking for dlopen keeps happening. config.log says:
|
|
This is not an ending error, but I am afraid it could cause problems in the correct working of Mesa libraries by other applications in the future.
So I have two errors related to lib dl, both that appeared to be related with the search for it happening in the wrong dirs. However, the error messages are different than the ones I expected, the ones that showed up in the test for dlopen and that I was able to fix by just creating a sym link from libdl dir to /usr/lib32.
So I am unsure about the reasons and open to any suggestions to fix the issue
Last edited on
You can set the library path: -L<path> -l<lib>
Typically you'd set that with variable LDFLAGS, however, LDFLAGS is not included at the end (as it should be), so some have taken to using LDADD, and adding that to the end of the rule. This is necessary because the gnu linker is a one pass linker, requiring libs to be specified in dependency order.
EDIT: BTW, libdl is a Linux specific problem as most Unix libs include it on libc. But it's not really C, it's POSIX, so I guess that's why it was split off. But there was a time when there was no difference between what was C and what was Unix.
Typically you'd set that with variable LDFLAGS, however, LDFLAGS is not included at the end (as it should be), so some have taken to using LDADD, and adding that to the end of the rule. This is necessary because the gnu linker is a one pass linker, requiring libs to be specified in dependency order.
EDIT: BTW, libdl is a Linux specific problem as most Unix libs include it on libc. But it's not really C, it's POSIX, so I guess that's why it was split off. But there was a time when there was no difference between what was C and what was Unix.
Last edited on
Hi. After reading what you wrote, I started to try to pass both the libdl's directory and itself with
and it returned
I then tried to move the -ld after the configure, and then I received:
CPPFLAGS="-I/media/34GB/Arquivos-de-Programas-Linux-32bit/xorg/X11-1.4.4/include/ -I/media/34GB/Arquivos-de-Programas-Linux/xorg//Xorgproto-2018.1/include/" LDFLAGS="-L/media/34GB/Arquivos-de-Programas-Linux-32bit/xorg//X11-1.4.4/lib/ -L/usr/lib32/" -ldl ./configureand it returned
-ldl: command not founI then tried to move the -ld after the configure, and then I received:
configure: error: unrecognized option: `-ldl'
-dl should be in LDFLAGS, you left it out. It should be:
CPPFLAGS="-I/media/34GB/Arquivos-de-Programas-Linux-32bit/xorg/X11-1.4.4/include/ -I/media/34GB/Arquivos-de-Programas-Linux/xorg/Xorgproto-2018.1/include/" LDFLAGS="-L/media/34GB/Arquivos-de-Programas-Linux-32bit/xorg/X11-1.4.4/lib/ -L/usr/lib32/ -ldl" ./configure
Last edited on
Topic archived. No new replies allowed.