[Buildroot] pppd breaks build without libutils

[Buildroot] pppd breaks build without libutils

[Cassiano Martin]

Hello,

I am generating a small firmware environment, and pppd breaks build process
if libutils is not included. I looked under its sources and its used to
wtmp logging.

diff -rupN pppd.b/pppd.mk pppd/pppd.mk
--- pppd.b/pppd.mk      2016-09-25 13:51:06.125430110 -0300
+++ pppd/pppd.mk        2016-09-19 13:48:11.223130150 -0300
@@ -45,6 +45,7 @@ PPPD_POST_EXTRACT_HOOKS += PPPD_SET_RESO

 define PPPD_CONFIGURE_CMDS
        $(SED) 's/FILTER=y/#FILTER=y/' $(PPPD_DIR)/pppd/Makefile.linux
+       $(SED) 's/USE_LIBUTIL=y/#USE_LIBUTIL=y/'
$(PPPD_DIR)/pppd/Makefile.linux
        $(SED) 's/ifneq ($$(wildcard \/usr\/include\/pcap-bpf.h),)/ifdef
FILTER/' $(PPPD_DIR)/*/Makefile.linux
        ( cd $(@D); ./configure --prefix=/usr )
 endef

[]'s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20160925/cf6fad79/attachment.html>

[Buildroot] pppd breaks build without libutils

[Thomas Petazzoni]

Hello,

On Sun, 25 Sep 2016 13:53:05 -0300, Cassiano Martin wrote:

> I am generating a small firmware environment, and pppd breaks build process
> if libutils is not included. I looked under its sources and its used to
> wtmp logging.

Thanks for this report. Could you be more specific in terms of the
Buildroot version that you're using, and the Buildroot configuration?
What exact build issue are you facing (i.e can you copy/paste the error
messages) ?

Indeed, we have autobuilders that test random configurations, and pppd
is built many times, and we haven't seen such an issue so far I believe.

Thanks a lot!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] pppd breaks build without libutils

[Cassiano Martin]

Sure, my fault not being version specific.
Im currently running a git cloned version (Buildroot
2016.08-git-01556-ge8c18f2-dirty)
and I'm using a pre-built toolchain from realtek. Target is MIPS32 bit LSB.
So far, I get this when compiling.

ude '-DDESTDIR="/usr"' -DCHAPMS=1 -DMPPE=1 -DHAS_SHADOW -DHAVE_CRYPT_H=1
-DHAVE_LOGWTMP=1 -DUSE_CRYPT=1 -DHAVE_MULTILINK -DUSE_TDB=1 -DPLUGIN
-DINET6=1 -DMAXOCTETS -Wl,-E -o pppd main.o magic.o fsm.o lcp.o ipcp.o
upap.o chap-new.o md5.o ccp.o ecp.o auth.o options.o demand.o utils.o
sys-linux.o ipxcp.o tty.o eap.o chap-md5.o session.o md4.o chap_ms.o sha1.o
pppcrypt.o multilink.o tdb.o spinlock.o ipv6cp.o eui64.o  -lcrypt -lutil
-ldl
/home/cassiano/projects/oiw-2441apgn/realtek/rsdk-4.6.4-4181-EB-3.10-u0.9.33-m32-150324/bin/../lib/gcc/mips-linux-uclibc/4.6.4/../../../../mips-linux-uclibc/bin/ld:
cannot find -lutil
collect2: ld returned 1 exit status
Makefile:217: recipe for target 'pppd' failed
make[2]: *** [pppd] Error 1
make[2]: Leaving directory
'/home/cassiano/projects/oiw-2441apgn/output/build/pppd-2.4.7/pppd'
Makefile:13: recipe for target 'all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory
'/home/cassiano/projects/oiw-2441apgn/output/build/pppd-2.4.7'
package/pkg-generic.mk:201: recipe for target
'/home/cassiano/projects/oiw-2441apgn/output/build/pppd-2.4.7/.stamp_built'
failed


