libdl seems not linked when using ulibc ARM stage3

[destroyedlolo]

Hello,

I'm installing Gentoo on a AllWinner A13 powered tablet.

I did 2 images, both containing the same packages. One using the standard "glibc" stage3-armv7a_hardfp image, another one using stage3-armv7a_hardfp-uclibc-vanilla.

I don't have any trouble with glibc one, but some packages are falling to build on uLibc one, because it seems dl library is not linked by default.

As example, Lua is falling with following error :

Code: Select all

libtool --quiet --tag=CC --mode=link armv7a-hardfloat-linux-uclibceabi-gcc -export-dynamic -Wl,-O1 -Wl,--as-needed -o lua lua.lo liblua.la -lreadline
libtool --quiet --tag=CC --mode=link armv7a-hardfloat-linux-uclibceabi-gcc -static -export-dynamic -Wl,-O1 -Wl,--as-needed -o lua_test lua.lo liblua.la -lreadline
./.libs/liblua.so: undefined reference to `dlerror'
./.libs/liblua.so: undefined reference to `dlclose'
./.libs/liblua.so: undefined reference to `dlopen'
./.libs/liblua.so: undefined reference to `dlsym'
collect2: error: ld returned 1 exit status
Makefile:201: recipe for target 'lua' failed

Why this difference, and what is the correct way to correct this issue ?

Thanks

Laurent

[steveL]

I don't have any trouble with glibc one, but some packages are falling to build on uLibc one, because it seems dl library is not linked by default.

If your analysis is correct, then this is a bug in the upstream (build-system for the) software; though it can be worked-round by adding -ldl to LDFLAGS in the ebuild.
In general, what flag to use would be checked-for by the configure script, usually autoconf-generated.

Code: Select all

<mira> µClibc can do libdl, not sure whether -ldl is required.

Your example, lua, has a very simple build-system, afair.

For a quick workaround, you would [post=513780]use package.env[/post] to add the value to LDFLAGS for whichever packages required it; then you would be in a position to report a bug for those, stating that adding -ldl to LDFLAGS fixes the issue at your end, so the maintainer can look at the specific build-system and feed a minor patch upstream.

So check if adding -ldl to LDFLAGS for lua works first:
/etc/portage/env/ldl.conf

Code: Select all

LDFLAGS="$LDFLAGS -ldl"

/etc/portage/package.env

Code: Select all

dev-lang/lua  ldl.conf

HTH,
steveL

[destroyedlolo]

Hello,

I solved the issue by adding -ldl directly in make.conf

If your analysis is correct, then this is a bug in the upstream (build-system for the) software; though it can be worked-round by adding -ldl to LDFLAGS in the ebuild.
In general, what flag to use would be checked-for by the configure script, usually autoconf-generated.

In this case, why it's working when I'm not using ulibc environment ?

Bye

Laurent

[steveL]

If your analysis is correct, then this is a bug in the upstream (build-system for the) software; though it can be worked-round by adding -ldl to LDFLAGS in the ebuild.

I solved the issue by adding -ldl directly in make.conf

Cool.

In general, what flag to use would be checked-for by the configure script, usually autoconf-generated.

In this case, why it's working when I'm not using ulibc environment ?

Because it is not always needed, depending on the platform, which may not support dlsym at all; ergo it gets sorted out in configure.ac.

POSIX does not mandate -ldl, so strictly speaking it should not be required on a POSIX-compliant system. cf: man c99
So glibc provides it in libc, which is always searched, but may be specified early.

Nonetheless, that is precisely the role of a configure script: to establish what is supported, and whether eg: -ldl needs to be added, or not, or its functionality is unsupported.

[destroyedlolo]

Ok, thanks for your explanation.

Next time I'll update my tablet, I'll note failing packages and open ticket for them.

Bye

Laurent

[steveL]

Ok, thanks for your explanation.

Next time I'll update my tablet, I'll note failing packages and open ticket for them.

You're welcome :-)

That's all anyone could ask, so thanks.