| Message ID | 1442450292-13794-1-git-send-email-ryanbarnett3@gmail.com |
|---|---|
| State | Rejected |
| Headers | show |
Ryan, On Wed, 16 Sep 2015 19:38:12 -0500, Ryan Barnett wrote: > While attempting to build make in a static library only configuration > the following error will be shown: > > gc_pthread_redirects.h:37:22: fatal error: dlfcn.h: No such file or > directory > # include <dlfcn.h> > > Fix this by depending make on !BR2_STATIC_LIBS. > > Fixes: > http://autobuild.buildroot.net/results/814/8143ae0afac139845e5016058d85c800dc8527ad > > Signed-off-by: Ryan Barnett <ryanbarnett3@gmail.com> Unfortunately, I believe this is not the proper fix. If you use http://autobuild.buildroot.org/toolchains/configs/br-arm-full-static.config and build just the make package, it builds just fine: $ file output/target/usr/bin/make output/target/usr/bin/make: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, stripped The file gc_pthread_redirects.h comes, I believe, from bdwgc, which got built before make in the autobuild test case you're pointing to. This header file is known to incorrectly include <dlfcn.h>, unless GC_NO_DLOPEN is specified. See what is done in guile.mk for example to pass GC_NO_DLOPEN when BR2_STATIC_LIBS=y. I believe the chain is that you have bdwgc that gets built, then guile, then make. In this case, make detects the availability of guile and uses it, which is the reason why gc_pthread_redirects.h gets included by make. So I suggest one of the two options: * Make the optional dependency of make on guile explicit in make.mk, and pass GC_NO_DLOPEN when we're building statically. * Disable guile support completely in make. I don't think we care about having guile support in make in the context of Buildroot, so this is probably the easiest solution. Consequently, I've marked your patch as Rejected in patchwork. Can you send a patch implementing one of the two options above? Thanks, Thomas
Thomas, On Thu, Sep 17, 2015 at 4:27 PM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: > Ryan, > > On Wed, 16 Sep 2015 19:38:12 -0500, Ryan Barnett wrote: >> While attempting to build make in a static library only configuration >> the following error will be shown: >> >> gc_pthread_redirects.h:37:22: fatal error: dlfcn.h: No such file or >> directory >> # include <dlfcn.h> >> >> Fix this by depending make on !BR2_STATIC_LIBS. >> >> Fixes: >> http://autobuild.buildroot.net/results/814/8143ae0afac139845e5016058d85c800dc8527ad >> >> Signed-off-by: Ryan Barnett <ryanbarnett3@gmail.com> > > Unfortunately, I believe this is not the proper fix. If you use > http://autobuild.buildroot.org/toolchains/configs/br-arm-full-static.config > and build just the make package, it builds just fine: > > $ file output/target/usr/bin/make > output/target/usr/bin/make: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, stripped > > The file gc_pthread_redirects.h comes, I believe, from bdwgc, which got > built before make in the autobuild test case you're pointing to. This > header file is known to incorrectly include <dlfcn.h>, unless > GC_NO_DLOPEN is specified. See what is done in guile.mk for example to > pass GC_NO_DLOPEN when BR2_STATIC_LIBS=y. > > I believe the chain is that you have bdwgc that gets built, then guile, > then make. In this case, make detects the availability of guile and > uses it, which is the reason why gc_pthread_redirects.h gets included > by make. Thank you for the detailed explanation! I had quickly seen how this was addressed in the past via a search of the mailing list. > So I suggest one of the two options: > > * Make the optional dependency of make on guile explicit in make.mk, > and pass GC_NO_DLOPEN when we're building statically. > > * Disable guile support completely in make. I don't think we care > about having guile support in make in the context of Buildroot, so > this is probably the easiest solution. I am going to go disabling guile support in a static only configuration. I ran into an issue with setting GC_NO_DLOPEN define in that there then becomes multiple definitions of locale_charset between libintl and libguile and I wasn't sure how to properly fix it. Looking at what guile is used for in make, it doesn't appear extremely useful especially in a static only configuration. Thanks, -Ryan
Hello, On Sun, 20 Sep 2015 09:40:25 -0500, Ryan Barnett wrote: > I am going to go disabling guile support in a static only > configuration. I ran into an issue with setting GC_NO_DLOPEN define in > that there then becomes multiple definitions of locale_charset between > libintl and libguile and I wasn't sure how to properly fix it. Looking > at what guile is used for in make, it doesn't appear extremely useful > especially in a static only configuration. I think we should disable guile support completely, not only for static only builds. I don't really see the usefulness of guile support in make in the context of Buildroot. Generally speaking, I think we should --disable-<foo> or --without-<foo> explicitly for as many options as possible, unless they are explicitly handled in Buildroot. Thomas
Ryan, On Sun, 20 Sep 2015 18:58:21 +0200, Thomas Petazzoni wrote: > On Sun, 20 Sep 2015 09:40:25 -0500, Ryan Barnett wrote: > > > I am going to go disabling guile support in a static only > > configuration. I ran into an issue with setting GC_NO_DLOPEN define in > > that there then becomes multiple definitions of locale_charset between > > libintl and libguile and I wasn't sure how to properly fix it. Looking > > at what guile is used for in make, it doesn't appear extremely useful > > especially in a static only configuration. > > I think we should disable guile support completely, not only for static > only builds. I don't really see the usefulness of guile support in > make in the context of Buildroot. I didn't see that there is some explicit handling of guile in our current make package. It was added by Baruch in commit 38ee8a8e1651f1de2b2698e4c6bce2e488001cdb. Baruch, were you specifically interested in guile support in make? Best regards, Thomas
Hi Thomas, On Sun, Sep 20, 2015 at 07:04:08PM +0200, Thomas Petazzoni wrote: > On Sun, 20 Sep 2015 18:58:21 +0200, Thomas Petazzoni wrote: > > > On Sun, 20 Sep 2015 09:40:25 -0500, Ryan Barnett wrote: > > > > > I am going to go disabling guile support in a static only > > > configuration. I ran into an issue with setting GC_NO_DLOPEN define in > > > that there then becomes multiple definitions of locale_charset between > > > libintl and libguile and I wasn't sure how to properly fix it. Looking > > > at what guile is used for in make, it doesn't appear extremely useful > > > especially in a static only configuration. > > > > I think we should disable guile support completely, not only for static > > only builds. I don't really see the usefulness of guile support in > > make in the context of Buildroot. > > I didn't see that there is some explicit handling of guile in our > current make package. It was added by Baruch in commit > 38ee8a8e1651f1de2b2698e4c6bce2e488001cdb. > > Baruch, were you specifically interested in guile support in make? No. It was just the usual optional dependency for the sake of reproducibility as part of a related build failure investigation. I'm fine with removing guile support in make. baruch
All, On Sep 20, 2015 12:16 PM, "Baruch Siach" <baruch@tkos.co.il> wrote: > > Hi Thomas, > > On Sun, Sep 20, 2015 at 07:04:08PM +0200, Thomas Petazzoni wrote: > > On Sun, 20 Sep 2015 18:58:21 +0200, Thomas Petazzoni wrote: > > > > > On Sun, 20 Sep 2015 09:40:25 -0500, Ryan Barnett wrote: > > > > > > > I am going to go disabling guile support in a static only > > > > configuration. I ran into an issue with setting GC_NO_DLOPEN define in > > > > that there then becomes multiple definitions of locale_charset between > > > > libintl and libguile and I wasn't sure how to properly fix it. Looking > > > > at what guile is used for in make, it doesn't appear extremely useful > > > > especially in a static only configuration. > > > > > > I think we should disable guile support completely, not only for static > > > only builds. I don't really see the usefulness of guile support in > > > make in the context of Buildroot. > > > > I didn't see that there is some explicit handling of guile in our > > current make package. It was added by Baruch in commit > > 38ee8a8e1651f1de2b2698e4c6bce2e488001cdb. > > > > Baruch, were you specifically interested in guile support in make? > > No. It was just the usual optional dependency for the sake of reproducibility > as part of a related build failure investigation. I'm fine with removing guile > support in make. I will just remove it completely. I will send another patch. Thanks, -Ryan
diff --git a/package/make/Config.in b/package/make/Config.in index f576b7b..11adbab 100644 --- a/package/make/Config.in +++ b/package/make/Config.in @@ -1,6 +1,7 @@ config BR2_PACKAGE_MAKE bool "make" depends on BR2_USE_MMU # fork() + depends on !BR2_STATIC_LIBS # dlopen() select BR2_PACKAGE_GETTEXT if BR2_NEEDS_GETTEXT_IF_LOCALE help A tool which controls the generation of executables and other @@ -11,3 +12,6 @@ config BR2_PACKAGE_MAKE useful to run the uClibc test suite on the target. http://www.gnu.org/software/make/ + +comment "make needs a toolchain w/ dynamic libraries" + depends on BR2_STATIC_LIBS
While attempting to build make in a static library only configuration the following error will be shown: gc_pthread_redirects.h:37:22: fatal error: dlfcn.h: No such file or directory # include <dlfcn.h> Fix this by depending make on !BR2_STATIC_LIBS. Fixes: http://autobuild.buildroot.net/results/814/8143ae0afac139845e5016058d85c800dc8527ad Signed-off-by: Ryan Barnett <ryanbarnett3@gmail.com> --- package/make/Config.in | 4 ++++ 1 file changed, 4 insertions(+)