Bug 239888 (x-static-lib-cern) - please ship a static lib
Summary: please ship a static lib
Alias: x-static-lib-cern
Product: Fedora
Classification: Fedora
Component: libXt   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Søren Sandmann Pedersen
QA Contact:
: 239907 239908 239909 239910 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2007-05-11 22:26 UTC by Patrice Dumas
Modified: 2018-04-11 11:26 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-05-22 14:44:14 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Patrice Dumas 2007-05-11 22:26:34 UTC
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:
Actual results:

Expected results:

Additional info:

Comment 1 Adam Jackson 2007-05-16 22:25:17 UTC
Remind me why you need to link cernlib statically.

Comment 2 Patrice Dumas 2007-05-16 22:31:13 UTC
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.

Comment 3 Adam Jackson 2007-05-17 15:02:39 UTC
And it's not okay for you to link cernlib statically, but the X libs dynamically?

(No, I don't buy the portability argument.)

Comment 4 Patrice Dumas 2007-05-20 23:08:25 UTC
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.

Comment 5 Matěj Cepl 2007-05-22 14:23:46 UTC
*** Bug 239907 has been marked as a duplicate of this bug. ***

Comment 6 Matěj Cepl 2007-05-22 14:24:19 UTC
*** Bug 239908 has been marked as a duplicate of this bug. ***

Comment 7 Matěj Cepl 2007-05-22 14:26:47 UTC
*** Bug 239909 has been marked as a duplicate of this bug. ***

Comment 8 Matěj Cepl 2007-05-22 14:27:37 UTC
*** Bug 239910 has been marked as a duplicate of this bug. ***

Comment 9 Matěj Cepl 2007-05-22 14:29:33 UTC
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

Comment 10 Søren Sandmann Pedersen 2007-05-22 14:44:14 UTC


"In general, packagers are strongly encouraged not to ship static libs unless a
compelling reason exists."

Comment 11 Patrice Dumas 2007-05-22 17:26:35 UTC
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.

Comment 12 Søren Sandmann Pedersen 2007-05-22 18:21:48 UTC
No, I don't think this reason is compelling. As you say, there is a workaround.

Comment 13 Patrice Dumas 2007-05-22 19:14:32 UTC
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.

Comment 14 Patrice Dumas 2007-05-23 07:35:58 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.