https://bugzilla.novell.com/show_bug.cgi?id=481502 Philipp Thomas <pth@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|pth@novell.com |nadvornik@novell.com -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=481502 User er258@cam.ac.uk added comment https://bugzilla.novell.com/show_bug.cgi?id=481502#c3 --- Comment #3 from Edward Rosten <er258@cam.ac.uk> 2009-03-03 11:11:36 MST --- I develop in a SUSE system, and run my code on several clusters. Some of the these use an older version of SUSE, others use different Linux distributions. By far the easiest way to run my binaries reliably on these systems is to compile it as a static executable. I am also working in collaboration with a number of other people worldwide. It saves my collaborators considerable time if I can ship them working binaries which they can run. Since I can not rely on them having the same library versions (or even 32 bit versions at all), it saves us all considerable time if I can simply send them a static executable. Why are static libraries being phased out? They are harmless to anyone who does not opt for them and invaluable in certain circumstances. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=481502 User er258@cam.ac.uk added comment https://bugzilla.novell.com/show_bug.cgi?id=481502#c5 --- Comment #5 from Edward Rosten <er258@cam.ac.uk> 2009-03-03 11:52:04 MST ---

...

They are harmless to anyone who does not opt for them and invaluable in certain circumstances.

http://people.redhat.com/drepper/no_static_linking.html additionally with the killer arguments in that document, we have to ensure that

The arguments are not killer arguments. They are correct in many cases. Except, crucially the last argument: "The often used argument about statically linked apps being more portable (i.e., can be copied to other systems and simply used since there are no dependencies) is not true since every non-trivial program needs dynamic linking at least for one of the reasons mentioned above. And dynamic linking kills the portability of statically linked apps." which is a variation of the "no true Scotsman" fallacy. My programs are not trivial, they simply don't do anything which requires dynamic linking. I would strongly suspect that this is the case for a lot of scientific code: it loads some data, churns through a bunch of arrays for a number of hours, writes some data and then quits. The points don't apply, because the code is frequently rebuilt, security isn't an issue, a small number of instances run (binary size in memory doesn't matter), no complex features of libc are used and debugging is performed on the local machine using a dynamically linked executable. The end result is that running on clusters becomes much more difficult, since with static linking, a rather more complex and error prone distribution process is required.

1) packages that we ship do not use them, when you have a few, it is easy, when you have thousands it is a lost battle.

I was under the impression that dynamic linking was always used unless specified manually during the build process, but I may be mistaken.

You will have to live with it.

That is a shame. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=481502 User crrodriguez@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=481502#c7 --- Comment #7 from Cristian Rodríguez <crrodriguez@novell.com> 2009-03-03 12:16:58 MST --- see also what others are doing http://fedoraproject.org/wiki/Packaging/Guidelines#Packaging_Static_Librarie... Doing this also provides other side-effect advantages like much reduced packages size, bandwidth saving, less IO in the buildservers.. reduced compilation time as when static libraries are there libtool has to create separate objects for PIC and non-PIC code...there are probably many other advantages that Im missing here too ;) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=481502 User er258@cam.ac.uk added comment https://bugzilla.novell.com/show_bug.cgi?id=481502#c9 --- Comment #9 from Edward Rosten <er258@cam.ac.uk> 2009-03-03 16:01:17 MST ---

This is because you are doing it wrong, since some time we are providing you tools to do just that in automated way, if your software is opensource, you can use the opensuse buildservice to fully automate this task and just add a repository to your machines and install updated software from there.. now if your software is propietary, you can run a private obs-server instance, it is opensource, we can also assist you in setting it up in the opensuse-buildservice mailing list.

The buildserver looks to be a good solution for quite a lot of tasks, but I doubt I can get it installed on all the clusters I use. Also, as far as I can tell, it builds whole packages, which will require root prelidges to install. Most people whi I know who use clusters use quite rapidly changing hand-hacked code, so I'm not sure it's the right tool in this case.

Doing this also provides other side-effect advantages like much reduced packages size, bandwidth saving, less IO in the buildservers.. reduced compilation time as when static libraries are there libtool has to create separate objects for PIC and non-PIC code...there are probably many other advantages that Im missing here too ;)

I can see that. I also take the point that producing -static RPMs is much more work. I had a go, and it required considerably more work than removing the .a, though it is fairly mindless work. Will you accept patches to spec files? I suspect that if the process is user driven then a quite small set of libraries will end up with static versions: only those for which it is useful. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.