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
