.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
...)  by brute-forcing through /opt /every time/ I log in (I use su -
alot...). This also makes it bearable to do things like 'echo
- 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?

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

More information about the blfs-support mailing list