Re: Linking shared libraries with -lc
On Fri, 2 Jan 1998, Richard Braakman wrote: I made a list of packages that include shared libraries for which ldd says statically linked. I plan to use this list to automatically generate bug reports (about 50). However, I am unsure of the text to use. This is my first try: [snip] First of all, thanks for collecting all the infos! Basically, I agree with you. However, I think we should stick to the usual procedure. That is, we should prepare a policy change which will then be discussion on debian-policy and included in the next policy weekly posting for approval. After that, the policy manual is changed and you could start filing bug reports. Everything else is likely to result into big flame wars. (Maintainers usually don't like to see bugs reported against their packages unless you refer to the policy manual :-) Anyways, the bug report should probably not contain that much information. The info should go into the policy manual. Then, you just have to refer to section x.x in the bug report. So, if you like, I'd appreciate it if you could come up with a suggestion for the policy text. (If not, then I'll do it when I have time for this.) Thanks in advance, Chris -- Christian Schwarz [EMAIL PROTECTED], [EMAIL PROTECTED], Don't know Perl? [EMAIL PROTECTED], [EMAIL PROTECTED] Visit PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA http://www.perl.com http://fatman.mathematik.tu-muenchen.de/~schwarz/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Linking shared libraries with -lc
On Sat, Jan 03, 1998 at 07:09:38PM +0100, Christian Schwarz wrote: On Fri, 2 Jan 1998, Richard Braakman wrote: [-lc issue] Basically, I agree with you. However, I think we should stick to the usual procedure. That is, we should prepare a policy change which will then be discussion on debian-policy and included in the next policy weekly posting for approval. After that, the policy manual is changed and you could start filing bug reports. IMHO, the link issue itself does not need more discussion; the issue itself has been known for a long time, and nobody has expressed any objections that I can recall. As such, I don't think Richard should wait with filing the bugreports; perhaps he can just put in a details will soon be available in an upgraded policy document. Perhaps the phrasing of this needs discussion, but not the implementation. Don't get me wrong: in general, I'm very much in favour of discussing things before putting them into policy; just in this case, I think that there is already a concensus, and waiting for it to go into policy officially before submitting bugreports just delays implementation. Everything else is likely to result into big flame wars. (Maintainers usually don't like to see bugs reported against their packages unless you refer to the policy manual :-) Hmmm... I've never felt this way; I do feel free to ignore bugs that I don't consider bugs and that don't have to do with policy. Ray -- PATRIOTISM A great British writer once said that if he had to choose between betraying his country and betraying a friend he hoped he would have the decency to betray his country. - The Hipcrime Vocab by Chad C. Mulligan -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Linking shared libraries with -lc
Christian Schwarz wrote: Basically, I agree with you. However, I think we should stick to the usual procedure. That is, we should prepare a policy change which will then be discussion on debian-policy and included in the next policy weekly posting for approval. After that, the policy manual is changed and you could start filing bug reports. Oh. Er. I just sent them out. I think your mail arrived while I was sending them :) I didn't expect this to be a matter of determining policy; I thought that because it was listed in the Upcoming Releases file, it had been decided on before I joined. That's why I didn't wait very long for comments. (I'm impatient because I have a lot of free time this week, and I'll be much more busy next week. I want to get Debian stuff done :-) So, if you like, I'd appreciate it if you could come up with a suggestion for the policy text. (If not, then I'll do it when I have time for this.) I don't think I have the expertise for that. Ray Dassen's version contains many remarks that I can't explain. I just know that it's useful to have the linker warn if you try to link a libc5 library with a libc6 one, especially now that we're building a libc6 release. Richard Braakman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Linking shared libraries with -lc
I made a list of packages that include shared libraries for which ldd says statically linked. I plan to use this list to automatically generate bug reports (about 50). However, I am unsure of the text to use. This is my first try: Package: %s Version: %s This is an automated bugreport. The package %s contains a shared library that should be explicitly linked with the libraries it depends on. Filename: %s Explicit linking of shared libraries has several advantages, the most important of which is that it allows the dynamic linker to detect conflicts between library versions. Every shared library should at least be linked explicitly with libc, by passing -lc to the linker. When this is done, the package should use dpkg-shlibdeps on the shared libraries to generate a correct Depends: line automatically. I would like to add a For more information, see... paragraph to that, but I could not find a reference. I dug up some things from the mailing list, though: From Brian White's Upcoming Debian Releases mailings * Link shared libs against other shared libs instead of static [14] 14 - Link shared libraries themselves against other shared libs, instead of including their code static (e.g. as current S-Lang already does); this can reduce memory use. -- [EMAIL PROTECTED] (J.H.M.Dassen) See H.J. Lu's ELF: From The Programmer's Perspective URL:ftp://tsx-11.mit.edu/pub/linux/packages/GCC/elf.ps.gz for details. From an update Ray Dassen mailed on Sep 23 14 - Link shared libraries themselves against other shared libs, instead of including their code statically. This has several advantages. It allows the linker to warn about mixed libc5/libc6 binaries, and, more general, makes the dependencies of shared libraries themselves more explicit; this should be used in generating the Depends: line of a library package (e.g. through dpkg-shlibdeps). This could prevent subtle bugs resulting from interactions between code (statically included) from incompatible library versions. Also, it can reduce memory use. -- [EMAIL PROTECTED] (J.H.M. Dassen) See H.J. Lu's ELF: From The Programmer's Perspective URL:ftp://tsx-11.mit.edu/pub/linux/packages/GCC/elf.ps.gz for details. From a comment Mark Baker made on Nov 23 * Link shared libs against other shared libs instead of static [14] What you mean is `link shared libs so they contain dependency information'. If you don't do that, ldd says `statically linked' but that's just a very misleading error, since libraries are never statically linked. -- I hope that someone can take this information and straighten it out to turn it into a nice proposal for the policy manual. Richard Braakman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
