[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Fedora-packaging] Re: libtool(.la) archive policy proposal



On Oct 12, 2006, Enrico Scholz <enrico scholz informatik tu-chemnitz de> wrote:

> Alexandre Oliva <aoliva redhat com> writes:
>>>> Revisting the root of evil. What exactly is wrong with not removing
>>>> all *.la files?
>> 
>>> - .la files must be shipped in main package, not in -devel
>> 
>> Only if users of the library rely on libltdl and explicitly refer to
>> the .la files.

> no; when some package contains a dynamic loadable module with .la
> files, this .la file will be used for dependency resolving.

Err...  I don't follow.  Is this any different from the libltdl case I
mentioned above?

> When such a dependency is expressed as

> | dependency_libs='...  /usr/lib/libkickermain.la ...'

> 'libkickermain.la' must be a main package but not in -devel.

Aah, I think I see what you mean.

libfoo.la is a loadable module.

libbar.la is a library in a separate package that libfoo.la was linked
with.

Someone lt_dlopenext()s libfoo, and that fails if libbar.la is not
available.

Is this what you mean?

If you, you're right.  I hadn't considered this case.

That said, if libbar.la had never had its .la file present at libfoo's
build time, libfoo.la couldn't possibly refer to libbar.la.


/me wonders if his reasoning breaks if both libfoo and libbar are in
the same package.  In this case, libfoo.la might refer to libbar.la,
indeed.  But then, since they're both part of the same build, that's a
single spec file, and one might easily arrange to keep libbar.la
installed.  So indeed there may have to be an exception to the rule
for this case.


Unless you also remove the libfoo.la, and call it a bug if any package
that relies on lt_dlopen("libfoo.la"), instead of
lt_dlopenext("libfoo").  Then, you can do away with the .la files even
in this case.

Right?  Or am I still missing anything?

> Because a library can be linked against arbitrary .la modules, a library
> must either remove .la files completely or ship them in the main package.

I don't think this follows.  It does hold that they probably ought to
be in the same package, or arranged such that the package containing
libfoo.la requires that containing libbar.la.  But I still fail to see
a need for the .la file in the main package, except for
lt_dlopen("libfoo.la")

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
Secretary for FSF Latin America        http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva {redhat com, gcc.gnu.org}
Free Software Evangelist  oliva {lsd ic unicamp br, gnu.org}


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]