2016-09-25 15:58 GMT-03:00 Thomas Petazzoni <
thomas.petazzoni@free-electrons.com>:

> Hello,
>
> On Sun, 25 Sep 2016 13:53:05 -0300, Cassiano Martin wrote:
>
> > I am generating a small firmware environment, and pppd breaks build
> process
> > if libutils is not included. I looked under its sources and its used to
> > wtmp logging.
>
> Thanks for this report. Could you be more specific in terms of the
> Buildroot version that you're using, and the Buildroot configuration?
> What exact build issue are you facing (i.e can you copy/paste the error
> messages) ?
>
> Indeed, we have autobuilders that test random configurations, and pppd
> is built many times, and we haven't seen such an issue so far I believe.
>
> Thanks a lot!
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20160925/c1b6f38b/attachment.html>

[Buildroot] pppd breaks build without libutils

[Arnout Vandecappelle]

On 26-09-16 01:39, Cassiano Martin wrote:
> Sure, my fault not being version specific. 
> Im currently running a git cloned version (Buildroot
> 2016.08-git-01556-ge8c18f2-dirty)
> and I'm using a pre-built toolchain from realtek. Target is MIPS32 bit LSB. 
> So far, I get this when compiling.
> 
> ude '-DDESTDIR="/usr"' -DCHAPMS=1 -DMPPE=1 -DHAS_SHADOW -DHAVE_CRYPT_H=1
> -DHAVE_LOGWTMP=1 -DUSE_CRYPT=1 -DHAVE_MULTILINK -DUSE_TDB=1 -DPLUGIN -DINET6=1
> -DMAXOCTETS -Wl,-E -o pppd main.o magic.o fsm.o lcp.o ipcp.o upap.o chap-new.o
> md5.o ccp.o ecp.o auth.o options.o demand.o utils.o sys-linux.o ipxcp.o tty.o
> eap.o chap-md5.o session.o md4.o chap_ms.o sha1.o pppcrypt.o multilink.o tdb.o
> spinlock.o ipv6cp.o eui64.o  -lcrypt -lutil -ldl
> /home/cassiano/projects/oiw-2441apgn/realtek/rsdk-4.6.4-4181-EB-3.10-u0.9.33-m32-150324/bin/../lib/gcc/mips-linux-uclibc/4.6.4/../../../../mips-linux-uclibc/bin/ld:
> cannot find -lutil

 Looks like the Realtek toolchain is not compatible with Buildroot assumptions.
libutil is part of the toolchain. I guess Realtek configures uClibc without
UCLIBC_HAS_LIBUTIL.

 Buildroot cannot support all possible uClibc configurations for all packages.
Instead, we take minimal assumptions about the uClibc configuration - basically
package/uclibc/uClibc-ng.config. If you have something less than that, then some
packages may fail.

 The workaround you propose is basically disabling wtmp support. It's not really
acceptable to do that for 95% of the users who actually do have this in their
toolchain.

 We should probably add a FAQ entry for this kind of issue.

 Regards,
 Arnout

> collect2: ld returned 1 exit status
> Makefile:217: recipe for target 'pppd' failed
> make[2]: *** [pppd] Error 1
> make[2]: Leaving directory
> '/home/cassiano/projects/oiw-2441apgn/output/build/pppd-2.4.7/pppd'
> Makefile:13: recipe for target 'all' failed
> make[1]: *** [all] Error 2
> make[1]: Leaving directory
> '/home/cassiano/projects/oiw-2441apgn/output/build/pppd-2.4.7'
> package/pkg-generic.mk:201 <http://pkg-generic.mk:201>: recipe for target
> '/home/cassiano/projects/oiw-2441apgn/output/build/pppd-2.4.7/.stamp_built' failed
> 
> 

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] pppd breaks build without libutils

[Yann E. MORIN]

Arnout, All,

