Re: New ghc6 needs manual bootstrapping for C++ ABI/libgmp3 transition.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 LaMont Jones <[EMAIL PROTECTED]> writes: > On Thu, Sep 01, 2005 at 11:28:10PM +0200, Kurt Roeckx wrote: >> Because of the C++ ABI transition, ghc6 needs to be rebuild against >> the new libgmp3c2. To build it, follow the instruction in >> debian/bootstrap-extracted. > > Done. Btw, if I'm silly enough to try to rebuild ghc6 using the > newly-built ghc6, then haddock is FTBFS (after ghc6, build happy, > then try haddock...): I was silly enough... When I did it for powerpc, I bootstrapped ghc6, then built happy, haddock and haskell-utils, then rebuilt ghc6 with sbuild and my new packages. Did you patch for #300385 and #316657? Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFDH0FVVcFcaSW/uEgRAunRAJ9LBUnq11HoFLLpm9r6FRl5eNd5BwCfRlwc b9jw2wfBOspx9yTrDp9Ntlk= =o/yH -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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
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 +0000, 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 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 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 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 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: Sysvinit error on apt-get update
On Mon, Dec 19, 2011 at 10:04:34PM +0100, pe...@kahn.nu wrote: > Hi and thanks for all your hard work. > I have just tried updating my debian hurd install and dpkg fails with the > following error: > > dpkg: error processing > /var/cache/apt/archives/sysvinit_2.88dsf-16_hurd-i386.deb (--unpack): > trying to overwrite '/sbin/halt', which is also in package hurd 20111206-1 > configured to not write apport reports > Processing triggers for man-db ... > Errors were encountered while processing: > /var/cache/apt/archives/sysvinit_2.88dsf-16_hurd-i386.deb > E: Sub-process /usr/bin/dpkg returned an error code (1) > > (I'm sorry if this text contains typos, i have only got one screen and > wrote the text while watching it on my hurd computer.) > > Does anyone have any idea on how to get past this? It's likely a bug in one of sysvinit or hurd packages, since both can't provide the same file. Did the older sysvinit package provide /sbin/halt? If looks like they did not according to debian/rules. While the packaging was updated in -16, this logic is still present. But it's obviously not working. It would be good if a Hurd porter could perhaps see why--I can't see anything obviously wrong.. 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. -- 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/20111219225854.gc5...@codelibre.net
