Message ID | 20220620115510.33792-1-paul@crapouillou.net |
---|---|
State | Rejected |
Headers | show |
Series | [1/1] package/boost: add option to force static build | expand |
Hello Paul, Le 20/06/2022 à 13:55, Paul Cercueil a écrit : > This option can be useful when building for a system that > needs to somewhat maintain compatibility with previously built > software, as Boost is notorious for breaking ABI at every > single release. > > Signed-off-by: Paul Cercueil <paul@crapouillou.net> > --- > package/boost/Config.in | 11 +++++++++++ > package/boost/boost.mk | 2 +- > 2 files changed, 12 insertions(+), 1 deletion(-) > > diff --git a/package/boost/Config.in b/package/boost/Config.in > index b99b01f22e..60eb83ff4c 100644 > --- a/package/boost/Config.in > +++ b/package/boost/Config.in > @@ -16,6 +16,17 @@ config BR2_PACKAGE_BOOST > > if BR2_PACKAGE_BOOST > > +config BR2_PACKAGE_BOOST_STATIC > + bool "Build static libraries" > + depends on BR2_SHARED_LIBS > + help > + Build static Boost libraries. > + > + This option can be useful when building for a system that > + needs to somewhat maintain compatibility with previously built > + software, as Boost is notorious for breaking ABI at every > + single release. > + > config BR2_PACKAGE_BOOST_ATOMIC > bool "boost-atomic" > depends on BR2_TOOLCHAIN_SUPPORTS_ALWAYS_LOCKFREE_ATOMIC_INTS > diff --git a/package/boost/boost.mk b/package/boost/boost.mk > index f6e9a03220..162277b968 100644 > --- a/package/boost/boost.mk > +++ b/package/boost/boost.mk > @@ -109,7 +109,7 @@ endif > > # By default, Boost build and installs both the shared and static > # variants. Override that if we want static only or shared only. > -ifeq ($(BR2_STATIC_LIBS),y) > +ifeq ($(BR2_STATIC_LIBS)$(BR2_PACKAGE_BOOST_STATIC),y) > BOOST_OPTS += link=static runtime-link=static So in a BR2_SHARED_LIBS configuration, we end up with static boost libraries? What could happens with packages expecting boost shared libraries due to BR2_SHARED_LIBS but only get static boost libraries? Also a similar per-package option could be added to all packages... After discussing with Thomas and Arnout, we are not convinced by this patch. Best regards, Romain > else ifeq ($(BR2_SHARED_LIBS),y) > BOOST_OPTS += link=shared runtime-link=shared
Hi Romain, Le mer., juil. 27 2022 at 17:06:52 +0200, Romain Naour <romain.naour@smile.fr> a écrit : > Hello Paul, > > Le 20/06/2022 à 13:55, Paul Cercueil a écrit : >> This option can be useful when building for a system that >> needs to somewhat maintain compatibility with previously built >> software, as Boost is notorious for breaking ABI at every >> single release. >> >> Signed-off-by: Paul Cercueil <paul@crapouillou.net> >> --- >> package/boost/Config.in | 11 +++++++++++ >> package/boost/boost.mk | 2 +- >> 2 files changed, 12 insertions(+), 1 deletion(-) >> >> diff --git a/package/boost/Config.in b/package/boost/Config.in >> index b99b01f22e..60eb83ff4c 100644 >> --- a/package/boost/Config.in >> +++ b/package/boost/Config.in >> @@ -16,6 +16,17 @@ config BR2_PACKAGE_BOOST >> >> if BR2_PACKAGE_BOOST >> >> +config BR2_PACKAGE_BOOST_STATIC >> + bool "Build static libraries" >> + depends on BR2_SHARED_LIBS >> + help >> + Build static Boost libraries. >> + >> + This option can be useful when building for a system that >> + needs to somewhat maintain compatibility with previously built >> + software, as Boost is notorious for breaking ABI at every >> + single release. >> + >> config BR2_PACKAGE_BOOST_ATOMIC >> bool "boost-atomic" >> depends on BR2_TOOLCHAIN_SUPPORTS_ALWAYS_LOCKFREE_ATOMIC_INTS >> diff --git a/package/boost/boost.mk b/package/boost/boost.mk >> index f6e9a03220..162277b968 100644 >> --- a/package/boost/boost.mk >> +++ b/package/boost/boost.mk >> @@ -109,7 +109,7 @@ endif >> >> # By default, Boost build and installs both the shared and static >> # variants. Override that if we want static only or shared only. >> -ifeq ($(BR2_STATIC_LIBS),y) >> +ifeq ($(BR2_STATIC_LIBS)$(BR2_PACKAGE_BOOST_STATIC),y) >> BOOST_OPTS += link=static runtime-link=static > > So in a BR2_SHARED_LIBS configuration, we end up with static boost > libraries? If the option is set, yes. > What could happens with packages expecting boost shared libraries due > to > BR2_SHARED_LIBS but only get static boost libraries? Then they would just compile against the static library. Or what do you mean? > Also a similar per-package option could be added to all packages... > > After discussing with Thomas and Arnout, we are not convinced by this > patch. Yes, I know that a similar per-package option could be added to all packages, and I know that we (both you and me) don't want that. My argument is that none of the other packages (that I know of) break ABI at every single minor version. Only Boost does that, and it makes it completely impossible to support old programs. I've been doing this trick of compiling static builds of Boost since Buildroot 2014.05 and the majority of binaries built back then still run with my current distribution based on Buildroot 2021.08. Programs built against shared Boost would break every 3 months. Cheers, -Paul
Paul, All, On 2022-07-27 16:42 +0100, Paul Cercueil spake thusly: > Le mer., juil. 27 2022 at 17:06:52 +0200, Romain Naour > <romain.naour@smile.fr> a écrit : > >Le 20/06/2022 à 13:55, Paul Cercueil a écrit : > >> This option can be useful when building for a system that > >> needs to somewhat maintain compatibility with previously built > >> software, as Boost is notorious for breaking ABI at every > >> single release. If you need to link with boost libs, it means your program already know the correct ABI? I mean, you have two situations: - you have sources for your program: you don't care about ABI breakage, because you will build from source, so the compiler and linker knows what to do, so you don't need to force static libs? - you have a .o file for your package's, and you can actually link with the static libs, so it means you have the proper ABI, so why can't you link with the shared ones? Now, if you have a binary-only executable, then you don't need to link it at all. So, I am not sure I see what the actual issue is... Also, I don't think it is sane, as Romain pointed out, that the whole Boost is bilt statically for the whole system; that does not fly with me... > >After discussing with Thomas and Arnout, we are not convinced by this > >patch. Neither am I... > Yes, I know that a similar per-package option could be added to all > packages, and I know that we (both you and me) don't want that. My argument > is that none of the other packages (that I know of) break ABI at every > single minor version. Only Boost does that, and it makes it completely > impossible to support old programs. > > I've been doing this trick of compiling static builds of Boost since > Buildroot 2014.05 and the majority of binaries built back then still run > with my current distribution based on Buildroot 2021.08. Programs built > against shared Boost would break every 3 months. I don't understand what you are saying here. Do you mean that you built binaries back in 2014, and drop them in your shinny new system, and they still run? That's fine, do that: install pre-built binaries of your application: you don't need to build a static boost on the whole system for that. Now, if what you need is a way to initially be able to build those programs to start with, and link them statically, so that you can install them as binary prebuilt, then build a static-only SDK, build your programs, and drop them in your other configuration that has Boost available as shared for the rest of the system. Of course, unless there is something else I missed (entirely possible as I am having a very bad day today and can't think totally right). Regards, Yann E. MORIN.
Hi Yann, Le mer., juil. 27 2022 at 17:57:11 +0200, Yann E. MORIN <yann.morin.1998@free.fr> a écrit : > Paul, All, > > On 2022-07-27 16:42 +0100, Paul Cercueil spake thusly: >> Le mer., juil. 27 2022 at 17:06:52 +0200, Romain Naour >> <romain.naour@smile.fr> a écrit : >> >Le 20/06/2022 à 13:55, Paul Cercueil a écrit : >> >> This option can be useful when building for a system that >> >> needs to somewhat maintain compatibility with previously built >> >> software, as Boost is notorious for breaking ABI at every >> >> single release. > > If you need to link with boost libs, it means your program already > know > the correct ABI? It knows the ABI of libboost that was used at the time the program was compiled. > I mean, you have two situations: > - you have sources for your program: you don't care about ABI > breakage, because you will build from source, so the compiler and > linker knows what to do, so you don't need to force static libs? That's true, *if* you only consider Buildroot packages. Because as soon as libboost is bumped in Buildroot, every application compiled against the previous SDK is broken, and needs to be compiled again. > - you have a .o file for your package's, and you can actually link > with the static libs, so it means you have the proper ABI, so why > can't you link with the shared ones? As soon as libboost is bumped in Buildroot, the symbol names of the library change, so everything need to be compiled from sources again, and not just re-linked. > Now, if you have a binary-only executable, then you don't need to link > it at all. If I have a binary-only executable linked to a shared libboost, then I *need* to have in the rootfs the shared libboost of the *exact* same version used when compiling. Which means that as soon as my users update the rootfs, every pre-built application out there that links against libboost is now broken. > So, I am not sure I see what the actual issue is... > > Also, I don't think it is sane, as Romain pointed out, that the whole > Boost is bilt statically for the whole system; that does not fly with > me... > >> >After discussing with Thomas and Arnout, we are not convinced by >> this >> >patch. > > Neither am I... > >> Yes, I know that a similar per-package option could be added to all >> packages, and I know that we (both you and me) don't want that. My >> argument >> is that none of the other packages (that I know of) break ABI at >> every >> single minor version. Only Boost does that, and it makes it >> completely >> impossible to support old programs. >> >> I've been doing this trick of compiling static builds of Boost since >> Buildroot 2014.05 and the majority of binaries built back then >> still run >> with my current distribution based on Buildroot 2021.08. Programs >> built >> against shared Boost would break every 3 months. > > I don't understand what you are saying here. Do you mean that you > built > binaries back in 2014, and drop them in your shinny new system, and > they > still run? That's fine, do that: install pre-built binaries of your > application: you don't need to build a static boost on the whole > system > for that. Those binaries built back in 2014 still run now because I already had the "static libboost" exception back in 2014. If I didn't have that, these binaries would have been linked against the shared libboost, and would have been broken as soon as the shared libboost bumped its *minor* version - which occurs every few months. Since these old binaries are not linked against a shared libboost, thanks to the "static libboost" exception, they are not the problem here. What I am trying to do, is to make sure that any program compiled today against my buildroot SDK won't link against the shared libboost, and link against a static libboost instead, to give them a chance to be compatible in my distribution for a bit more than a few months. Note that by "programs" here we're talking about applications and games produced by the community, which may be closed-source and very old, which means that they cannot be easily recompiled. > Now, if what you need is a way to initially be able to build those > programs to start with, and link them statically, so that you can > install them as binary prebuilt, then build a static-only SDK, build > your programs, and drop them in your other configuration that has > Boost > available as shared for the rest of the system. > > Of course, unless there is something else I missed (entirely possible > as I am having a very bad day today and can't think totally right). I want to link everything dynamically for the flexibility - for instance all of our old games (including closed-sources ones) gained support for rendering on DRM/KMS through SDL1, just because they were dynamically linked against libsdl1. I only want to link statically against libboost, because it is the only library that breaks its ABI at every single *minor* version, while every other library breaks its ABI at every *major* version. Hope that clears any doubts. Cheers, -Paul
diff --git a/package/boost/Config.in b/package/boost/Config.in index b99b01f22e..60eb83ff4c 100644 --- a/package/boost/Config.in +++ b/package/boost/Config.in @@ -16,6 +16,17 @@ config BR2_PACKAGE_BOOST if BR2_PACKAGE_BOOST +config BR2_PACKAGE_BOOST_STATIC + bool "Build static libraries" + depends on BR2_SHARED_LIBS + help + Build static Boost libraries. + + This option can be useful when building for a system that + needs to somewhat maintain compatibility with previously built + software, as Boost is notorious for breaking ABI at every + single release. + config BR2_PACKAGE_BOOST_ATOMIC bool "boost-atomic" depends on BR2_TOOLCHAIN_SUPPORTS_ALWAYS_LOCKFREE_ATOMIC_INTS diff --git a/package/boost/boost.mk b/package/boost/boost.mk index f6e9a03220..162277b968 100644 --- a/package/boost/boost.mk +++ b/package/boost/boost.mk @@ -109,7 +109,7 @@ endif # By default, Boost build and installs both the shared and static # variants. Override that if we want static only or shared only. -ifeq ($(BR2_STATIC_LIBS),y) +ifeq ($(BR2_STATIC_LIBS)$(BR2_PACKAGE_BOOST_STATIC),y) BOOST_OPTS += link=static runtime-link=static else ifeq ($(BR2_SHARED_LIBS),y) BOOST_OPTS += link=shared runtime-link=shared
This option can be useful when building for a system that needs to somewhat maintain compatibility with previously built software, as Boost is notorious for breaking ABI at every single release. Signed-off-by: Paul Cercueil <paul@crapouillou.net> --- package/boost/Config.in | 11 +++++++++++ package/boost/boost.mk | 2 +- 2 files changed, 12 insertions(+), 1 deletion(-)