On 2016-09-27 23:33 +0200, Arnout Vandecappelle spake thusly:
> On 26-09-16 01:39, Cassiano Martin wrote:
> > Sure, my fault not being version specific. 
> > Im currently running a git cloned version (Buildroot
> > 2016.08-git-01556-ge8c18f2-dirty)
> > and I'm using a pre-built toolchain from realtek. Target is MIPS32 bit LSB. 
> > So far, I get this when compiling.
> > 
> > ude '-DDESTDIR="/usr"' -DCHAPMS=1 -DMPPE=1 -DHAS_SHADOW -DHAVE_CRYPT_H=1
> > -DHAVE_LOGWTMP=1 -DUSE_CRYPT=1 -DHAVE_MULTILINK -DUSE_TDB=1 -DPLUGIN -DINET6=1
> > -DMAXOCTETS -Wl,-E -o pppd main.o magic.o fsm.o lcp.o ipcp.o upap.o chap-new.o
> > md5.o ccp.o ecp.o auth.o options.o demand.o utils.o sys-linux.o ipxcp.o tty.o
> > eap.o chap-md5.o session.o md4.o chap_ms.o sha1.o pppcrypt.o multilink.o tdb.o
> > spinlock.o ipv6cp.o eui64.o  -lcrypt -lutil -ldl
> > /home/cassiano/projects/oiw-2441apgn/realtek/rsdk-4.6.4-4181-EB-3.10-u0.9.33-m32-150324/bin/../lib/gcc/mips-linux-uclibc/4.6.4/../../../../mips-linux-uclibc/bin/ld:
> > cannot find -lutil
> 
>  Looks like the Realtek toolchain is not compatible with Buildroot assumptions.
> libutil is part of the toolchain. I guess Realtek configures uClibc without
> UCLIBC_HAS_LIBUTIL.

Which suddenly rings a bell here: the latest uClibc-ng version, 1.0.18,
now is one-lib, i.e. everything merged into libc.so like musl is, so
we could get external toolchains which will lack libutil.so because
there is no longer such a library now.

If uClibc-ng does like musl does, there will be a lot of empty static
versions of the libraries, libutil.a, libcrypt.a and so on, but there
will no longer be shared variants.

We'll have to account for that in our external toolchain handling.

Regards,
Yann E. MORIN.

>  Buildroot cannot support all possible uClibc configurations for all packages.
> Instead, we take minimal assumptions about the uClibc configuration - basically
> package/uclibc/uClibc-ng.config. If you have something less than that, then some
> packages may fail.
> 
>  The workaround you propose is basically disabling wtmp support. It's not really
> acceptable to do that for 95% of the users who actually do have this in their
> toolchain.
> 
>  We should probably add a FAQ entry for this kind of issue.
> 
>  Regards,
>  Arnout
> 
> > collect2: ld returned 1 exit status
> > Makefile:217: recipe for target 'pppd' failed
> > make[2]: *** [pppd] Error 1
> > make[2]: Leaving directory
> > '/home/cassiano/projects/oiw-2441apgn/output/build/pppd-2.4.7/pppd'
> > Makefile:13: recipe for target 'all' failed
> > make[1]: *** [all] Error 2
> > make[1]: Leaving directory
> > '/home/cassiano/projects/oiw-2441apgn/output/build/pppd-2.4.7'
> > package/pkg-generic.mk:201 <http://pkg-generic.mk:201>: recipe for target
> > '/home/cassiano/projects/oiw-2441apgn/output/build/pppd-2.4.7/.stamp_built' failed
> > 
> > 
> 
> -- 
> Arnout Vandecappelle                          arnout at mind be
> Senior Embedded Software Architect            +32-16-286500
> Essensium/Mind                                http://www.mind.be
> G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
> GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] pppd breaks build without libutils

[Thomas Petazzoni]

Hello,

On Tue, 27 Sep 2016 23:43:25 +0200, Yann E. MORIN wrote:

