* [Buildroot] pppd breaks build without libutils
@ 2016-09-25 16:53 Cassiano Martin
2016-09-25 18:58 ` Thomas Petazzoni
0 siblings, 1 reply; 10+ messages in thread
From: Cassiano Martin @ 2016-09-25 16:53 UTC (permalink / raw)
To: buildroot
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>
^ permalink raw reply [flat|nested] 10+ messages in thread* [Buildroot] pppd breaks build without libutils 2016-09-25 16:53 [Buildroot] pppd breaks build without libutils Cassiano Martin @ 2016-09-25 18:58 ` Thomas Petazzoni 2016-09-25 23:39 ` Cassiano Martin 0 siblings, 1 reply; 10+ messages in thread From: Thomas Petazzoni @ 2016-09-25 18:58 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [Buildroot] pppd breaks build without libutils 2016-09-25 18:58 ` Thomas Petazzoni @ 2016-09-25 23:39 ` Cassiano Martin 2016-09-27 21:33 ` Arnout Vandecappelle 0 siblings, 1 reply; 10+ messages in thread From: Cassiano Martin @ 2016-09-25 23:39 UTC (permalink / raw) To: buildroot 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> ^ permalink raw reply [flat|nested] 10+ messages in thread
* [Buildroot] pppd breaks build without libutils 2016-09-25 23:39 ` Cassiano Martin @ 2016-09-27 21:33 ` Arnout Vandecappelle 2016-09-27 21:43 ` Yann E. MORIN 0 siblings, 1 reply; 10+ messages in thread From: Arnout Vandecappelle @ 2016-09-27 21:33 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [Buildroot] pppd breaks build without libutils 2016-09-27 21:33 ` Arnout Vandecappelle @ 2016-09-27 21:43 ` Yann E. MORIN 2016-09-28 8:59 ` Thomas Petazzoni 0 siblings, 1 reply; 10+ messages in thread From: Yann E. MORIN @ 2016-09-27 21:43 UTC (permalink / raw) To: buildroot 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. | '------------------------------^-------^------------------^--------------------' ^ permalink raw reply [flat|nested] 10+ messages in thread
* [Buildroot] pppd breaks build without libutils 2016-09-27 21:43 ` Yann E. MORIN @ 2016-09-28 8:59 ` Thomas Petazzoni 2016-09-28 16:34 ` Yann E. MORIN 0 siblings, 1 reply; 10+ messages in thread From: Thomas Petazzoni @ 2016-09-28 8:59 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [Buildroot] pppd breaks build without libutils 2016-09-28 8:59 ` Thomas Petazzoni @ 2016-09-28 16:34 ` Yann E. MORIN 2016-09-28 16:41 ` Waldemar Brodkorb 2016-09-29 9:41 ` Arnout Vandecappelle 0 siblings, 2 replies; 10+ messages in thread From: Yann E. MORIN @ 2016-09-28 16:34 UTC (permalink / raw) To: buildroot 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. | '------------------------------^-------^------------------^--------------------' ^ permalink raw reply [flat|nested] 10+ messages in thread
* [Buildroot] pppd breaks build without libutils 2016-09-28 16:34 ` Yann E. MORIN @ 2016-09-28 16:41 ` Waldemar Brodkorb 2016-09-28 16:47 ` Yann E. MORIN 2016-09-29 9:41 ` Arnout Vandecappelle 1 sibling, 1 reply; 10+ messages in thread From: Waldemar Brodkorb @ 2016-09-28 16:41 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [Buildroot] pppd breaks build without libutils 2016-09-28 16:41 ` Waldemar Brodkorb @ 2016-09-28 16:47 ` Yann E. MORIN 0 siblings, 0 replies; 10+ messages in thread From: Yann E. MORIN @ 2016-09-28 16:47 UTC (permalink / raw) To: buildroot 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. | '------------------------------^-------^------------------^--------------------' ^ permalink raw reply [flat|nested] 10+ messages in thread
* [Buildroot] pppd breaks build without libutils 2016-09-28 16:34 ` Yann E. MORIN 2016-09-28 16:41 ` Waldemar Brodkorb @ 2016-09-29 9:41 ` Arnout Vandecappelle 1 sibling, 0 replies; 10+ messages in thread From: Arnout Vandecappelle @ 2016-09-29 9:41 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2016-09-29 9:41 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-09-25 16:53 [Buildroot] pppd breaks build without libutils Cassiano Martin 2016-09-25 18:58 ` Thomas Petazzoni 2016-09-25 23:39 ` Cassiano Martin 2016-09-27 21:33 ` Arnout Vandecappelle 2016-09-27 21:43 ` Yann E. MORIN 2016-09-28 8:59 ` Thomas Petazzoni 2016-09-28 16:34 ` Yann E. MORIN 2016-09-28 16:41 ` Waldemar Brodkorb 2016-09-28 16:47 ` Yann E. MORIN 2016-09-29 9:41 ` Arnout Vandecappelle
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.