After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 73655 - libtest* should not be installed in $(libdir)
libtest* should not be installed in $(libdir)
Status: RESOLVED FIXED
Product: atk
Classification: Platform
Component: gail
0.9
Other All
: Normal normal
: ---
Assigned To: padraig.obriain
padraig.obriain
Depends on:
Blocks:
 
 
Reported: 2002-03-06 00:55 UTC by James Henstridge
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: 2.0



Description James Henstridge 2002-03-06 00:55:08 UTC
Currently gail (and to a lesser extent, atk) install a large number of
libtest* libraries into $(libdir).

As far as I can tell, these libraries are supposed to be loaded via
GTK_MODULES, and not linked to.  In that case, they should probably be put
in the gtk modules directory, which currently is:
  $(libdir)/gtk-2.0/2.0.0/modules

(maybe $(libdir)/gtk-2.0/modules is okay as well).

Secondly, the modules should be built with the "-module -avoid-version"
libtool flags (currently all the ATK ones all have version suffixes).  This
should reduce the clutter in $(libdir), and make sure the modules don't get
mixed up with real libraries.
Comment 1 James Henstridge 2002-03-06 00:57:57 UTC
that last message should have read "the gail libtest* modules all have
version suffixes".  The ATK libtest* modules don't have version sufixes.
Comment 2 Owen Taylor 2002-03-06 01:01:37 UTC
I've removed the atk ones from the install temporarily 
(put them as noinst_LTLIBRARIES).
Comment 3 James Henstridge 2002-03-06 01:22:47 UTC
This should also cover libgail itself and libferret as well ...
Comment 4 James Henstridge 2002-03-06 01:29:57 UTC
Note that using noinst will probably make the modules completely
unusable.  If libtool doesn't think a library will be installed, it
creates one of its .al files instead of a .so, which is a static
library of PIC compiled objects, which is useless for dlopen().
Comment 5 padraig.obriain 2002-03-06 10:50:01 UTC
I have noticed that the directories $(libdir)/gtk-2.0/2.0.0/modules
and $(libdir)/gtk-2.0/modules currently do not exist. Should it be the
responsibility of the GTK+ installation to create these directories?
Comment 6 James Henstridge 2002-03-06 11:35:29 UTC
The directories are not created by default by the gtk+ install, but it
should check in those directories for modules.
Comment 7 padraig.obriain 2002-03-06 11:47:27 UTC
My concern is with the symmetry of adding and removing packages.
If my package is going to install a file in a directory I am not
responsible for, I would expect that the directory should have been
created with the correct permissions, rather than me having to guess
what permissions to create the directory.

If I create a directory when adding a package I would expect to remove
the directory when removing the package. Clearly, this should not
happen in this case as other packages may have installed files in that
directory. 

Perhaps I should log this against GTK+ rather than discussing it here.
Comment 8 James Henstridge 2002-03-06 12:07:27 UTC
Okay.  I understand your concerns.  Note that gtk-engines falls into a
similar situation here -- it creates the engines subdir for the theme
engines.

Whatever gets decided for the modules dir should probably be mirrored
for the engines directory.

Either way, gail won't have to care about actual creation of the dir.
 Automake will call mkinstalldir to create the directory if it is missing.
Comment 9 padraig.obriain 2002-03-08 12:44:20 UTC
I have changed the gail build to not install the modules built in the
test directory except for ferret. The two modules which are bult
libgail and libferret are installed ain $(libdir).gtk-2.0/modules
directory and are bult with -module.

I am not sure that I want to remove the version number for libgail.

Can this bug be closed now?
Comment 10 James Henstridge 2002-03-09 02:41:23 UTC
I guess so.  The library version numbers don't really hurt, but they
also don't really help (unless there are cases where an app would
explicitly linky against libgail?).  In the normal use, when someone
sets GTK_MODULES="gail:ferret" or something like that, the version
numbers aren't even used.