> Which suddenly rings a bell here: the latest uClibc-ng version, 1.0.18,
> now is one-lib, i.e. everything merged into libc.so like musl is, so
> we could get external toolchains which will lack libutil.so because
> there is no longer such a library now.
> 
> If uClibc-ng does like musl does, there will be a lot of empty static
> versions of the libraries, libutil.a, libcrypt.a and so on, but there
> will no longer be shared variants.
> 
> We'll have to account for that in our external toolchain handling.

I'm not sure what needs to be handled. We already support musl that
does this, and it works fine. It should be perfectly transparent to the
external toolchain handling (except the copying of the shared libraries
to the target, of course).

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] pppd breaks build without libutils

[Yann E. MORIN]

Thomas, All,

On 2016-09-28 10:59 +0200, Thomas Petazzoni spake thusly:
> On Tue, 27 Sep 2016 23:43:25 +0200, Yann E. MORIN wrote:
> 
> > Which suddenly rings a bell here: the latest uClibc-ng version, 1.0.18,
> > now is one-lib, i.e. everything merged into libc.so like musl is, so
> > we could get external toolchains which will lack libutil.so because
> > there is no longer such a library now.
> > 
> > If uClibc-ng does like musl does, there will be a lot of empty static
> > versions of the libraries, libutil.a, libcrypt.a and so on, but there
> > will no longer be shared variants.
> > 
> > We'll have to account for that in our external toolchain handling.
> 
> I'm not sure what needs to be handled. We already support musl that
> does this, and it works fine. It should be perfectly transparent to the
> external toolchain handling (except the copying of the shared libraries
> to the target, of course).

That's exactly what I meant: currently, we copy anexplicit set of shared
libraries from external uClibc-based toolchains:

   66 ifeq ($(BR2_TOOLCHAIN_EXTERNAL_GLIBC)$(BR2_TOOLCHAIN_EXTERNAL_UCLIBC),y)
   67 TOOLCHAIN_EXTERNAL_LIBS += libatomic.so.* libc.so.* libcrypt.so.*
        libdl.so.* libgcc_s.so.* libm.so.*       libnsl.so.* libresolv.so.*
        librt.so.* libutil.so.*
   68 ifeq ($(BR2_TOOLCHAIN_EXTERNAL_GLIBC)$(BR2_ARM_EABIHF),yy)
   69 TOOLCHAIN_EXTERNAL_LIBS += ld-linux-armhf.so.*
   70 else
   71 TOOLCHAIN_EXTERNAL_LIBS += ld*.so.*
   72 endif
   73 ifeq ($(BR2_TOOLCHAIN_HAS_THREADS),y)
   74 TOOLCHAIN_EXTERNAL_LIBS += libpthread.so.*
   75 ifneq ($(BR2_PACKAGE_GDB)$(BR2_TOOLCHAIN_EXTERNAL_GDB_SERVER_COPY),)
   76 TOOLCHAIN_EXTERNAL_LIBS += libthread_db.so.*
   77 endif # gdbserver
   78 endif # ! no threads
   79 endif

Now, old uClibc-based toolchains will have those libs, while newer ones
will only have libc.so.* .

This is that which we need to account for.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] pppd breaks build without libutils

[Waldemar Brodkorb]

Hi,
Yann E. MORIN wrote,

