Description of problem: I need a static lib of libXt to be able to link statically against the cernlib. (The cernlib needs libXt through lesstif). Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Remind me why you need to link cernlib statically.
The cernlib is very useful in numerical experiments where statically linking enhance portability a lot, while the drawbacks are not relevant (security, dlopening, nss and so on). I won't bother you with the details but this is a real world need for me. In fact the cernlib parts that depends on lesstif and X libs are not necessarily those that are that much interesting for numerical experiment, but the libs weren't split, so the scripts that drives compilation brings in the parts depending on lesstif and X libs.
And it's not okay for you to link cernlib statically, but the X libs dynamically? (No, I don't buy the portability argument.)
It may be possible to link some libs dynamically and others statically and use some compiler flags to use the compiler static libs, but it is much simpler to add -static to the compiler command line and be done. I haven't seen, in the g77 documentation how to use the static compiler libs. For the portability, just imagine that I want to run a program compiled on a fedora box on another linux that don't have the X libs installed. This is an extreme examples, but there are also gfortran compiled program on a linux without gfortran, the reverse with g77.
*** Bug 239907 has been marked as a duplicate of this bug. ***
*** Bug 239908 has been marked as a duplicate of this bug. ***
*** Bug 239909 has been marked as a duplicate of this bug. ***
*** Bug 239910 has been marked as a duplicate of this bug. ***
Just to make the list of all the libraries which were requested (please, reporter, correct me if I am wrong) -- libXt, libXp, libXext, libXpm, libXaw
See http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryChanges "In general, packagers are strongly encouraged not to ship static libs unless a compelling reason exists."
Isn't my reason not compelling? One cannot build a static executable using the cernlib libraries using the cernlib link script, although it makes perfect sense for many programs since they won't need dynamic linking and are much more portable this way. I can workaround that issue myself since I know the internals of the cernlib packaging, but a randow cernlib user (cernlib users are not random in general, but don't know the cernlib packaging) will be very annoyed not to be able to create static executables.
No, I don't think this reason is compelling. As you say, there is a workaround.
Indeed, but this workaround is only present because I don't follow strictly upstream and use the library split from debian patches. This should be transparent for the user. Ok, I'll modify my patch for the cernlib-static link script such as not bring in the library linked with X when using mathlib and graflib. This could break the user expectations, but anyway. This should be more consistent with the debian cernlib link script, though.
I have modified the cernlib-static such as not bring in the X/lesstif libs in the default case. This may not be backward compatible, but it is what is done in the debian cernlib script, so it kinda makes sense (and it solves my personal use cases). The lesstif or X parts are needed when linking with libgeant321 which is used to compute particles trajectories, so I guess statically compiled X libs would still be useful for the geant321 users, although it is also possible that this lib is deprecated. Same for pawlib/graphlib which are used for data processing and display. I'll reopen this bug or a similar one if I get users complaints.