Thanks for the answers. There is some relevant info there, like
ldconfig to ignore symbolic links when scanning for libraries
Well, I am already facing problems, possibly caused by this dl issue.
When configuring wine, it tests for lib freetype, and it does not find
it, being irrelevant that I am passing the relevant dir to it:
"configure:10110: gcc -m32 -o conftest -g -O2
-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
/ -L/media/34GB/Arquivos-de-Programas-Linux-32bit/xorg/X11-1.4.4/lib/
-L/media/34GB/Arquivos-de-Programas-Linux-32bit/Freetype-2.2.1/lib/
-L/usr/lib32 -ldl conftest.c -lfreetype -lfreetype >&5
configure:10110: $? = 0
configure:10122: result: not found
configure:10221: error: FreeType 32-bit development files not found.
Fonts will not be built.
Use the --without-freetype option if you really want this"
As I am passing its directory, it seems the likely reason is that
Freetype was built without dlopen support ?
When I call ldd on libfreetype.so or any 32bit so library that I built
them, ldd reports them as static.
So what can I do? Perhaps to rebuild all of them, but before that, to
copy all the relevant 32bit Glibc files to /usr/lib32, adding it to
ld.conf.so and then calling ldconfig prior to start to rebuild them?
12.10.2021, 10:08, "Bob Friesenhahn" <bfriesen@xxxxxxxxxxxxxxxxxxx>:
On Mon, 11 Oct 2021, alexandre schenberg wrote:
which made sense, as I had not yet made a symbolic link to libdl
on
/usr/lib32. Then I just did it. Yet, this error message continued
to
appear. What changed was this detection test: "checking for
dlopen in
-ldl..." that went from "no" to "yes", notwithstanding that
"checking
for dlopen." continued to return no.
Following suggestion on a message board, I was able to circumvent
these
"skipping incompatible" error messages by adding a "-L/usr/lib32/
-ldl" to the end of wine's configure parameter list.
Adding -L/usr/lib32/ was likely the correct thing to do.
So what was left from these messages on wine, mesa and alsa was
the:
"checking for dlopen... no". It did not stop me to build Alsa. I
don't
know about mesa and wine, since I still have many other tests to
deal
it before I can try to compile them. What I am afraid of, is that
this
can make a software to refuse to run for not finding the 32bit
library
that it requires (like wine not finding a .so alsa library)
If the software does not use dlopen, then support for dynamic
modules
or dynamically loading libraries may be missing from it. Depending
on
the software, this might severely diminish its functionality.
Does this fear have any basis or am I looking for trouble without
need?
Can I safely ignore this libdl check?
I also would like to understand the reason behind the "skipping
incompatible" error messages. It seems it was looking for libdl
on
/usr/lib64/ instead /usr/lib32. If so, why? I understand that
/usr/lib32 did not exist when the system was installed, but
looking for
a 32bit library on a 64bit dir just does not compute.
I suggest reading the documentation for 'ldconfig' and 'ld.so'.
The "skipping incompatible" message is really a warning but it
becomes
significant if the 32-bit library is not found.
Major x86-64 Linux distributions appear to be in the process of
removing 32-bit support. Be aware that if you get 32-bit support
working today on your Linux distribution that it might not work in
the
next major release cycle.
Bob
--
Bob Friesenhahn
[1]bfriesen@xxxxxxxxxxxxxxxxxxx,
[2]http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, [3]http://www.GraphicsMagick.org/
Public Key,
[4]http://www.simplesystems.org/users/bfriesen/public-key.txt
References
1. mailto:bfriesen@xxxxxxxxxxxxxxxxxxx
2. http://www.simplesystems.org/users/bfriesen/
3. http://www.graphicsmagick.org/
4. http://www.simplesystems.org/users/bfriesen/public-key.txt
