[Top][All Lists]

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

Re: Absolute paths generated by libtool.

From: Benoit Sigoure
Subject: Re: Absolute paths generated by libtool.
Date: Tue, 14 Nov 2006 19:17:37 +0100
User-agent: Internet Messaging Program (IMP) H3 (4.0.2)

Quoting Ralf Wildenhues <address@hidden>:

Hello Benoit,

Hi, thanks for your quick reply.

* Benoit Sigoure wrote on Tue, Nov 14, 2006 at 05:35:03PM CET:

My final questions are: is this necessary on Windows? Can't you keep the
relative path?

Not easily.

That's weird though because if you look closely at the line printed by libtool,
it reads:
Note that the libfsm_xml_parser is printed twice, once with an absolute path
(which I don't want) once with a relative path (which I do want).

Now I really have no idea about libtool's logic and internals but here is an
educated guess:
libtool is invoked with the relative paths to the two .la. It reads them in
order to know what are the dependencies. The depends on the
libfsm_xml_parser and has the following in its .la:
-Lc:/Qt/4.2.1/lib -lqtmain -lQtXml4 -lQtGui4 -lQtCore4'

Here is the address@hidden full path. Now libtool recursively reads the and adds the absolute path to the .a.

Next, libtool treats the other .la it was given on the command line -- which
turns out to be the same as before (for libfsm_xml_parser) which leads it to
add a relative path to libfsm_xml_parser.a (because the .la was provided with a
relative path).

Alright so I see two possible ways out:
Before finalizing the command, libtool looks at all the libs and finds out that
libfsm_xml_parser.a appears twice (once with an absolute path and once with a
relative path) and preferes to drop the one with the absolute path. This is
non-trivial to implement (knowing that two different paths point in fact to the
same file) and requires more efforts.

Another solution would be: why not encode the relative path to in ? After all, where does this path come from?
The says that LIBADD is xml_parser/
Why not keep a relative path? Given the path to, we can find that of using a simple concatenation. This is reasonably easy to
implement, isn't it? It requires very little changes and is not likely to break anything right? (I'm not a libtool expert so I'm just guessing this, I know that
libtool internals are rather obfusc^H^H^H^H^H^Hcomplicated).

What do you think about this?

SIGOURE Benoit aka Tsuna
 /EPITA\ Promo 2008, LRDE

reply via email to

[Prev in Thread] Current Thread [Next in Thread]