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):
Steps to Reproduce:
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
"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.