> Thomas, All,
> 
> On 2016-09-28 10:59 +0200, Thomas Petazzoni spake thusly:
> > On Tue, 27 Sep 2016 23:43:25 +0200, Yann E. MORIN wrote:
> > 
> > > Which suddenly rings a bell here: the latest uClibc-ng version, 1.0.18,
> > > now is one-lib, i.e. everything merged into libc.so like musl is, so
> > > we could get external toolchains which will lack libutil.so because
> > > there is no longer such a library now.
> > > 
> > > If uClibc-ng does like musl does, there will be a lot of empty static
> > > versions of the libraries, libutil.a, libcrypt.a and so on, but there
> > > will no longer be shared variants.
> > > 
> > > We'll have to account for that in our external toolchain handling.
> > 
> > I'm not sure what needs to be handled. We already support musl that
> > does this, and it works fine. It should be perfectly transparent to the
> > external toolchain handling (except the copying of the shared libraries
> > to the target, of course).
> 
> That's exactly what I meant: currently, we copy anexplicit set of shared
> libraries from external uClibc-based toolchains:
> 
>    66 ifeq ($(BR2_TOOLCHAIN_EXTERNAL_GLIBC)$(BR2_TOOLCHAIN_EXTERNAL_UCLIBC),y)
>    67 TOOLCHAIN_EXTERNAL_LIBS += libatomic.so.* libc.so.* libcrypt.so.*
>         libdl.so.* libgcc_s.so.* libm.so.*       libnsl.so.* libresolv.so.*
>         librt.so.* libutil.so.*
>    68 ifeq ($(BR2_TOOLCHAIN_EXTERNAL_GLIBC)$(BR2_ARM_EABIHF),yy)
>    69 TOOLCHAIN_EXTERNAL_LIBS += ld-linux-armhf.so.*
>    70 else
>    71 TOOLCHAIN_EXTERNAL_LIBS += ld*.so.*
>    72 endif
>    73 ifeq ($(BR2_TOOLCHAIN_HAS_THREADS),y)
>    74 TOOLCHAIN_EXTERNAL_LIBS += libpthread.so.*
>    75 ifneq ($(BR2_PACKAGE_GDB)$(BR2_TOOLCHAIN_EXTERNAL_GDB_SERVER_COPY),)
>    76 TOOLCHAIN_EXTERNAL_LIBS += libthread_db.so.*
>    77 endif # gdbserver
>    78 endif # ! no threads
>    79 endif
> 
> Now, old uClibc-based toolchains will have those libs, while newer ones
> will only have libc.so.* .

Just to be sure:
It will have libc.so.* and ld-uClibc* they are not combined.
And for gdb threading we still have libthread_db.so*.

best regards
 Waldemar

[Buildroot] pppd breaks build without libutils

[Yann E. MORIN]

Waldemar, All,

On 2016-09-28 18:41 +0200, Waldemar Brodkorb spake thusly:
> Yann E. MORIN wrote,
> > On 2016-09-28 10:59 +0200, Thomas Petazzoni spake thusly:
> > > On Tue, 27 Sep 2016 23:43:25 +0200, Yann E. MORIN wrote:
> > > 
> > > > Which suddenly rings a bell here: the latest uClibc-ng version, 1.0.18,
> > > > now is one-lib, i.e. everything merged into libc.so like musl is, so
> > > > we could get external toolchains which will lack libutil.so because
> > > > there is no longer such a library now.
> > > > 
> > > > If uClibc-ng does like musl does, there will be a lot of empty static
> > > > versions of the libraries, libutil.a, libcrypt.a and so on, but there
> > > > will no longer be shared variants.
> > > > 
> > > > We'll have to account for that in our external toolchain handling.
> > > 
> > > I'm not sure what needs to be handled. We already support musl that
> > > does this, and it works fine. It should be perfectly transparent to the
> > > external toolchain handling (except the copying of the shared libraries
> > > to the target, of course).
> > 
> > That's exactly what I meant: currently, we copy anexplicit set of shared
> > libraries from external uClibc-based toolchains:
> > 
> >    66 ifeq ($(BR2_TOOLCHAIN_EXTERNAL_GLIBC)$(BR2_TOOLCHAIN_EXTERNAL_UCLIBC),y)
> >    67 TOOLCHAIN_EXTERNAL_LIBS += libatomic.so.* libc.so.* libcrypt.so.*
> >         libdl.so.* libgcc_s.so.* libm.so.*       libnsl.so.* libresolv.so.*
> >         librt.so.* libutil.so.*
> >    68 ifeq ($(BR2_TOOLCHAIN_EXTERNAL_GLIBC)$(BR2_ARM_EABIHF),yy)
> >    69 TOOLCHAIN_EXTERNAL_LIBS += ld-linux-armhf.so.*
> >    70 else
> >    71 TOOLCHAIN_EXTERNAL_LIBS += ld*.so.*
> >    72 endif
> >    73 ifeq ($(BR2_TOOLCHAIN_HAS_THREADS),y)
> >    74 TOOLCHAIN_EXTERNAL_LIBS += libpthread.so.*
> >    75 ifneq ($(BR2_PACKAGE_GDB)$(BR2_TOOLCHAIN_EXTERNAL_GDB_SERVER_COPY),)
> >    76 TOOLCHAIN_EXTERNAL_LIBS += libthread_db.so.*
> >    77 endif # gdbserver
> >    78 endif # ! no threads
> >    79 endif
> > 
> > Now, old uClibc-based toolchains will have those libs, while newer ones
> > will only have libc.so.* .
> 
> Just to be sure:
> It will have libc.so.* and ld-uClibc* they are not combined.
> And for gdb threading we still have libthread_db.so*.

