.la files in /opt/Foo

Lennon Cook maguswizardo at gmail.com
Sun Mar 19 23:41:37 PST 2006


On 3/20/06, Carlos Eduardo de Brito Novaes <carlosnov at gmail.com> wrote:
> Em Sábado 18 Março 2006 21:56, Lennon Cook escreveu:
> > And so the question becomes - what would be the best course
> > of action here? Is it safe to just adjust the paths in this file, or
> > would I be better to recompile GTK with glib living in /opt?
> I dont really think it is necessary to recompile anything. I understand that
> if you recompile a package with the same compiler and options, you will get
> the same binary files. Except for the hardcoded paths that seens to exist in
> the real base librarys from glib or the compilers in gcc.
I've ended up deciding to recompile GTK despite the non-necesity of
it, simply because last time I recompiled it, I managed to leave out a
feature I need (SVG support).
Also, I've resolved to use symlinks after all, for a few reasons. Most notably:
- It takes a lot of time out of running /etc/profile if it doesn't
have hundreds of loops and checks in it to determine the path. This
way, I need only to keep the symlinks up to date (and I have a script
to refresh them that I'll run once in a while), rather than setting up
various envvars (PATH, PYTHONPATH, LD_LIBRARY_PATH, PKG_CONFIG_PATH
...)  by brute-forcing through /opt /every time/ I log in (I use su -
alot...). This also makes it bearable to do things like 'echo
$PKG_CONFIG_PATH' .
- Symlinks can be updated in a live system - envvars need to be reset,
and then /every app that needs them/ restarted.
- Packages that *don't* use libtool, and so don't know about the *.la
files, need the -L /foo/bar options passed manually - both for finding
their dependancies, and (much worse) to be found by any package that
happens to depend on them. With symlinks, I just need to have
LD_FLAGS="... -L /Index/Libraries"


> Maybe you can do this to track the changes in the .la files.
>
> I really dont understand the real meaning of .la files, but as I already told,
> I had to change a file in the past to compile a package, and it worked.
The libtool explanation certainly makes sense. I'll look for some
documentation to confirm it, but I think that you were mostly right.

> I wonder if a good automake implementation
> does not need the .la files.
I think that absolutely nothing should need it if you keep your
envvars up-to-date. But the nature of envvars makes this difficult, as
mentioned above.  Now that I'm beggining to understand how it works,
libtool (and, for that matter, pkg-config) strikes me as a horrid
kludge, but I don't think theres any real alternative. My symlinks are
also kludgy, but I believe them to be slightly less so, since they
have the added benifit of not needing packages to know about them to
be useful.

> Are you moving packages like this for any special reason?
The end result is to move to a GoboLinux inspired filesystem heirachy
(although one that is, to my mind, better). Also, I'm trying to learn
something along the way.

> Would you be so kind to report us your sucess?
Certainly.

--
Lennon Victor Cook
"He who receives an idea from me receives without lessening, as he who
lights his candle at mine receives light without darkening" - Thomas
Jefferson



More information about the blfs-support mailing list