Re: DSO linking changes for wheezy
On Tue, Nov 16, 2010 at 07:04:53PM +0100, Matthias Klose wrote: > On 16.11.2010 10:42, Roger Leigh wrote: >> On Tue, Nov 16, 2010 at 01:14:09AM +0100, Matthias Klose wrote: >>> On 14.11.2010 13:19, Julien Cristau wrote: On Fri, Oct 29, 2010 at 15:43:57 +0200, Matthias Klose wrote: > For wheezy I'm planning to change the linking behaviour for DSOs > (turning on --as-needed and --no-copy-dt-needed-entries. The > rationale is summarized in > http://wiki.debian.org/ToolChain/DSOLinking. I would like to know > about issues with these changes on some of the Debian ports, and if > we need to disable one of these changes on some port. > --no-add-needed sounds like it'll cause a *lot* of build failures for no particular gain. I don't think it's a good idea. >>> >>> I think it is. Besides fixing potential bugs, else you'll never be able >>> to use gold as the linker. See the already filed bug reports. >> >> This change is one I can agree with on technical grounds, though it >> will cause a great deal of pain in the short term. Have we got any >> estimates on exactly how much breakage will result before the change >> gets made? > > see http://wiki.debian.org/ToolChain/DSOLinking#Furtherinformation > referenced in the first email of this thread. I had a look at that, and we've got (summarised) 413 outstanding bugs 308 fixed/pending So there's still some way to go, but looking promising. I did notice that all those bugs were filed almost exactly a year ago. This won't have picked up issues with current packages, such as the Boost link failures I've encountered. Would it be possible to repeat the archive-wide rebuild with our current sources? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: DSO linking changes for wheezy
Florian Weimer, le Tue 16 Nov 2010 19:49:57 +0100, a écrit : > * Roland McGrath: > > >> I can't see why you think --as-needed is fundamentally wrong or > >> unnecessary. > > > > It is fundamentally wrong because -lfoo means I demand that the > > initializers of libfoo.so run, whether or not I called anything in it. > > So it's more like static linking. 8-) ?! Initializers are called dynamically, and if you upgrade the library, the new initializers will be called (and new ones will be called as well!). I don't see what you see static here. Samuel -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101116191430.gf5...@const.famille.thibault.fr
Re: DSO linking changes for wheezy
* Roland McGrath: >> I can't see why you think --as-needed is fundamentally wrong or unnecessary. > > It is fundamentally wrong because -lfoo means I demand that the > initializers of libfoo.so run, whether or not I called anything in it. So it's more like static linking. 8-) IMHO, the current difference in behavior between dynamic and static linking is quite odd. --as-needed changes only one tiny aspect, unfortunately. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zkt95ciy@mid.deneb.enyo.de
Re: DSO linking changes for wheezy
On 16.11.2010 10:42, Roger Leigh wrote: On Tue, Nov 16, 2010 at 01:14:09AM +0100, Matthias Klose wrote: On 14.11.2010 13:19, Julien Cristau wrote: On Fri, Oct 29, 2010 at 15:43:57 +0200, Matthias Klose wrote: For wheezy I'm planning to change the linking behaviour for DSOs (turning on --as-needed and --no-copy-dt-needed-entries. The rationale is summarized in http://wiki.debian.org/ToolChain/DSOLinking. I would like to know about issues with these changes on some of the Debian ports, and if we need to disable one of these changes on some port. --no-add-needed sounds like it'll cause a *lot* of build failures for no particular gain. I don't think it's a good idea. I think it is. Besides fixing potential bugs, else you'll never be able to use gold as the linker. See the already filed bug reports. This change is one I can agree with on technical grounds, though it will cause a great deal of pain in the short term. Have we got any estimates on exactly how much breakage will result before the change gets made? see http://wiki.debian.org/ToolChain/DSOLinking#Furtherinformation referenced in the first email of this thread. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ce2c7c5.5040...@debian.org
Re: DSO linking changes for wheezy
Steve Langasek, le Tue 16 Nov 2010 09:14:40 -0800, a écrit : > I don't argue that this makes --as-needed *correct* as a default, but I > think it's clear how using --as-needed may benefit a distribution in terms > of reducing churn when library dependencies change. We agree on the second part, but the change of behavior makes it unacceptable as default, thus making the second part void. Samuel -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101116174307.gk5...@const.bordeaux.inria.fr
Re: DSO linking changes for wheezy
On Tue, Nov 16, 2010 at 09:49:08AM +0100, Julien Cristau wrote: > On Mon, Nov 15, 2010 at 21:29:07 -0500, Matt Turner wrote: > > >> I can't see why you think --as-needed is fundamentally wrong or > > >> unnecessary. > > >> Check out http://www.gentoo.org/proj/en/qa/asneeded.xml > > >> --as-needed has saved tons of time for upgrades like Cairo in Gentoo, > > >> where Cairo had been linked to glitz which is now useless and gone. > > > Not a problem, if Cairo was properly exposing the dep. > > >> So > > >> when people upgraded Cairo, all the software that linked against it > > >> (and also unnecessarily linked against glitz) > > > Why did it get linked against glitz? That's where the problem is. > > I think because -lglitz was in cairo's .pc file. > That should be fixed by removing -lglitz from cairo's .pc file, not by > passing --as-needed to the linker. I agree with you, -lglitz should never have been listed in the .pc file to begin with. However, *given* that it was there, the default --no-as-needed behavior means that removing libglitz is more painful than it would be otherwise, because instead of just rebuilding cairo itself without glitz, you must rebuild everything above cairo in the stack that used pkg-config for linking. I don't argue that this makes --as-needed *correct* as a default, but I think it's clear how using --as-needed may benefit a distribution in terms of reducing churn when library dependencies change. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101116171440.gf30...@virgil.dodds.net
Re: DSO linking changes for wheezy
* Kurt Roeckx [101114 14:08]: > People have been claiming that constructors or init section are a > possible problem. I have yet to see an example where it breaks. The following example is a bit constructed, but shows a silent change of run-time behaviour if --as-needed is passed: $ cat > ertest.c <<'EOF' #include #include #include #include #include static String fr[] = { "*geometry: 100x100\n", NULL }; int main(int argc, String argv[]) { XtAppContext context; Widget app_shell; app_shell = XtOpenApplication(&context, "ERTEST", NULL, 0, &argc, argv, fr, applicationShellWidgetClass, NULL, 0); XtRealizeWidget(app_shell); XtAppMainLoop(context); return 0; } EOF $ gcc -o ertest -Wall -O2 ertest.c -lXaw -lXt $ ./ertest & $ editres # Select Commands/Get Tree and click at the window the first program created $ gcc -o ertest -Wl,--as-needed -Wall -O2 ertest.c -lXaw -lXt $ ./ertest & $ editres # Try it again and it fails now... Bernhard R. Link -- "Never contain programs so few bugs, as when no debugging tools are available!" Niklaus Wirth -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101116100120.ga29...@pcpool00.mathematik.uni-freiburg.de
Re: DSO linking changes for wheezy
> This change is one I can agree with on technical grounds, though it > will cause a great deal of pain in the short term. Have we got any > estimates on exactly how much breakage will result before the change > gets made? Fedora already made the change a full release cycles ago, and Fedora package maintainers (should have) sent their fixes upstream to the various packages that were affected. You can find some of the details of that experience at: https://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking https://bugzilla.redhat.com/showdependencytree.cgi?id=564245 -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101116095858.ad58e2c...@topped-with-meat.com
Re: DSO linking changes for wheezy
On Tue, Nov 16, 2010 at 01:14:09AM +0100, Matthias Klose wrote: > On 14.11.2010 13:19, Julien Cristau wrote: >> On Fri, Oct 29, 2010 at 15:43:57 +0200, Matthias Klose wrote: >> >>> For wheezy I'm planning to change the linking behaviour for DSOs >>> (turning on --as-needed and --no-copy-dt-needed-entries. The >>> rationale is summarized in >>> http://wiki.debian.org/ToolChain/DSOLinking. I would like to know >>> about issues with these changes on some of the Debian ports, and if >>> we need to disable one of these changes on some port. >>> >> --no-add-needed sounds like it'll cause a *lot* of build failures for no >> particular gain. I don't think it's a good idea. > > I think it is. Besides fixing potential bugs, else you'll never be able > to use gold as the linker. See the already filed bug reports. This change is one I can agree with on technical grounds, though it will cause a great deal of pain in the short term. Have we got any estimates on exactly how much breakage will result before the change gets made? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: DSO linking changes for wheezy
On Tue, Nov 16, 2010 at 01:14:09 +0100, Matthias Klose wrote: > On 14.11.2010 13:19, Julien Cristau wrote: > >On Fri, Oct 29, 2010 at 15:43:57 +0200, Matthias Klose wrote: > > > >>For wheezy I'm planning to change the linking behaviour for DSOs > >>(turning on --as-needed and --no-copy-dt-needed-entries. The > >>rationale is summarized in > >>http://wiki.debian.org/ToolChain/DSOLinking. I would like to know > >>about issues with these changes on some of the Debian ports, and if > >>we need to disable one of these changes on some port. > >> > >--no-add-needed sounds like it'll cause a *lot* of build failures for no > >particular gain. I don't think it's a good idea. > > I think it is. Besides fixing potential bugs, else you'll never be > able to use gold as the linker. See the already filed bug reports. > Exactly, see the already filed reports. You don't need to turn them into build failures before you can file reports and send patches. Cheers, Julien signature.asc Description: Digital signature
Re: DSO linking changes for wheezy
On Mon, Nov 15, 2010 at 21:29:07 -0500, Matt Turner wrote: > On Mon, Nov 15, 2010 at 8:15 PM, Samuel Thibault wrote: > > Matt Turner, le Mon 15 Nov 2010 19:51:10 -0500, a écrit : > >> On Mon, Nov 15, 2010 at 7:24 PM, Roger Leigh wrote: > >> > What's the actual problem --as-needed is trying to solve? > >> > > >> > The answer is mainly unwanted libraries being linked in as a result > >> > of using pkg-config (and various other -config variants), though there > >> > are other, lesser, culprits. The pkg-config .pc files for gtk, gnome > >> > and other libraries add in many libraries, most of which aren't > >> > typically needed. > >> > > >> > The solution: fix the .pc files! > >> > > >> > Using --as-needed is merely papering over the actual root problem. > >> > It "fixes" the symptoms, but it's not addressing the actual cause. > >> > The number of packages providing broken .pc files is not large, and > >> > the number breaking due to relying on this brokenness is likely > >> > just as small. > >> > >> I can't see why you think --as-needed is fundamentally wrong or > >> unnecessary. > >> > >> Check out http://www.gentoo.org/proj/en/qa/asneeded.xml > >> > >> --as-needed has saved tons of time for upgrades like Cairo in Gentoo, > >> where Cairo had been linked to glitz which is now useless and gone. > > > > Not a problem, if Cairo was properly exposing the dep. > > > >> So > >> when people upgraded Cairo, all the software that linked against it > >> (and also unnecessarily linked against glitz) > > > > Why did it get linked against glitz? That's where the problem is. > > I think because -lglitz was in cairo's .pc file. > That should be fixed by removing -lglitz from cairo's .pc file, not by passing --as-needed to the linker. Cheers, Julien signature.asc Description: Digital signature
Re: DSO linking changes for wheezy
On Mon, Nov 15, 2010 at 8:15 PM, Samuel Thibault wrote: > Matt Turner, le Mon 15 Nov 2010 19:51:10 -0500, a écrit : >> On Mon, Nov 15, 2010 at 7:24 PM, Roger Leigh wrote: >> > What's the actual problem --as-needed is trying to solve? >> > >> > The answer is mainly unwanted libraries being linked in as a result >> > of using pkg-config (and various other -config variants), though there >> > are other, lesser, culprits. The pkg-config .pc files for gtk, gnome >> > and other libraries add in many libraries, most of which aren't >> > typically needed. >> > >> > The solution: fix the .pc files! >> > >> > Using --as-needed is merely papering over the actual root problem. >> > It "fixes" the symptoms, but it's not addressing the actual cause. >> > The number of packages providing broken .pc files is not large, and >> > the number breaking due to relying on this brokenness is likely >> > just as small. >> >> I can't see why you think --as-needed is fundamentally wrong or unnecessary. >> >> Check out http://www.gentoo.org/proj/en/qa/asneeded.xml >> >> --as-needed has saved tons of time for upgrades like Cairo in Gentoo, >> where Cairo had been linked to glitz which is now useless and gone. > > Not a problem, if Cairo was properly exposing the dep. > >> So >> when people upgraded Cairo, all the software that linked against it >> (and also unnecessarily linked against glitz) > > Why did it get linked against glitz? That's where the problem is. I think because -lglitz was in cairo's .pc file. Matt -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=tex5afxojxthnva0wcvrha9b-njkem7dnc...@mail.gmail.com
Re: DSO linking changes for wheezy
Matt Turner, le Mon 15 Nov 2010 19:51:10 -0500, a écrit : > On Mon, Nov 15, 2010 at 7:24 PM, Roger Leigh wrote: > > What's the actual problem --as-needed is trying to solve? > > > > The answer is mainly unwanted libraries being linked in as a result > > of using pkg-config (and various other -config variants), though there > > are other, lesser, culprits. The pkg-config .pc files for gtk, gnome > > and other libraries add in many libraries, most of which aren't > > typically needed. > > > > The solution: fix the .pc files! > > > > Using --as-needed is merely papering over the actual root problem. > > It "fixes" the symptoms, but it's not addressing the actual cause. > > The number of packages providing broken .pc files is not large, and > > the number breaking due to relying on this brokenness is likely > > just as small. > > I can't see why you think --as-needed is fundamentally wrong or unnecessary. > > Check out http://www.gentoo.org/proj/en/qa/asneeded.xml > > --as-needed has saved tons of time for upgrades like Cairo in Gentoo, > where Cairo had been linked to glitz which is now useless and gone. Not a problem, if Cairo was properly exposing the dep. > So > when people upgraded Cairo, all the software that linked against it > (and also unnecessarily linked against glitz) Why did it get linked against glitz? That's where the problem is. Samuel -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101116011555.gt6...@const.famille.thibault.fr
Re: DSO linking changes for wheezy
> I can't see why you think --as-needed is fundamentally wrong or unnecessary. It is fundamentally wrong because -lfoo means I demand that the initializers of libfoo.so run, whether or not I called anything in it. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101116011103.5f8452c...@topped-with-meat.com
Re: DSO linking changes for wheezy
On Mon, Nov 15, 2010 at 7:24 PM, Roger Leigh wrote: > What's the actual problem --as-needed is trying to solve? > > The answer is mainly unwanted libraries being linked in as a result > of using pkg-config (and various other -config variants), though there > are other, lesser, culprits. The pkg-config .pc files for gtk, gnome > and other libraries add in many libraries, most of which aren't > typically needed. > > The solution: fix the .pc files! > > Using --as-needed is merely papering over the actual root problem. > It "fixes" the symptoms, but it's not addressing the actual cause. > The number of packages providing broken .pc files is not large, and > the number breaking due to relying on this brokenness is likely > just as small. I can't see why you think --as-needed is fundamentally wrong or unnecessary. Check out http://www.gentoo.org/proj/en/qa/asneeded.xml --as-needed has saved tons of time for upgrades like Cairo in Gentoo, where Cairo had been linked to glitz which is now useless and gone. So when people upgraded Cairo, all the software that linked against it (and also unnecessarily linked against glitz) broke because glitz was missing. Maybe this isn't important for binary distributions. I don't know. I mean, I don't particularly care what Debian does. I just find the fervor with which you fight against --as-needed strange. Matt -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinsmth+krapikupgrww9niqqiy6ogmsuxdox...@mail.gmail.com
Re: DSO linking changes for wheezy
On 16.11.2010 01:24, Roger Leigh wrote: On Mon, Nov 15, 2010 at 11:02:57PM +0100, Matthias Klose wrote: On 14.11.2010 16:06, Roger Leigh wrote: While I understand the rationale for --no-copy-dt-needed-entries for preventing encapsulation violations via indirect linking, I don't agree with the use of --as-needed *at all*. If a library has been explicitly linked in, it shouldn't be removed. This is an issue for fixing in individual packages, not in the toolchain. I can understand on using it on a per-package basis, but not in the actual toolchain defaults. The compiler and linker *should not be second-guessing the user*. This can break perfectly legitimate code making use of ELF constructors and other features which won't be picked out just by looking at symbol usage. People have been claiming that constructors or init section are a possible problem. I have yet to see an example where it breaks. It's not a very widely used feature. I'm sure it's trivial to make such a test case. Portable software tends not to make use of ELF- specific features like this, but that's not an excuse for breaking perfectly legitimate code. But whether or not there are real life examples, --as-needed is *fundamentally wrong*. It's deliberately *not doing what the user requested*, and to make that misfeature the system-wide default would be entirely inappropriate. If a package wishes to make use of such a feature after understanding the implications, then they are free to do so. But to make it the default--I don't think that's a technically sound decision. maybe, and fix it in N - ~100 packages? Or fix the ~100 packages? The point of injection is for discussion. I would prefer having this set in dpkg-buildflags, and then disabled by these ~100 packages. Note that this is probably the same like modifying the N - ~100 packages, as almost no package respects dpkg-buildflags yet. What's the actual problem --as-needed is trying to solve? why did I explain it in the wiki? The answer is mainly unwanted libraries being linked in as a result of using pkg-config (and various other -config variants), though there are other, lesser, culprits. The pkg-config .pc files for gtk, gnome and other libraries add in many libraries, most of which aren't typically needed. The solution: fix the .pc files! and add more .pc files? Definitely not. I didn't see that many packages where different binaries/libaries were linked with a different set of libraries. Usually this is already introduced by upstreams. Using --as-needed is merely papering over the actual root problem. It "fixes" the symptoms, but it's not addressing the actual cause. The number of packages providing broken .pc files is not large, and the number breaking due to relying on this brokenness is likely just as small. Other libraries being linked unnecessarily can be removed on a per-package basis. lintian is warning about this, so most developers should be aware of the problem. Damaging our toolchain to work around buggy build scripts is wrong; we should just fix the scripts! again, this is not a script/pkgconfig problem only. Matthias -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ce1d23f.7000...@debian.org
Re: DSO linking changes for wheezy
On 14.11.2010 13:19, Julien Cristau wrote: On Fri, Oct 29, 2010 at 15:43:57 +0200, Matthias Klose wrote: For wheezy I'm planning to change the linking behaviour for DSOs (turning on --as-needed and --no-copy-dt-needed-entries. The rationale is summarized in http://wiki.debian.org/ToolChain/DSOLinking. I would like to know about issues with these changes on some of the Debian ports, and if we need to disable one of these changes on some port. --no-add-needed sounds like it'll cause a *lot* of build failures for no particular gain. I don't think it's a good idea. I think it is. Besides fixing potential bugs, else you'll never be able to use gold as the linker. See the already filed bug reports. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ce1ccd1.8010...@debian.org
Re: DSO linking changes for wheezy
On Mon, Nov 15, 2010 at 11:02:57PM +0100, Matthias Klose wrote: > On 14.11.2010 16:06, Roger Leigh wrote: While I understand the rationale for --no-copy-dt-needed-entries for preventing encapsulation violations via indirect linking, I don't agree with the use of --as-needed *at all*. If a library has been explicitly linked in, it shouldn't be removed. This is an issue for fixing in individual packages, not in the toolchain. I can understand on using it on a per-package basis, but not in the actual toolchain defaults. The compiler and linker *should not be second-guessing the user*. This can break perfectly legitimate code making use of ELF constructors and other features which won't be picked out just by looking at symbol usage. >>> >>> People have been claiming that constructors or init section are a >>> possible problem. I have yet to see an example where it breaks. >> >> It's not a very widely used feature. I'm sure it's trivial to make >> such a test case. Portable software tends not to make use of ELF- >> specific features like this, but that's not an excuse for breaking >> perfectly legitimate code. >> >> But whether or not there are real life examples, --as-needed is >> *fundamentally wrong*. It's deliberately *not doing what the user >> requested*, and to make that misfeature the system-wide default >> would be entirely inappropriate. If a package wishes to make use >> of such a feature after understanding the implications, then they >> are free to do so. But to make it the default--I don't think that's >> a technically sound decision. > > maybe, and fix it in N - ~100 packages? Or fix the ~100 packages? The > point of injection is for discussion. I would prefer having this set in > dpkg-buildflags, and then disabled by these ~100 packages. Note that > this is probably the same like modifying the N - ~100 packages, as almost > no package respects dpkg-buildflags yet. What's the actual problem --as-needed is trying to solve? The answer is mainly unwanted libraries being linked in as a result of using pkg-config (and various other -config variants), though there are other, lesser, culprits. The pkg-config .pc files for gtk, gnome and other libraries add in many libraries, most of which aren't typically needed. The solution: fix the .pc files! Using --as-needed is merely papering over the actual root problem. It "fixes" the symptoms, but it's not addressing the actual cause. The number of packages providing broken .pc files is not large, and the number breaking due to relying on this brokenness is likely just as small. Other libraries being linked unnecessarily can be removed on a per-package basis. lintian is warning about this, so most developers should be aware of the problem. Damaging our toolchain to work around buggy build scripts is wrong; we should just fix the scripts! Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: DSO linking changes for wheezy
> On 15.11.2010 07:16, Roland McGrath wrote: > yes, OpenSuse is using --as-needed, but not --no-add-needed. That is a pretty nutty choice. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2010111535.2b3672c...@topped-with-meat.com
Re: DSO linking changes for wheezy
On Mon, Nov 15, 2010 at 11:02:57PM +0100, Matthias Klose wrote: > maybe, and fix it in N - ~100 packages? Or fix the ~100 packages? > The point of injection is for discussion. I would prefer having > this set in dpkg-buildflags, and then disabled by these ~100 > packages. Note that this is probably the same like modifying the N > - ~100 packages, as almost no package respects dpkg-buildflags yet. Did you actually do a build test? Kind regards Philipp Kern signature.asc Description: Digital signature
Re: DSO linking changes for wheezy
On 14.11.2010 16:06, Roger Leigh wrote: While I understand the rationale for --no-copy-dt-needed-entries for preventing encapsulation violations via indirect linking, I don't agree with the use of --as-needed *at all*. If a library has been explicitly linked in, it shouldn't be removed. This is an issue for fixing in individual packages, not in the toolchain. I can understand on using it on a per-package basis, but not in the actual toolchain defaults. The compiler and linker *should not be second-guessing the user*. This can break perfectly legitimate code making use of ELF constructors and other features which won't be picked out just by looking at symbol usage. People have been claiming that constructors or init section are a possible problem. I have yet to see an example where it breaks. It's not a very widely used feature. I'm sure it's trivial to make such a test case. Portable software tends not to make use of ELF- specific features like this, but that's not an excuse for breaking perfectly legitimate code. But whether or not there are real life examples, --as-needed is *fundamentally wrong*. It's deliberately *not doing what the user requested*, and to make that misfeature the system-wide default would be entirely inappropriate. If a package wishes to make use of such a feature after understanding the implications, then they are free to do so. But to make it the default--I don't think that's a technically sound decision. maybe, and fix it in N - ~100 packages? Or fix the ~100 packages? The point of injection is for discussion. I would prefer having this set in dpkg-buildflags, and then disabled by these ~100 packages. Note that this is probably the same like modifying the N - ~100 packages, as almost no package respects dpkg-buildflags yet. Matthias -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ce1ae11.2010...@debian.org
Re: DSO linking changes for wheezy
On 15.11.2010 07:16, Roland McGrath wrote: airlied_, does Fedora use --as-needed by default? Fedora 14 too? mattst88: yes The naming of the options makes people easily confused. --no-add-needed is the only option Fedora's gcc passes. yes, OpenSuse is using --as-needed, but not --no-add-needed. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ce1acb3.1090...@debian.org
Re: DSO linking changes for wheezy
> airlied_, does Fedora use --as-needed by default? Fedora 14 too? > mattst88: yes The naming of the options makes people easily confused. --no-add-needed is the only option Fedora's gcc passes. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101115061626.8f8b22c...@topped-with-meat.com
Re: DSO linking changes for wheezy
On Sun, Nov 14, 2010 at 8:40 PM, Adam Goode wrote: > On 11/14/2010 12:42 PM, Matt Turner wrote: >> Please ignore me if I've misunderstood the situation, firstly. >> >> Both Fedora and Gentoo are using --as-needed by default now. And from >> what I've read (google: site:blog.flameeyes.eu as-needed) --as-needed >> is certainly useful and prevents lots of unnecessary problems. >> > > I don't believe Fedora (as of 14) is using --as-needed. airlied_, does Fedora use --as-needed by default? Fedora 14 too? mattst88: yes -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikfcxtsqs4cz2of7ny7xyuev3bbgpdjko_sr...@mail.gmail.com
Re: DSO linking changes for wheezy
On 11/14/2010 12:42 PM, Matt Turner wrote: > Please ignore me if I've misunderstood the situation, firstly. > > Both Fedora and Gentoo are using --as-needed by default now. And from > what I've read (google: site:blog.flameeyes.eu as-needed) --as-needed > is certainly useful and prevents lots of unnecessary problems. > I don't believe Fedora (as of 14) is using --as-needed. Adam signature.asc Description: OpenPGP digital signature
Re: DSO linking changes for wheezy
On Sun, Nov 14, 2010 at 10:06 AM, Roger Leigh wrote: > On Sun, Nov 14, 2010 at 01:51:49PM +0100, Kurt Roeckx wrote: >> On Sun, Nov 07, 2010 at 04:19:10PM +, Roger Leigh wrote: >> > On Fri, Oct 29, 2010 at 03:43:57PM +0200, Matthias Klose wrote: >> > > For wheezy I'm planning to change the linking behaviour for DSOs (turning >> > > on --as-needed and --no-copy-dt-needed-entries. The rationale is >> > > summarized in http://wiki.debian.org/ToolChain/DSOLinking. I would like >> > > to know about issues with these changes on some of the Debian ports, and >> > > if we need to disable one of these changes on some port. >> > >> > While I understand the rationale for --no-copy-dt-needed-entries for >> > preventing encapsulation violations via indirect linking, I don't agree >> > with the use of --as-needed *at all*. If a library has been explicitly >> > linked in, it shouldn't be removed. This is an issue for fixing in >> > individual packages, not in the toolchain. >> > >> > I can understand on using it on a per-package basis, but not in the >> > actual toolchain defaults. The compiler and linker *should not be >> > second-guessing the user*. This can break perfectly legitimate code >> > making use of ELF constructors and other features which won't be >> > picked out just by looking at symbol usage. >> >> People have been claiming that constructors or init section are a >> possible problem. I have yet to see an example where it breaks. > > It's not a very widely used feature. I'm sure it's trivial to make > such a test case. Portable software tends not to make use of ELF- > specific features like this, but that's not an excuse for breaking > perfectly legitimate code. > > But whether or not there are real life examples, --as-needed is > *fundamentally wrong*. It's deliberately *not doing what the user > requested*, and to make that misfeature the system-wide default > would be entirely inappropriate. If a package wishes to make use > of such a feature after understanding the implications, then they > are free to do so. But to make it the default--I don't think that's > a technically sound decision. Please ignore me if I've misunderstood the situation, firstly. Both Fedora and Gentoo are using --as-needed by default now. And from what I've read (google: site:blog.flameeyes.eu as-needed) --as-needed is certainly useful and prevents lots of unnecessary problems. "It's deliberately *not doing what the user requested*" -> In the case of Gentoo, the problem is that the user himself isn't specifically requesting all these libraries are linked in. They're specified by the build system or .la files. If the user wants lots of libraries linked in unnecessarily, then he can turn off --as-needed. So, I guess I'm not understanding what the problem with --as-needed is, exactly. Thanks, Matt -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktim6q3wvkh_crahhs_5rnkakq6rnfvfksmcpt...@mail.gmail.com
Re: DSO linking changes for wheezy
On Sun, Nov 14, 2010 at 01:19:08PM +0100, Julien Cristau wrote: > On Fri, Oct 29, 2010 at 15:43:57 +0200, Matthias Klose wrote: > > > For wheezy I'm planning to change the linking behaviour for DSOs > > (turning on --as-needed and --no-copy-dt-needed-entries. The > > rationale is summarized in > > http://wiki.debian.org/ToolChain/DSOLinking. I would like to know > > about issues with these changes on some of the Debian ports, and if > > we need to disable one of these changes on some port. > > > --no-add-needed sounds like it'll cause a *lot* of build failures for no > particular gain. I don't think it's a good idea. This change will definitely cause a lot of link failures; having some concrete numbers to determine how many would be quite useful here, e.g. from an archive-wide rebuild. Example failure case: #593876 libboost-filesystem-dev: Undeclared indirect dependency of boost_filesystem on boost_system causes link failure While --no-copy-dt-needed-entries does "fix" programs depending upon indirect linkage, this is something we've been relying on for over a decade and has worked quite well in practice. While strict correctness is nice to have, and I've already fixed my programs to work with strict linking, I'm not entirely sure why indirect linking is that bad in practice. Note that in the above Boost example, you get caught out just due to some inline functions in headers resulting an a completely unexpected additional dependency, so the need for linking is there, but would have otherwise been happily satisfied indirectly. Also, it means that the user of a library needs to be intimately aware of its internals which is not good. If the Boost filesystem library changes how it works but without changing its public interface, I could be screwed again in six months time. This is partly the fault of Boost for exposing its internals in its headers, but disallowing indirect linking make it worse. Overall, it could be for the best, but it will be painful initially. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: DSO linking changes for wheezy
On Sun, Nov 14, 2010 at 01:51:49PM +0100, Kurt Roeckx wrote: > On Sun, Nov 07, 2010 at 04:19:10PM +, Roger Leigh wrote: > > On Fri, Oct 29, 2010 at 03:43:57PM +0200, Matthias Klose wrote: > > > For wheezy I'm planning to change the linking behaviour for DSOs (turning > > > on --as-needed and --no-copy-dt-needed-entries. The rationale is > > > summarized in http://wiki.debian.org/ToolChain/DSOLinking. I would like > > > to know about issues with these changes on some of the Debian ports, and > > > if we need to disable one of these changes on some port. > > > > While I understand the rationale for --no-copy-dt-needed-entries for > > preventing encapsulation violations via indirect linking, I don't agree > > with the use of --as-needed *at all*. If a library has been explicitly > > linked in, it shouldn't be removed. This is an issue for fixing in > > individual packages, not in the toolchain. > > > > I can understand on using it on a per-package basis, but not in the > > actual toolchain defaults. The compiler and linker *should not be > > second-guessing the user*. This can break perfectly legitimate code > > making use of ELF constructors and other features which won't be > > picked out just by looking at symbol usage. > > People have been claiming that constructors or init section are a > possible problem. I have yet to see an example where it breaks. It's not a very widely used feature. I'm sure it's trivial to make such a test case. Portable software tends not to make use of ELF- specific features like this, but that's not an excuse for breaking perfectly legitimate code. But whether or not there are real life examples, --as-needed is *fundamentally wrong*. It's deliberately *not doing what the user requested*, and to make that misfeature the system-wide default would be entirely inappropriate. If a package wishes to make use of such a feature after understanding the implications, then they are free to do so. But to make it the default--I don't think that's a technically sound decision. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: DSO linking changes for wheezy
On Sun, Nov 07, 2010 at 04:19:10PM +, Roger Leigh wrote: > On Fri, Oct 29, 2010 at 03:43:57PM +0200, Matthias Klose wrote: > > For wheezy I'm planning to change the linking behaviour for DSOs (turning > > on --as-needed and --no-copy-dt-needed-entries. The rationale is > > summarized in http://wiki.debian.org/ToolChain/DSOLinking. I would like > > to know about issues with these changes on some of the Debian ports, and > > if we need to disable one of these changes on some port. > > While I understand the rationale for --no-copy-dt-needed-entries for > preventing encapsulation violations via indirect linking, I don't agree > with the use of --as-needed *at all*. If a library has been explicitly > linked in, it shouldn't be removed. This is an issue for fixing in > individual packages, not in the toolchain. > > I can understand on using it on a per-package basis, but not in the > actual toolchain defaults. The compiler and linker *should not be > second-guessing the user*. This can break perfectly legitimate code > making use of ELF constructors and other features which won't be > picked out just by looking at symbol usage. People have been claiming that constructors or init section are a possible problem. I have yet to see an example where it breaks. Kurt -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101114125148.ga26...@roeckx.be
Re: DSO linking changes for wheezy
On Fri, Oct 29, 2010 at 15:43:57 +0200, Matthias Klose wrote: > For wheezy I'm planning to change the linking behaviour for DSOs > (turning on --as-needed and --no-copy-dt-needed-entries. The > rationale is summarized in > http://wiki.debian.org/ToolChain/DSOLinking. I would like to know > about issues with these changes on some of the Debian ports, and if > we need to disable one of these changes on some port. > --no-add-needed sounds like it'll cause a *lot* of build failures for no particular gain. I don't think it's a good idea. Cheers, Julien signature.asc Description: Digital signature
Re: DSO linking changes for wheezy
On Fri, Oct 29, 2010 at 03:43:57PM +0200, Matthias Klose wrote: > For wheezy I'm planning to change the linking behaviour for DSOs (turning > on --as-needed and --no-copy-dt-needed-entries. The rationale is > summarized in http://wiki.debian.org/ToolChain/DSOLinking. I would like > to know about issues with these changes on some of the Debian ports, and > if we need to disable one of these changes on some port. While I understand the rationale for --no-copy-dt-needed-entries for preventing encapsulation violations via indirect linking, I don't agree with the use of --as-needed *at all*. If a library has been explicitly linked in, it shouldn't be removed. This is an issue for fixing in individual packages, not in the toolchain. I can understand on using it on a per-package basis, but not in the actual toolchain defaults. The compiler and linker *should not be second-guessing the user*. This can break perfectly legitimate code making use of ELF constructors and other features which won't be picked out just by looking at symbol usage. Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature