Bug 203619 - .so should be in -devel
.so should be in -devel
Product: Fedora
Classification: Fedora
Component: arts (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ngo Than
Depends On:
  Show dependency treegraph
Reported: 2006-08-22 15:02 EDT by Patrice Dumas
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-10-30 06:19:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
support for libdap and fix for hdf (810 bytes, patch)
2006-09-14 11:49 EDT, Patrice Dumas
no flags Details | Diff

  None (edit)
Description Patrice Dumas 2006-08-22 15:02:49 EDT
Description of problem:

There are .so files in arts they should certainly be in 

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Comment 1 Rex Dieter 2006-08-22 22:06:31 EDT
Your assumption that all lib*.so should be in -devel is wrong in this case. 
Many of these are runtime-loadable modules.
Comment 2 Patrice Dumas 2006-08-23 04:35:36 EDT
Indeed, when dlopened .so should be in main package, but in general
shouldn't be in %{_libdir}, but in a subdir. Moreover if they are 
modules that are only runtime they shouldn't have versionning nor 
sonames. And lastly dlopening should be avoided, although there are
indeed valuable uses for plugin systems.

If I'm not wrong, the plugin system in arts is handled
by mcop. So things should be done such that the .la required
by mcop (if I'm not wrong) are in a specific directory, together
with .so link if needed. And then the .so of the modules that
have an api could be only in -devel.

If some application dlopen the arts modules, bypassing
mcop, there should be some .so link available, but not in %_libdir,
but in %_libdir/arts/ or %_libdir/arts-plugins/ for example, 
pointing to ../libarts*.so.0.0.*

This may be more an upstream issue, but maybe could be worked
out at the fedora level. All those .la hanging around in %_libdir 
with hardcoded stuff, although the dynamic linker can do things right
doesn't seems right to me.

Anyway are all the libraries plugins? Aren't artsc, *mcop, and maybe
other simple libraries that should only be linked?
Comment 3 Rex Dieter 2006-08-23 12:29:50 EDT
All good points.  IMO, kde should fix a lot of the issues you raise: blurring
the difference between shared libs and loadable modules, using non-versioned
sonames, and comitting the sin of putting many of them in the same place
(%_libdir).  Unfortunately, these are all upstream issues, that can't be
reasonably addressed here (in Fedora).
Comment 4 Patrice Dumas 2006-08-23 18:09:18 EDT
It is not such a serious issue in kde as a whole, since all
the dirty things are in /usr/lib/kde3, not in %_libdir. At
least for

But arts puts those in %_libdir.
Comment 5 Patrice Dumas 2006-09-14 11:49:53 EDT
Created attachment 136273 [details]
support for libdap and fix for hdf

This fix the hdf4 issue, and add support for dods/libdap.

This should work for devel libdap, for previous FC releases
`dap-config --client-libs` should not be in LDFLAGS
(and shouldn't need to be in LDFLAGS).
Comment 6 Patrice Dumas 2006-09-14 11:51:39 EDT
Sorry for the previous comment and patch, it is for another 
unrelated bug...
Comment 7 Ngo Than 2006-10-30 06:19:33 EST
it's fixed in arts-1.5.5-0.1.fc6 which is available in FC6 update

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