Yes, I've seen that, but the main point is that most of the shared
variants will no longer be available any more, so we need to only copy
them when they exist.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] pppd breaks build without libutils

[Arnout Vandecappelle]

On 28-09-16 18:34, Yann E. MORIN wrote:
> Thomas, All,
> 
> On 2016-09-28 10:59 +0200, Thomas Petazzoni spake thusly:
>> On Tue, 27 Sep 2016 23:43:25 +0200, Yann E. MORIN wrote:
>>
>>> Which suddenly rings a bell here: the latest uClibc-ng version, 1.0.18,
>>> now is one-lib, i.e. everything merged into libc.so like musl is, so
>>> we could get external toolchains which will lack libutil.so because
>>> there is no longer such a library now.
>>>
>>> If uClibc-ng does like musl does, there will be a lot of empty static
>>> versions of the libraries, libutil.a, libcrypt.a and so on, but there
>>> will no longer be shared variants.
>>>
>>> We'll have to account for that in our external toolchain handling.
>>
>> I'm not sure what needs to be handled. We already support musl that
>> does this, and it works fine. It should be perfectly transparent to the
>> external toolchain handling (except the copying of the shared libraries
>> to the target, of course).
> 
> That's exactly what I meant: currently, we copy anexplicit set of shared
> libraries from external uClibc-based toolchains:
> 
>    66 ifeq ($(BR2_TOOLCHAIN_EXTERNAL_GLIBC)$(BR2_TOOLCHAIN_EXTERNAL_UCLIBC),y)
>    67 TOOLCHAIN_EXTERNAL_LIBS += libatomic.so.* libc.so.* libcrypt.so.*
>         libdl.so.* libgcc_s.so.* libm.so.*       libnsl.so.* libresolv.so.*
>         librt.so.* libutil.so.*
>    68 ifeq ($(BR2_TOOLCHAIN_EXTERNAL_GLIBC)$(BR2_ARM_EABIHF),yy)
>    69 TOOLCHAIN_EXTERNAL_LIBS += ld-linux-armhf.so.*
>    70 else
>    71 TOOLCHAIN_EXTERNAL_LIBS += ld*.so.*
>    72 endif
>    73 ifeq ($(BR2_TOOLCHAIN_HAS_THREADS),y)
>    74 TOOLCHAIN_EXTERNAL_LIBS += libpthread.so.*
>    75 ifneq ($(BR2_PACKAGE_GDB)$(BR2_TOOLCHAIN_EXTERNAL_GDB_SERVER_COPY),)
>    76 TOOLCHAIN_EXTERNAL_LIBS += libthread_db.so.*
>    77 endif # gdbserver
>    78 endif # ! no threads
>    79 endif
> 
> Now, old uClibc-based toolchains will have those libs, while newer ones
> will only have libc.so.* .
> 
> This is that which we need to account for.

TOOLCHAIN_EXTERNAL_LIBS is used as the -name argument of a find, so no error if
it doesn't exist. I tried adding a libfoobar.so.* and it doesn't complain (and
obviously there is no libfoobar.so.* in staging).

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF