[Top][All Lists]

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

Re: libtool 1.5 tag woes (static/shared)

From: Sander Niemeijer
Subject: Re: libtool 1.5 tag woes (static/shared)
Date: Wed, 19 Nov 2003 11:34:42 +0100

Bringing the discussion back to the list.

Begin forwarded message:

Hi Paolo,

I think I start to understand it now. When I was writing my e-mail, the libtool mail archive site was also not reachable, but today it was working again, so I have been able to do some catching up. As you already stated somewhere documentation about tags is rather non-existent, so forgive me when I'm making wrong assumptions here.

If I understand you correctly then you are solving the -fomit-frame-pointer problem by creating a special tag which you will use by calling libtool with the --tag=<yourtag> option when compiling/linking your library. Although this will surely do the job I don't think it would be a really clean solution to the problem. The fact that you would have to build your own version of the libtool script (including this special tag) means that it won't be possible to build the shared/static library pair you want with the globally available libtool script. What I think would be a more preferable approach is to have libtool command line options available that would let you provide additional options for static library compilation/linking and/or additional options for shared library compilation/linking. Something like: libtool -extra-shared-flags='-fomit-frame-pointer' --mode=link LINK-COMMAND

Yes, I had thought about it and also had implemented it with exactly this name, but this would lead to a proliferation of flags that I don't like. You are modifying the configuration, so a tag is the appropriate place for this.

As far as I can see specifying shared/static library specific compilation/linking options is not changing the configuration. Especially if you only want to do this for one of your many libraries in your package. If you wanted to have an additional linking option for both your static and shared version of your library you would add it as an (AM_)LDFLAGS item if you use automake or just add it to the libtool link command line. If you don't see this as changing the configuration, then wanting to add a link option for just the static or just the shared version of a library shouldn't be considered a configuration change either IMHO. I can understand that you may have some personal preference against having more flags, but if it is only personal preference, then maybe something has to give. I would opt for a 'best design' approach, which in my opinion would be to have the one or two extra libtool arguments introduced and not trying to 'pollute' the tags architecture of libtool with non-language related tags. But then again I'm no libtool tags expert, so maybe my 'pollute' statement is way off.

Actually, I don't think that anyone uses the global libtool script :-)


Going for such an approach of course also eliminates your 'copying tags in an upward-compatible way' problem.


On 18-nov-03, at 20:42, Paolo Bonzini wrote:

In a previous posting you opted for reverting the -static/-shared
functionality and in the posting quoted below you are opting to make
the disable-static/disable-shared tags obsolete.

The disable-static/disable-shared *tags* are not the *configure options*. In the older post I proposed to revert the -static/-shared functionality not because I fail to appreciate it, but because it has a duplicate: indeed, my request for a -static option for libraries was dropped two or three years ago :-) and instead, I was pointed to the disable-shared tag which was available in the then active multi-language branch, which became libtool 1.5

In a more recent post, after having developed further my idea of using tags for changes to the configurations, and not only for languages, I noted that my macro has an asymmetry: due to the way these two tags are implemented, they would not work with my macro. Since an alternative was added in the meanwhile, I proposed to obsolete them (also as a shortcut to keep my patch simple and easily reviewable/updatable) instead of reverting Ralph's patch.

I do recognize I am somewhat contradicting myself, in that I am proposing to obsolete the only precedent for "tags used to change the configuration". However, the real problem is that the two special tags are implemented
specially and are not known to the configure script.



reply via email to

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