Re: libtool versioning

[Peter Rosin]

Den 2010-05-03 22:03 skrev Ralf Wildenhues:

* Jef Driesen wrote on Mon, May 03, 2010 at 08:24:09PM CEST:

Yes, I have read the libtool manual, but it doesn't contain much
info about the resulting filename. Most of the info is about the
c:r:a scheme for input, not the output.


Yes, because the output file name is a per-system detail that you should
not have to care about.


#  1. Start with version information of `0:0:0' for each libtool library.
#  2. Update the version information only immediately before a public
# release of your software. More frequent updates are unnecessary, and
# only guarantee that the current interface number gets larger faster.
#  3. If the library source code has changed at all since the last update,
# then increment revision (`c:r:a' becomes `c:r+1:a').
#  4. If any interfaces have been added, removed, or changed since the last
# update, increment current, and set revision to 0.
#  5. If any interfaces have been added since the last public release, then
# increment age.
#  6. If any interfaces have been removed since the last public release,
# then set age to 0.


Shouldn't step #6 included "changed" as well as "removed"? If you
change the interface (for example modifying function parameters),
backwards compatibility is broken too. But only "removed" is listed
here.


Well, it is listed in step 4 already.


Sure, but if interfaces have been changed, but not removed, the
algorithm stops at step #4,


Read the algorithm without any implicit stops in mind, and it will work.

Anyway, your point is good that this is hard to understand, and we've
addressed that in git master.


Errrm, is that really so? I tend to agree with Jef here...

The algorithm *could* be interpreted such that e.g. the interface change
"int foo(void)" -> "int foo(int)" is an interface addition of int foo(int)
and an interface remove of int foo(void), thus triggering both #5 and #6.
But in that case "changed" need not be mentioned in #4 either. So, because
"changed" is mentioned in #4, it also needs to be explicitly mentioned
in #6.

Or what am I missing?

Cheers,
Peter

--
They are in the crowd with the answer before the question.
> Why do you dislike Jeopardy?


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: libtool versioning

[Peter Rosin]

Den 2010-05-04 20:00 skrev Ralf Wildenhues:

Errrm, is that really so? I tend to agree with Jef here...


I take it that your response is to my "... it will work" sentence, not
the paragraph below that.


Ah, indeed.


The algorithm *could* be interpreted such that e.g. the interface change
"int foo(void)" ->  "int foo(int)" is an interface addition of int foo(int)
and an interface remove of int foo(void), thus triggering both #5 and #6.
But in that case "changed" need not be mentioned in #4 either. So, because
"changed" is mentioned in #4, it also needs to be explicitly mentioned
in #6.


Ah, ok.  Yes, you're right.  Feel free to commit a patch to
s/removed/&  or changed/  in 6.


I've pushed the attached patch...

Cheers,
Peter

2010-05-05  Peter Rosin  

Clarify versioning algorithm documentation.
* doc/libtool.texi (Updating version info): Be explicit
about setting age to zero on interface change.
Reported by Jef Driesen 


--
They are in the crowd with the answer before the question.
> Why do you dislike Jeopardy?
diff --git a/doc/libtool.texi b/doc/libtool.texi
index f73f5a7..bbc22f4 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -2927,8 +2927,8 @@ If any interfaces have been added since the last public 
release, then
 increment @var{age}.
 
 @item
-If any interfaces have been removed since the last public release, then
-set @var{age} to 0.
+If any interfaces have been removed or changed since the last public
+release, then set @var{age} to 0.
 @end enumerate
 
 @stro...@emph{never}} try to set the interface numbers so that they
___
http://lists.gnu.org/mailman/listinfo/libtool

Re: libtool versioning

[Peter Rosin]

Den 2010-05-06 19:45 skrev Jason Curl:

On 04/05/2010 20:41, Peter Rosin wrote:

Den 2010-05-04 20:00 skrev Ralf Wildenhues:

Ah, ok. Yes, you're right. Feel free to commit a patch to
s/removed/& or changed/ in 6.

Sorry I came in late for the discussion. Is it correct to interpret
"removed" as an interface has been removed, or an interface has been
changed so as to cause a binary incompatibility, so that bumping the
major version is the result to indicate it is not 100% binary compatible
with the previous version, and therefore may break a program that is
already compiled against this library?


Hi Jason,

's/removed/& or changed/' could have been spelled out in full as
's/removed/removed or changed/' if that clarifies the situation for
you?

So, both removing an interface and changing an interface
cause a binary incompatibility, so both actions need a major
version bump and age=0 (i.e. not compatible with previous
versions).

Cheers,
Peter

--
They are in the crowd with the answer before the question.
> Why do you dislike Jeopardy?


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]

[Peter Rosin]

Hi Gary!

Den 2010-06-08 09:34 skrev Gary V. Vaughan:

[[Adding Libtool List]]

On 8 Jun 2010, at 08:42, Charles Wilson wrote:

Which is why I don't think even the Peter's long-ready MSVC patches, nor
my pile of pending patches, are candidates for this extremely shortened
release cycle.


Regarding these patches, I honestly have paid very little attention to
Windows fixes for libtool because I can't test them, and don't use them:
So I figured someone else was taking care of it.  Since that obviously
isn't the case, and because I'd hate to see them bitrotting indefinitely
in the list archives, we can either commit them on the trunk after 2.2.10,
or else create a topic branch in git to collect them together for testing
and merging back at an appropriate point.


There's already the pr-msvc-support branch, but when I tried to merge
master into it to make it easy to merge back later, the ChangeLog rotation
caused conflicts. How should I resolve those conflicts? By adding the
entries to ChangeLog.2009 or to ChangeLog? I think the "rule" is to
commit with the date preserved even if that causes the ChangeLog to
be unordered, but I don't know how that "rule" applies in the face
of a ChangeLog rotation (or two)...

It seems odd both to (a) have entries from 2009 in the (future-to-be) 2010
ChangeLog and (b) to make changes to the 2009 ChangeLog at this point.

I see that for the first merge of master into the branch last year I
updated the dates in the ChangeLog so that they said 2009, but that's
lying. Sort-of anyway...

Please advice.

Cheers,
Peter

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]

[Peter Rosin]

Den 2010-06-08 10:22 skrev Peter Rosin:

It seems odd both to (a) have entries from 2009 in the (future-to-be) 2010
ChangeLog and (b) to make changes to the 2009 ChangeLog at this point.

I see that for the first merge of master into the branch last year I
updated the dates in the ChangeLog so that they said 2009, but that's
lying. Sort-of anyway...


Thinking about it some more, I came to the conclusion that the obviously
correct thing to do is to merge the new entries into ChangeLog.2009.
If the branch is merged back, that is when the changes appeared, after
all. It we instead decide to cherry-pick from the branch it's another
story, then my request for advise will be applicable.


Please advice.


No longer needed, but thanks for your time anyway. :-)

Cheers,
Peter

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]

[Peter Rosin]

Den 2010-06-08 11:50 skrev Eric Blake:

On 06/08/2010 02:22 AM, Peter Rosin wrote:

There's already the pr-msvc-support branch, but when I tried to merge
master into it to make it easy to merge back later, the ChangeLog rotation
caused conflicts.


Do you have Bruno Haible's git-merge-changelog program installed on your
machine?  For the longest time, it was just a part of gnulib that you
had to build and install on your own, but it will soon be coming into
its own as a true package:

http://lists.gnu.org/archive/html/bug-gnulib/2010-05/msg00200.html
http://git.sv.gnu.org/cgit/gnulib.git/tree/lib/git-merge-changelog.c

With that installed, and a couple of lines in your .git/config (or even
globally in ~/.gitconfig), git can do the changelog merging
automatically for you (although it does it in commit order, rather than
date order).


I have git-merge-changelog. But my changes on the branch are in ChangeLog,
and the question was where they should be after the merge, in ChangeLog
or in ChangeLog.2009. I was not asking how the merge should be performed
with as little hassle as possible.


How should I resolve those conflicts? By adding the
entries to ChangeLog.2009 or to ChangeLog? I think the "rule" is to
commit with the date preserved even if that causes the ChangeLog to
be unordered, but I don't know how that "rule" applies in the face
of a ChangeLog rotation (or two)...


This is where the GNU Coding Standards are somewhat silent - they were
written in a day of CVS, when commits were made to a central repository
in strict order, so the date was always the date of the original commit.
 But nowadays, I'm personally fine seeing dates out of order, with the
understanding that the dates track the first commit on _someone's_
checkout, but list the order of commits into the upstream canonical
tree.  However, I also tend to personally re-date my Changelog entries
to the day that I'm pushing them upstream, but this can entail quite a
bit of work for a lengthy patch series.  And I do that by using 'git
rebase -i', so although the committer and ChangeLog date are the day I
push upstream, the author date is still my original date of writing the
patch.  And since 'git log' prefers author date over committer date,
that means that I often see out-of-order dates in the git log.  So I can
go either way.


You don't seem to grok that the pr-msvc-support branch is upstream.
Sorry for not being explicit about that, but please answer again when
taking that fact into account. I don't want to rebase that branch
just because someone rotated the ChangeLog. (But other issues with
the branch might make it desirable to rebase it anyway, but that's
beside the point.)

Cheers,
Peter

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]

[Peter Rosin]

Hi Christopher!

Den 2010-06-08 15:06 skrev Christopher Hulbert:

On Tue, Jun 8, 2010 at 7:40 AM, Gary V. Vaughan  wrote:

I think it important to merge pr-msvc-support into master one way or
another so that it doesn't get ignored for any longer than it has already.


I would like it to not get ignore longer either, but just looking at
the branch after pulling, I still don't see a hint of support for
either Intel or PGI compilers on windows, both of which my changes
support. That means I will likely have to continue to keep a local
branch with all my changes. In addition, I might have to work around
any issues created from the merge of the pr-msvc-support branch.


So, me working around issus with your patches is better exactly how?


Obviously making more work for 1 person shouldn't stop libtool
progress, but I think taking the time to come up with a plan on what
will be supported when the branch is merged in and making it useful
for people like me using other native Windows compilers (again, Intel
and PGI) would be nice. No matter what, I am sure I can work
with/around whatever happens, but I would certainly prefer that the
official libtool have more Windows support than at least I can see
from the pr-msvc-support branch.


Hey, I have more stuff that I would like to add, but given that it
has been virtually impossible to get any patch review for Windows stuff
(Ralf has been the only one doing it, thanks!), maybe, just maybe,
we shouldn't add too much to the plate? Which is also the reason why
I have been mostly ignoring anything new on the Windows front. Sorry
about the silence.

There is already enough pending stuff, IMHO. Let's just get that out
the door first. That may be frustrating for you, but the alternative
is frustrating for me which is worse - of course :-)

I've had enough frustration here, methinks.

Cheers,
Peter

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]

[Peter Rosin]

Den 2010-06-08 15:40 skrev Christopher Hulbert:

On Tue, Jun 8, 2010 at 9:24 AM, Peter Rosin  wrote:

I've had enough frustration here, methinks.


Sorry for my contribution to your frustration. I would just like to
see windows support in the mainstream to be done right, and the
attitude of "just get that out the door first" doesn't seem to be an
approach in the right direction. I realize you have done a lot of work
on that branch, and I am not trying to subvert it or criticize it. I
was just trying to make the Windows libtool support better.


But you are subverting it and you are criticizing it when you say
that it should "be done right". Of course it can be done better. That's
true of all software. But you have to understand that I'm at a point
where I since long have stopped adding new stuff since the pending
queue is too long. It should be no surprise that I'm not happy to see
others butt in and defer the queue even further.

Since the consensus seems to be to merge the pr-msvc-support branch,
then perhaps you should find problems with it now rather than wait
for it to be merged? You seem to want someone to look at your work
to check if it fits with what's pending, and adjust so that your
stuff merges easily later. But I get the feeling that we are past
that stage and am not really interested in going back to the drawing
board. I want to start using what's already implemented first. So
if you want your work to fit with the future of libtool you will
have to address specific issues now instead of the above hand-waving
with the implication that the pending stuff is somehow bad.

I'm biased of course, but you all know that.


I guess in the end, it doesn't matter to me. I will continue to do
whatever I am doing. Sorry for the noise.


Sorry if I'm stepping on toes here, but somehow this is a rather
sensitive subject to me...

Oh, and I will be much more open to collaboration once the branch
has been merged. That's a promise.

Cheers,
Peter

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]

[Peter Rosin]

Den 2010-06-08 18:19 skrev Christopher Hulbert:

On Tue, Jun 8, 2010 at 11:03 AM, Peter Rosin  wrote:

Den 2010-06-08 15:40 skrev Christopher Hulbert:


On Tue, Jun 8, 2010 at 9:24 AM, Peter Rosinwrote:


I've had enough frustration here, methinks.


Sorry for my contribution to your frustration. I would just like to
see windows support in the mainstream to be done right, and the
attitude of "just get that out the door first" doesn't seem to be an
approach in the right direction. I realize you have done a lot of work
on that branch, and I am not trying to subvert it or criticize it. I
was just trying to make the Windows libtool support better.


But you are subverting it and you are criticizing it when you say
that it should "be done right". Of course it can be done better. That's
true of all software. But you have to understand that I'm at a point
where I since long have stopped adding new stuff since the pending
queue is too long. It should be no surprise that I'm not happy to see
others butt in and defer the queue even further.


Rereading what I wrote, my point didn't come out right. What I wanted
to criticize was the attitude of just merge it then go forward. For
someone who has their own windows branch for some time now, I just
don't  feel that the emotional desire to just get your existing work
into the master warrants that kind of approach. I don't know what the
right-way to do Windows support is and you are probably far more
knowledgeable than I am with libtool, so there's no way for me to say
your stuff is wrong, bad, etc.

FWIW, I butted in over a year ago with questions about the branch and
my desire to support PGI and Windows compilers [1]. Only 2 people
responded to my butting, but unfortunately (and understandably)
neither of them I think wanted to get involved with it.



Since the consensus seems to be to merge the pr-msvc-support branch,
then perhaps you should find problems with it now rather than wait
for it to be merged? You seem to want someone to look at your work
to check if it fits with what's pending, and adjust so that your
stuff merges easily later. But I get the feeling that we are past
that stage and am not really interested in going back to the drawing
board. I want to start using what's already implemented first. So
if you want your work to fit with the future of libtool you will
have to address specific issues now instead of the above hand-waving
with the implication that the pending stuff is somehow bad.


I already mentioned two problems that exist for me (no support for
Intel or PGI compilers). Of course I want someone to look at my work
or at least be interested in looking at it because it provides me
support for building on Windows that I currently don't see available,
but I fail to see how that is a bad thing. I want to share what I have
done to possibly help other people. Obviously I am willing to get my
hands dirty or I would not have started modifying libtool on my own.

I am not saying what pr-msvc-support does is bad. I am saying that it
does not provide the Windows support I needed. I would not mind
helping to add my stuff to what you have, but I have posted several
messages before related to Windows that have just dead-ended. If
someone on the pr-msvc-support branch shows no interest in my work,
and it is easier for me to start from libtool master with a clean
slate, why would I bother trying to figure out what pr-msvc-support
already had.



I'm biased of course, but you all know that.


I guess in the end, it doesn't matter to me. I will continue to do
whatever I am doing. Sorry for the noise.


Sorry if I'm stepping on toes here, but somehow this is a rather
sensitive subject to me...


I understand it may be a sensitive subject to you. I don't know how to
say it again, but I am not criticizing or passing any other negative
judgement on the pr-msvc-support branch. I am just saying that it does
not support my Windows needs. I don't recall at the time I started my
windows branch if I was aware of pr-msvc-support or not.


Oh, and I will be much more open to collaboration once the branch
has been merged. That's a promise.


I guess I just don't understand that attitude. If it were me and
someone else wanted to collaborate or help out on Windows support,
interacting with them would be important to me. Then again, I don't
really care if my windows changes make into libtool. I will continue
to use whatever I have, and if pr-msvc-support gets merged with master
I will just figure it out.


I guess in the end it is just frustrating that few people on the
libtool list care about Windows, and furthermore do not express an
interest or invite collaboration. A year ago I had some questions on
the pr-msvc-support branch and even provided some patches I had made
to master at the time for PGI windows compiler support [1]. Only Bob
and Ralf respond

Re: pr-msvc-support merge

[Peter Rosin]

Hi Gary!

Den 2010-06-09 16:46 skrev Gary V. Vaughan:

Hi Peter,

[[Adding libtool list]]

On 9 Jun 2010, at 20:21, Peter Rosin wrote:

Den 2010-06-09 14:50 skrev Gary V. Vaughan:

As far as I can tell, you are eminently more qualified than me to know
whether your patches are likely to have issues.  If we can't do a straight
merge from your branch to master after 2.2.10 is rolled, then I suggest
you cherry pick as you see fit to a new merge-branch branched from current
master, but ping the list before you pull the trigger if there's anything
you want to iron out first.  When you have everything in order, I'll test
the result on all the hosts I have access to... if I hit any problems, we
can iron those out on the list too, and then merge to master when we're
done.


Then I suggest that we start with the archiver thing, as that is what the
first patch on the branch is about (see below).


This is all assuming that your changes are deep.  If not, and you think it
will be easier and/or faster to cherry pick straight into master discussing
as we go, I'm happy to do that too, although branching and merging are so
easy in git that we'd have to absolutely sure that we're not making master
any worse than the previous commit each time we add to it.


The first three are probably not that bad, but the last one (8c17887...)
needs...further discussion. It was discussed, but it dead-ended as usual [1].
Here's a mid-point message [2] that is good if you get interested and want
to find the start of that discussion...

(*) fbc144008bd66848111fb8ef2d7293b33957ea1a


The way you skip the last reload part of the test makes it look as though
the entire test-group has been skipped.  I think you should put the reloadable
object test inside a separate AT_SETUP/AT_CLEANUP, and skip just that part.


Doesn't that mean that all the compiling/linking has to be done twice, once
for each AT_SETUP? Is it worth it? Anyway, we'll get to this in due time I
suppose. Let's take care of the older patches first...


06cfce005204bb8ca212aadab38b38c0202ea04e


This is just documentation?  I'd rather the documentation is added (maybe
in several stages) along with the code changes that require that documentation.


Agreed.


2817364bb6efd20192c46edecfe085cbb288


Looks good.


Good to know, but it depends on the other stuff... So, it will have to wait.


8c17887ee34e73a2aeb127b94f5b76f45dc34017


Why so much cruft in ltmain.m4sh just to drive a different archiver?  It
seems to me that this would be better and easier to maintain, test and extend
as a whole new script.  Let's call it, $prefix/libexec/libtool/ar, build it
from $srcdir/libltdl/config/ar.m4sh, and have libtool set AR to point at the
script instead of /usr/bin/ar when the system is funky.

WDYT?


Sound appealing! I didn't want libtool to mess with $AR, so I introduced
another layer of indirection through a new $LTAR variable that libtool
can set to the "libtool --mode=ar" fallback for funky archivers. My way
requires interaction with automake but that's not needed if there's no
problem with libtool messing with $AR.

I have a patch somewhere that adds tracing to make all available libtool
modes detectable by automake and a 'tiny' automake patch somewhere else
that uses that to determine if the extra layer of indirection is
available, should I go digging for those patches or is "my way" just too
ugly?

Hmmm, the extra layer of indirection is orthogonal, isn't it?

You should know that this ar wrapper thing is an alternative to
commit 0bb52ed03e71109ef75f8d72439ea1365ae14f42
with the core idea to use a new variable $AR_SEP to handle some of the
funkiness of the MS archiver. The problem with that is that $AR_SEP
needs to be a space in the normal case, and a single space is not
easily stored as the variable content in makefiles.

Your way is also a bit over the top of my head. I don't know how to
create the infrastructure in the build system, so I'm going to need
help with that...

Cheers,
Peter

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: pr-msvc-support merge

[Peter Rosin]

Den 2010-06-10 11:14 skrev Gary V. Vaughan:

8c17887ee34e73a2aeb127b94f5b76f45dc34017


Why so much cruft in ltmain.m4sh just to drive a different archiver?  It
seems to me that this would be better and easier to maintain, test and extend
as a whole new script.  Let's call it, $prefix/libexec/libtool/ar, build it
from $srcdir/libltdl/config/ar.m4sh, and have libtool set AR to point at the
script instead of /usr/bin/ar when the system is funky.

WDYT?


Sound appealing! I didn't want libtool to mess with $AR, so I introduced
another layer of indirection through a new $LTAR variable that libtool
can set to the "libtool --mode=ar" fallback for funky archivers. My way
requires interaction with automake but that's not needed if there's no
problem with libtool messing with $AR.


Well, I think we'll need a parallel patch for automake anyway, since automake
has lib_LIBRARIES which may very well call $AR without involving libtool at
all.

Which makes me think that once we have our wrapper working, it makes more
sense to contribute it to automake than release it with libtool.


If the libtool part of the configure script clobbers $AR with the wrapper
script when needed, Automake can call $AR as much as it likes and it will
work. Or what am I missing?


I have a patch somewhere that adds tracing to make all available libtool
modes detectable by automake and a 'tiny' automake patch somewhere else
that uses that to determine if the extra layer of indirection is
available, should I go digging for those patches or is "my way" just too
ugly?


I dunno.  It's not the way I would have done it, but in the end you've
done all the work, and you'll likely be the one who keeps it all working
in the face of other changes to libtool down the line.  So you get to
choose whether you'd like to put more work in up front to minimise the
amount of maintenance you need later on.  Your call entirely :)


Hmmm, the extra layer of indirection is orthogonal, isn't it?


I'm not sure exactly what you mean.  Certainly we (and eventually
Automake) will need to figure out what to put in AR, but while we
get it working, I see no harm in unconditionally using:

   'AR = $(auxdir)/ar'


What I mean is that $AR may have been set by the user before running
configure to make a specific selection of the archiver. If the configure
script then determines that the user-provided $AR needs wrapping, it
needs to store this fact somewhere, and then you have contention for
the AR name. Is $AR under the control of the user or the configure
script? However, I guess the situation is very much the same as with
$CC and the compile script and that seems to work. I just don't
understand exactly how. Does it work because the CC make variable is
not the same thing as the CC shell variable?

*looks around a bit*

No, that's not it, one instance of the libtool script has

CC="/c/cygwin/home/peda/libtool/git/libtool-msvc/libltdl/config/compile cl"

and I only said CC=cl when I configured...

Maybe this is a non-issue?


You should know that this ar wrapper thing is an alternative to
commit 0bb52ed03e71109ef75f8d72439ea1365ae14f42
with the core idea to use a new variable $AR_SEP to handle some of the
funkiness of the MS archiver. The problem with that is that $AR_SEP
needs to be a space in the normal case, and a single space is not
easily stored as the variable content in makefiles.


I think we get to sidestep that whole issue by having the ar wrapper
figure it out at runtime for the best flexibility and reusability of
the same script when jumping between cygwin/msys/mingw etc.

>

Your way is also a bit over the top of my head. I don't know how to
create the infrastructure in the build system, so I'm going to need
help with that...


With the idea of contributing the script back to Automake for use in
its lib_LIBRARIES rules, we shouldn't use the m4sh infrastructure, so
let's just encapsulate it in a self-contained script to be installed
alongside mdate-sh, depcomp and the like.  It looks pretty straight-
forward actually.


Hmm, does this mean that everything about getting support for MS lib
as archiver ends up in Automake?

One thing that I "fear" about not having the support built into libtool
is that projects might need to invoke some extra macro (copy-paste-fix
AM_PROG_CC_C_O). Old projects tend to have AM_PROG_CC_C_O since they
needed to support some oldish toolchain many years ago, but how many
maintainers are going to add AM_PROG_FUNKY_AR and the $auxdir/ar script
at this point?

Cheers,
Peter

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: pr-msvc-support merge

[Peter Rosin]

Hi!

Ok, let's take a step back. This is no longer really merging
work from the branch, so since A) using MS lib as archiver isn't
essential for MSVC support (at least I don't think so, I can't
remember any case where binutils ar hasn't worked for me, but
ar creates archives that are different so I don't really like
the situation) and B) by the looks of it it will have little to
do with patching libtool anyway, I think it might be better
to leave the archiver work behind for a bit.

Some points:

By bringing a standalone script to the automake list that will
(at the moment, and for the foreseeable future) only be of use
if you want to use MS lib as archiver, but will still add
another file to "all" packages, I feel that there is a risk that
the benefit will be deemed too small when compared to the cost.
ltmain is already large and a few extra lines will not be noticed
by that many people.

If another funky archiver is found, which will need wrapping, the
needed "defunkying" should go into the same standalone script,
anything else would be a failure from my pov. But then you end
up with the problem Ralf mentioned (how to communicate from
configure to the wrapper how the wrapper should behave). That
problem is easily solved if the wrapper lives inside the libtool
script. Similarly, since we need to teach libtool how to convert
posix $build paths to $host paths anyway, if the wrapper lives in
libtool we get the infrastructure for that for free when it's time
to fix this for lib.exe. If the wrapper is standalone, it will
need to figure these things out on every invocation (probably doing
a bunch of painful forks) or it will need help from somewhere (i.e.
configure via make à la depcomp).

The above may sound as if I'm opposed to moving the script to
automake, but I'm not. I'm mostly afraid of the script ending up
where the cccl script - or should I say script_s_ - ended up.

The good thing with a standalone script is that it is usable w/o
some/all autotools. Having the script work w/o autoconf/automake
is not terribly important, so falling back to the depcomp variable
passing scheme when something is too painful to figure out at
runtime is workable, methinks.

Attaching a very rough first cut, but I don't intend to work on
this at the moment as explained at the top. I'll post a mail
addressing the next patch on the branch soonish instead.

Cheers,
Peter
#! /bin/sh

case $1 in
  '')
 echo "$0: No command.  Try \`$0 --help' for more information." 1>&2
 exit 1;
 ;;
  -h | --h*)
cat <<\EOF
Usage: ar [--help] [--version] PROGRAM ACTION ARCHIVE [MEMBER...]
EOF
exit $?
;;
  -v | --v*)
echo "ar v0.0"
exit $?
;;
esac

AR=$1
shift
action=$1
shift
archive=$1
shift
members=$@

test -z "$action" && echo "you must specify an action"
test -z "$archive" && echo "you must specify an archive"

case $action in
cru)
  $AR -NOLOGO -OUT:"$archive" $members
  ;;
x)
  $AR -NOLOGO -LIST:"$archive" | while read member
  do
$AR -NOLOGO -EXTRACT:"$member" "$archive"
  done
  ;;
t)
  $AR -NOLOGO -LIST:"$archive"
  ;;
*)
  echo "bad archive action, either cru, x or t"
  ;;
esac
___
http://lists.gnu.org/mailman/listinfo/libtool

Re: pr-msvc-support merge

[Peter Rosin]

Hi Ralf,

Den 2010-06-12 10:05 skrev Ralf Wildenhues:

* Peter Rosin wrote on Sat, Jun 12, 2010 at 12:49:18AM CEST:

The above may sound as if I'm opposed to moving the script to
automake, but I'm not. I'm mostly afraid of the script ending up
where the cccl script - or should I say script_s_ - ended up.


Well, I sort of figured that the 'compile' script could end up absorbing
quite a bit of the cccl functionality so to make it unneeded.  But hey,
let's be honest, somebody would have to do this work, because I don't
have the resources to do it.


Do you think something along these lines would be acceptable? It would
remove the need of some patches on the pr-msvc-support branch...

Is it perhaps time for me to assign copyright for automake changes?

Cheers,
Peter
diff --git a/lib/compile b/lib/compile
index c0096a7..ce89059 100755
--- a/lib/compile
+++ b/lib/compile
@@ -1,9 +1,9 @@
 #! /bin/sh
 # Wrapper for compilers which do not understand `-c -o'.
 
-scriptversion=2009-10-06.20; # UTC
+scriptversion=2010-06-14.06; # UTC
 
-# Copyright (C) 1999, 2000, 2003, 2004, 2005, 2009  Free Software
+# Copyright (C) 1999, 2000, 2003, 2004, 2005, 2009, 2010  Free Software
 # Foundation, Inc.
 # Written by Tom Tromey .
 #
@@ -29,6 +29,108 @@ scriptversion=2009-10-06.20; # UTC
 # bugs to  or send patches to
 # .
 
+path_conv=
+
+# func_path_conf build_path
+# Convert a $build path to $host form and store it in $path
+func_path_conv ()
+{
+  path=$1
+  case $path in
+/[^/]*) # absolute path, and no UNC path
+  if test -z "$path_conv"; then
+   # lazily determine how to convert abs paths
+   case `uname -s` in
+ MINGW*)
+   path_conv=mingw
+   ;;
+ CYGWIN*)
+   path_conv=cygwin
+   ;;
+ *)
+   path_conv=wine
+   ;;
+   esac
+  fi
+  case $path_conv in
+   mingw)
+ path=`cmd //C echo "$path " | sed -e 's/"\(.*\) " *\$/\1/'`
+ ;;
+   cygwin)
+ path=`cygpath -w "$path"`
+ ;;
+   wine)
+ path=`winepath -w "$path"`
+ ;;
+  esac
+  ;;
+  esac
+}
+
+# func_cl_wrapper cl arg...
+# Adjust compile command to suite cl
+func_cl_wrapper ()
+{
+  # Assume a capable shell
+  for arg
+  do
+if test -n "$eat"; then
+  eat=
+else
+  case $1 in
+   -o)
+ # configure might choose to run compile as `compile cc -o foo foo.c'.
+ eat=1
+ case $2 in
+   *.o | *.obj)
+ func_path_conv "$2"
+ set x "$@" -Fo"$path"
+ shift
+ ;;
+   *)
+ func_path_conv "$2"
+ set x "$@" -Fe"$path"
+ shift
+ ;;
+ esac
+ ;;
+   -I*)
+ func_path_conv "${1#-I}"
+ set x "$@" -I"$path"
+ shift
+ ;;
+   -l*)
+ set x "$@" "${1#-l}.lib"
+ shift
+ ;;
+   -L*)
+ func_path_conv "${1#-L}"
+ export LINK="$LINK -LIBPATH:$path"
+ ;;
+   -Wl,*)
+ arg=${1#-Wl,}
+ save_ifs="$IFS"; IFS=','
+ for flag in $arg; do
+   IFS="$save_ifs"
+   export LINK="$LINK $flag"
+ done
+ IFS="$save_ifs"
+ ;;
+   -Xlinker)
+ eat=1
+ export LINK="$LINK $2"
+ ;;
+   *)
+ set x "$@" "$1"
+ shift
+ ;;
+  esac
+fi
+shift
+  done
+  exec "$@"
+}
+
 case $1 in
   '')
  echo "$0: No command.  Try \`$0 --help' for more information." 1>&2
@@ -53,6 +155,9 @@ EOF
 echo "compile $scriptversion"
 exit $?
 ;;
+  cl | *[/\\]cl)
+func_cl_wrapper "$@"  # Doesn't return...
+;;
 esac
 
 ofile=
___
http://lists.gnu.org/mailman/listinfo/libtool

Re: pr-msvc-support merge

[Peter Rosin]

Hi Ralf!

Den 2010-06-14 22:40 skrev Ralf Wildenhues:

[ adding automake-patches; this is
   http://thread.gmane.org/gmane.comp.gnu.libtool.general/10927/focus=10954 ]

* Peter Rosin wrote on Mon, Jun 14, 2010 at 09:35:45AM CEST:

Den 2010-06-12 10:05 skrev Ralf Wildenhues:

Well, I sort of figured that the 'compile' script could end up absorbing
quite a bit of the cccl functionality so to make it unneeded.  But hey,
let's be honest, somebody would have to do this work, because I don't
have the resources to do it.


Do you think something along these lines would be acceptable? It would
remove the need of some patches on the pr-msvc-support branch...


The patch looks pretty good to me already, but is lacking additions for
ChangeLog, NEWS, and maybe doc/ and tests/ too.


Right.

[snip useful advice]

Running the tests are still an outright pain though, but I will try it.
But it might take some time, I'm not used to running them and msys
is...cumbersome. Meanwhile, I have attached the current version of the
patch in case there are further things to fix.


Some nits and questions:


+  case $path_conv in
+   mingw)
+ path=`cmd //C echo "$path " | sed -e 's/"\(.*\) " *\$/\1/'`


I fail to understand what this sed script is for.  Help?


It was the easiest I could come up with after experimenting a lot. That
wasn't yesterday though, but IIRC if you want to convert paths with
spaces, you need to quote the $path for cmd, hence the quotes in the
echo "$path " construct. The space before the end quote will make the
argument always contain a space which forces MSYS to add quotes when the
path is fed to the Windows process (cmd in this case). The quotes are
added by MSYS after converting the path to windows form. Without that
space, the string is only quoted if it happens to contain a space, so
view it as a canonicalizer. The sed script is there to remove those
quotes (and the space before the end quote). Also, something seem to
mysteriously add a space at the end, so I'm removing that too while at
it, but only if it's really there (it felt like a bug that might be
fixed at some point). It might be possible to use eval to remove the
quotes, but since the path will typically contain backslashes I didn't
want to go there.


+   cygwin)
+ path=`cygpath -w "$path"`


IIUC cygpath is pretty much required to be present on Cygwin
installations, right?  Can it fail though?  Should $path retain its old
value if it does?  Don't we want -m rather than -w for forward slashes
(which IIUC even MSVC programs should support) to avoid quoting issues?
   path=`cygpath -m "$path" || echo "$path"`


The mingw case and the wine case have backlashes, so in that case those
too have to be turned into forward slashes. But since this is the end of
the line (isn't it?), I don't really see the need to use forward slashes.
The only consumer of those paths is cl.exe (and friends).


+   wine)
+ path=`winepath -w "$path"`


winepath OTOH may not be present, so this should definitely fall back to
the unconverted path I think.  And maybe the path_conv-setting code
check for presence of winepath.


I added the wine stuff more as an afterthought, but adding that fallback
is easy enough. Done.


+   -L*)
+ func_path_conv "${1#-L}"
+ export LINK="$LINK -LIBPATH:$path"


Is LINK a predefined variable?  Does it come from libtool?  Or from the
user or the system?


There are three ways to get options through to the linker, IIUC. By
1) using the LINK environment variable. The user might have put
   stuff in it, so therefore preserve that and add any further
   options at the end.
2) using "-link  ..." on the command line, but that has the
   disadvantage that *all* options after -link are fed to the
   linker. Hmmm, but here we have control over that, so using
   that approach is feasible.
3) using a response file, then you can feed options to the
   compiler and the linker in whatever order you like, but with
   the disadvantage that you need to clean up the (temporary)
   response file (costs a fork).

My libtool patches used #1, that is the only relation to libtool.
This new version uses #2 instead. I think that might be clearer?


+ ;;
+   -Wl,*)
+ arg=${1#-Wl,}
+ save_ifs="$IFS"; IFS=','
+ for flag in $arg; do
+   IFS="$save_ifs"
+   export LINK="$LINK $flag"
+ done
+ IFS="$save_ifs"


For this, IFS needs to be initialized to default near the beginning of
the script (there is an embedded TAB in the last line):

nl='
'
IFS=" "" "$nl"


Wasn't aware of that, thanks! But you have five quotes, that's wrong
I suppose, so I removed the one before $nl.

Is the nl va

Re: .cvsignore files still relevant?

[Peter Rosin]

Den 2010-09-13 05:46 skrev Gary V. Vaughan:
> Do we still need to maintain .cvsignore files for a cvs
> mirror of our git repo, or is it safe to remove them now?

What on earth would .cvsignore be useful for in this day and age?

> (I have a patch in my queue that tries to sanitize and
> make equivalent our various ignore files -- but I see
> that Chuck's recent patch added *.obj to the top-level
> .gitignore without an equivalent *.obj addition to every
> .cvsignore file)

s/Chuck/Peter/

Cheers,
Peter

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: 2.4 Release in 24hrs

[Peter Rosin]

Den 2010-09-19 16:41 skrev Bob Friesenhahn:
> On Sun, 19 Sep 2010, Gary V. Vaughan wrote:
> 
>> I'm planning to make the belated 2.4 release in about 24 hours.
> 
> Yesterday I ran the libtool test suite on various machines here.  The
> test suite performed quite well (better than a week or two ago) on
> Solaris 10 x86 & SPARC, FreeBSD 8.0, and OS-X Leopard PPC.

And I ran the new testsuite on MSYS/MSVC and Cygwin/gcc this morning
and noticed nothing unexpected.

Cheers,
Peter

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: 2.4 Release in 24hrs

[Peter Rosin]

Hi Gary,

Den 2010-09-19 06:03 skrev Gary V. Vaughan:
> I'm planning to make the belated 2.4 release in about 24 hours.

Just a friendly ping, but only just now I pushed a change to the
'compile' script in automake and would like the new version in
the release if it's not too much to ask for.  Thanks!

Cheers,
Peter

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: 2.4 Release in 24hrs

[Peter Rosin]

Hi Ralf,

Den 2010-09-20 19:41 skrev Ralf Wildenhues:
> I'd really appreciate if you guys could send build logs to the autobuild
> server as I've been doing lately, much more than just posting
> non-verbose results on the list here.
> 
> You don't need to have autobuild installed.  When Eric installs
> autobuild.m4 you don't need to do anything else.
> 
> Here's what I use, more or less, to create the logs:
> 
>   ( ../libtool/configure [OPTIONS] \
> && make \
> && make -k check
> cat test-suite.log tests/testsuite.log
> if tail tests/testsuite.log | grep '^| ' >/dev/null; then :; else
>   sed 's/^/| /' config.log
> fi
>   ) > logfile
> 
>   $sanitize logfile
>   mail libtool_autobuild.josefsson.org < logfile
> 
> with the underscore replaced by @.  For now, OPTIONS includes
> autobuild_mode=bla if there is anything special about the build.

If I do post there, will a human (you?) or a robot process the mail?
Is the Subject: important?

I have plans to soon mail output from the v2.4 tag with OPTIONS as
below on MSYS:
autobuild_mode=msvc \
CC="/c/cygwin/home/peda/automake/lib/compile cl" \
CFLAGS="-MD -Zi -EHsc" \
CXX="/c/cygwin/home/peda/automake/lib/compile cl" \
CXXFLAGS="-MD -Zi -EHsc" \
LD=link \
NM="dumpbin -symbols" \
STRIP=: \
AR="/c/cygwin/home/peda/automake/lib/ar-lib lib" \
RANLIB=: \
F77=no \
FC=no \
GCJ=no \
--enable-dependency-tracking

and as below on Cygwin:
autobuild_mode=msvc \
CC="/home/peda/automake/lib/compile cl" \
CFLAGS="-MD -Zi -EHsc" \
CXX="/home/peda/automake/lib/compile cl" \
CXXFLAGS="-MD -Zi -EHsc" \
LD=link \
NM="dumpbin -symbols" \
STRIP=: \
AR="/home/peda/automake/lib/ar-lib lib" \
RANLIB=: \
F77=no \
FC=no \
GCJ=no \
--enable-dependency-tracking \
lt_cv_to_host_file_cmd=func_convert_file_cygwin_to_w32 \
lt_cv_to_tool_file_cmd=func_convert_file_cygwin_to_w32 \

Should I have set autobuild_mode to something else? I'll fiddle the
already generated output if so...

Cheers,
Peter

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: autobuild results

[Peter Rosin]

Den 2010-09-23 20:05 skrev Ralf Wildenhues:
>> I have plans to soon mail output from the v2.4 tag with OPTIONS as
>> below on MSYS:
> *snip*
> 
> That looks all fine to me.  Thanks!

Hi Ralf,

Ok, done, and they appeared just fine on the site too. Since you said
you were going to collect them, would you want a bcc for future dumps?

Cheers,
Peter

___
http://lists.gnu.org/mailman/listinfo/libtool

bindir.at takes forever.

[Peter Rosin]

Hi!

I have been looking at the loops in tests/bindir.at and I see
this:

  for bindir in \
$curdir/usr/lib/gcc/i686-pc-cygwin/4.5.0/bin/ \
$curdir/usr/lib/gcc/i686-pc-cygwin/4.5.0/bin \
$curdir/usr/lib/gcc/i686-pc-cygwin/4.5.0/ \
$curdir/usr/lib/gcc/i686-pc-cygwin/4.5.0 \
$curdir/usr/lib/gcc/i686-pc-cygwin/bin/ \
$curdir/usr/lib/gcc/i686-pc-cygwin/bin \
$curdir/usr/lib/gcc/i686-pc-cygwin/ \
$curdir/usr/lib/gcc/i686-pc-cygwin \
$curdir/usr/lib/bin/ \
$curdir/usr/lib/bin \
$curdir/usr/bin/ \
$curdir/usr/bin \
$curdir/bin/ \
$curdir/bin \
/tmp/foo/bar ;
  do

 ...

  done

Is it really necessary to check *all* components with the trailing slash?
And do we really need to test so many levels? Looks like the tests time
could be cut dramatically with little risk of causing a regression.

That would be very useful to me, since I have this for MSYS/MSVC:
54. bindir install tests (bindir.at:190): ok (20m5.264s 16m18.552s)
and this for Cygwin/MSVC:
54. bindir install tests (bindir.at:190): ok (18m47.361s 24m34.475s)

I know the test is designed to mimic what GCC is doing when it is built,
but this is a bit over the top if you ask me. And I can't imagine that
GCC is using all those variations of bindir...

Thoughts?

Cheers,
Peter

___
http://lists.gnu.org/mailman/listinfo/libtool

New autobuild results for MSVC from v2.4-7-gc5bce82

[Peter Rosin]

Hi!

FYI, I just uploaded the latest MSVC results, one FAIL in the
old testsuite, the rest is PASS/SKIP/XFAIL.

Should be a good base for future regression analysis.

Cheers,
Peter

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: somewhat misleading -no-undefined documentation

[Peter Rosin]

Hi Simon,

Den 2010-10-12 11:19 skrev Simon Josefsson:
> Ralf Wildenhues  writes:
> 
>> I kinda like Simon's patch you referenced (wow, that's old!), so how
>> about this patch which takes from both your suggestions?
> 
> I like it.  Thanks, this closes a long-standing libtool concern of mine.
> 
> Generally, having to use -no-undefined to get things to work on some
> platforms (e.g., to get a working DLL) is somewhat obscure and seems
> counter to having the default behaviour Just Work.  Is there any reason
> -no-undefined cannot be the default?  Is it common for installed
> libraries to have unresolved symbols at link time?  Even if it is,
> couldn't libtool figure out that there aren't any external symbols, and
> create the DLL when it is possible?  I may be missing some details
> though.

-no-undefined predates my involvement and I have not done a decent
dig in the archives, but as far as I understand, the reasoning is
based on these facts:

1. There are legitimate reasons for libraries to have unresolved
   symbols.
2. Those libraries can't ever exist as (normal) DLLs.
3. However, they can exist as static libraries.
4. Libtool has no means to determine if the library has unresolved
   symbols as an intentional feature or if it's a bug.
5. It is a maintenance nightmare for Libtool to determine if the
   DLL failed to build because of unresolved symbols or for some
   other reason.  Or both.
6. A long time ago, it was determined that the default should be
   to not attempt to create DLLs unless it was known beforehand
   that there should be no unresolved symbols.

I can only assume that the reason for not attempting to build the
DLL is that there is no way to know if Libtool should fall back to
only creating a static library or if it should bomb out with an
error when the attempt to link the DLL fails.

Falling back to static and not error out when failing to build the
DLL has its problems, since even a big fat warning is easily missed
in the flood of messages in a typical build.

I assume that bombing out with an error will be a regression for
some libraries which currently relies on Libtool to not attempt the
creation of DLLs when -no-undefined is not issued.  Those projects
must be provided with a matching -undefined option for this to be
a viable path.  Or should it be -undefined-symbols? -undefined seems
so unspecific and, well, undefined...

Cheers,
Peter

___
http://lists.gnu.org/mailman/listinfo/libtool

[RFC] w32 and Libtool.

[Peter Rosin]

Hi!

I have been tinkering with a text describing the hoops to jump when
prepping a library for Windows. At some point it should be texified and
added to the manual, but I'm not the best candidate for that job so this
is plain ASCII for now.

Can you spot any errors?

(I have not actually tested the code samples. Yet)

Cheers,
Peter



Windows DLLs.
-

This topic describes a couple of ways to portably create Windows Dynamic
Link Libraries (DLLs). Libtool knows how to create DLLs using GNU tools
and using Microsoft tools.

A typical library has a "hidden" implementation with an interface
described in a header file. On just about every system, the interface
could be something like this:

Example foo.h:

#ifndef FOO_H
#define FOO_H

int one (void);
int two (void);
extern int three;

#endif /* FOO_H */

And the implementation could be something like this:

Example foo.c:

#include "foo.h"

int one (void)
{
  return 1;
}

int two (void)
{
  return 2;
}

int three = 3;


When using contemporary GNU tools to create the Windows DLL, the above
code will work there too, thanks to its auto-import/auto-export
features. But that is not the case when using older GNU tools or perhaps
more interesting when using proprietary tools. In those cases the code
will need additional decorations on the interface symbols with
__declspec(dllimport) and __declspec(dllexport) depending on if the
library is built or if it's consumed and how it's built and consumed.

Concentrating on how Libtool is using Microsoft tools, Libtool will dig
through the object files making up the library looking for non-static
symbols to automatically export. I.e., Libtool with Microsoft tools is
trying to mimic the auto-export feature of the contemporary GNU tools.
It should be noted that the GNU auto-export feature in turned off when
an explicit __declspec(dllexport) is seen. The GNU tools is doing this
to not make more symbols visible for projects that have already taken
the trouble to decorate all symbols. There is no similar way to limit
which symbols are visible in the code when Libtool is using Microsoft
tools. In order to limit symbol visibility in that case you need to use
one of the -export-symbols or -export-symbols-regex options.

No matching help with auto-import is provided by Libtool for neither
proprietary tools nor older GNU tools, so symbols *must* be decorated in
order to import them from a DLL for everything but contemporary GNU
tools on Windows.

When the objects that form the library are built, there are generally
two copies built for each object. One copy is used when linking the DLL
and one copy is used for the static library. On Windows systems, the
copy used when creating the DLL is compiled with the flag -DDLL_EXPORT.
It is common practice to also add a flag that is only present when the
library is built, but that will not be present when it is consumed, such
as -DBUILDING_LIBFOO. These defines are then used to discriminate how
the interface symbols should be decorated.

However, the matching double compile is not performed when consuming
libraries. It is therefore not possible to reliably distinguish if the
consumer is importing from a DLL or if it is going to use a static
library. With contemporary GNU tools, auto-import saves the day. With
Microsoft tools you typically get away with always compiling the code as
if it is going to be linked with a DLL. There are cases when this does
not work, such as when only variables and no functions are imported from
the library. There is also a price connected to this liberal use of
imports in that an extra indirection is introduced when you are
consuming the static version of the library. That extra indirection is
always present when the DLL is consumed, but it is not needed when
consuming the static library.

For older GNU tools and other proprietary tools there is no generic way
to make it possible to consume either of the DLL or the static library
without user intervention, the tools needs to be told what is intended.
Or, to be exact, the author are not aware of any generic way. One
assumption that has been used is that if a DLL is being built
(DLL_EXPORT is defined) then that DLL is going to consume any dependent
libraries as DLLs. If that assumption is made everywhere, it is possible
to select how an end user application is consuming libraries by adding a
single flag -DDLL_EXPORT when a DLL build is required. This is of course
an all or nothing deal, either everything as DLLs or everything as
static libraries.

To sum up the above, the header file of the foo library needs to be
changed into something like this:

Modified foo.h:

#ifndef FOO_H
#define FOO_H

#if (defined _WIN32 || defined _WIN32_WCE) && !defined __GNUC__
# ifdef BUILDING_LIBFOO
#  ifdef DLL_EXPORT
#   define LIBFOO_SCOPE extern __declspec (dllexport)
#  endif
# elif defined _MSC_VER || defined DLL_EXPORT
#  define LIBFOO_SCOPE extern __declspec (dllimport)
# endif
#endif
#ifndef LIBFOO_SCOPE
# define LIBFOO_

Re: [RFC] w32 and Libtool.

[Peter Rosin]

Den 2010-10-13 20:50 skrev Ralf Wildenhues:
> Hi Peter,
> 
> * Peter Rosin wrote on Wed, Oct 13, 2010 at 08:19:27PM CEST:
>> Can you spot any errors?
> 
> See below.  I've only checked for things obvious to me; I hope somebody
> else verifies the w32 semantics and details.  ;-)

I have snipped the hunks where I agree with you review and have nothing
of value to add. I have also taken case of the nit mentioned by Vincent.

> Two spaces after period.

I consider that part of texification.

>> int one (void)
>> {
>>   return 1;
>> }
>>
>> int two (void)
>> {
>>   return 2;
>> }
>>
>> int three = 3;
> 
> Isn't this less-than fully general, in the sense that having in addition
> references to one and three from within two would possibly be more
> complex to handle?

I don't remember ever having problems with that, but I suppose two () could
be written as { return three - one (); } if that makes you sleep better.

>> an explicit __declspec(dllexport) is seen. The GNU tools is doing this
>> to not make more symbols visible for projects that have already taken
>> the trouble to decorate all symbols. There is no similar way to limit
> 
> s/all// ?  (because how can you know that it did do so for all symbols,
> when parts of the project may come from third parties?)

You have to decorate all symbols you wish to export, because if you miss
some, auto-export will have been disabled by the symbols that was indeed
decorated.  I'll still remove "all" though, because you really only need
to decorate the symbols that you wish to export, and that is typically
not *all* symbols.

>> No matching help with auto-import is provided by Libtool for neither
>> proprietary tools nor older GNU tools, so symbols *must* be decorated in
>> order to import them from a DLL for everything but contemporary GNU
>> tools on Windows.
> 
> But can we not assume that older GNU tools are irrelevant?  What would
> keep people from updating them?

I don't know. I felt that a bit of history wouldn't hurt here. Maybe I'm
just muddying the waters?

>> When the objects that form the library are built, there are generally
>> two copies built for each object. One copy is used when linking the DLL
>> and one copy is used for the static library. On Windows systems, the
>> copy used when creating the DLL is compiled with the flag -DDLL_EXPORT.
> 
>> It is common practice to also add a flag that is only present when the
>> library is built, but that will not be present when it is consumed, such
>> as -DBUILDING_LIBFOO. These defines are then used to discriminate how
>> the interface symbols should be decorated.
> 
> This seems to be a bit reversed.  From a narrative standpoint, the
> "common practice" only appears out of necessity, and the necessity has
> not been explained yet.  Right?

Right. I'll rephrase.

>> With
>> Microsoft tools you typically get away with always compiling the code as
>> if it is going to be linked with a DLL. There are cases when this does
>> not work, such as when only variables and no functions are imported from
>> the library. There is also a price connected to this liberal use of
>> imports in that an extra indirection is introduced when you are
>> consuming the static version of the library. That extra indirection is
>> always present when the DLL is consumed, but it is not needed when
>> consuming the static library.
> 
> This paragraph is fairly vague.  I understand if you don't want to tell
> all the gory details about this, but in that case maybe a pointer to
> more detailed documentation would be good here.

I don't know where this is spelled out, and it is intentionally vague as
I don't know all the answers.

>> For older GNU tools and other proprietary tools there is no generic way
>> to make it possible to consume either of the DLL or the static library
>> without user intervention, the tools needs to be told what is intended.
>> Or, to be exact, the author are not aware of any generic way. One
> 
> s/are/is/  This sounds a bit awkward still.

Don't know what to do about that.

>> assumption that has been used is that if a DLL is being built
> 
> that is commonly used?

I rephrased it differently.

>> It should be noted that there are various projects that attempt to relax
>> these requirements by various low level tricks, but they are not
>> discussed here.
> 
> Pointers?

Added.

Here's an update:


Windows DLLs.
-

This topic describes a couple of ways to portably create Windows Dynamic
Link Libraries (DLLs).  Libtool knows how to create DLLs using GNU tools

Re: [RFC] w32 and Libtool.

[Peter Rosin]

Hi Simon,

Thanks for the feedback.

Den 2010-10-14 09:34 skrev Simon Josefsson:
> First, thanks for working on this.  It is definitely needed in the
> manual.  I have re-engineered this a couple of times already, but the
> collected wisdom should be in the manual in the first place.

Indeed.

> Peter Rosin  writes:
>> #if defined _WIN32 && !defined __GNUC__
>> # ifdef BUILDING_LIBFOO
>> #  ifdef DLL_EXPORT
>> #   define LIBFOO_SCOPE extern __declspec (dllexport)
>> #  endif
>> # elif defined _MSC_VER || defined DLL_EXPORT
>> #  define LIBFOO_SCOPE extern __declspec (dllimport)
>> # endif
>> #endif
>> #ifndef LIBFOO_SCOPE
>> # define LIBFOO_SCOPE extern
>> #endif
> 
> I think it would help to namespace clarify this, to make it clear which
> CPP symbols are from the system and which are intended to be provided by
> the project itself.  How about this:
> 
> #if defined _WIN32 && !defined __GNUC__
> # ifdef LIBFOO_BUILDING
> #  ifdef LIBFOO_DLL_EXPORT
> #   define LIBFOO_SCOPE extern __declspec (dllexport)
> #  endif
> # elif defined _MSC_VER || defined LIBFOO_DLL_EXPORT
> #  define LIBFOO_SCOPE extern __declspec (dllimport)
> # endif
> #endif
> #ifndef LIBFOO_SCOPE
> # define LIBFOO_SCOPE extern
> #endif

DLL_EXPORT comes from libtool, so it should not be changed to
LIBFOO_DLL_EXPORT. And while I approve of starting with LIBFOO_
instead of BUILDING_, LIBFOO_BUILDING sounds very wrong as
BUILDING changes from a verb to a noun. LIBFOO_BUILD perhaps?
Other suggestions welcome.

> However, I suspect people will need to adapt this block for their own
> projects.

Yes, I should have tested the code before I submitted the initial
version.  When I tested the code, I realized I had forgotten a
couple of pretty important bits.  An update is coming up.

> For comparison, in my projects I'm using a variant of this:
> 
> # ifndef GSASL_API
> #  if defined GSASL_BUILDING && defined HAVE_VISIBILITY && HAVE_VISIBILITY
> #   define GSASL_API __attribute__((__visibility__("default")))
> #  elif defined GSASL_BUILDING && defined _MSC_VER && ! defined GSASL_STATIC
> #   define GSASL_API __declspec(dllexport)
> #  elif defined _MSC_VER && ! defined GSASL_STATIC
> #   define GSASL_API __declspec(dllimport)
> #  else
> #   define GSASL_API
> #  endif
> # endif

I'm desperately trying to get away from having to specify (the
equivalence of) GSASL_STATIC when consuming libraries.

Cheers,
Peter

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: [RFC] w32 and Libtool.

[Peter Rosin]

Den 2010-10-13 20:50 skrev Ralf Wildenhues:
> Hi Peter,
> 
> * Peter Rosin wrote on Wed, Oct 13, 2010 at 08:19:27PM CEST:
>> Can you spot any errors?
> 
> See below.  I've only checked for things obvious to me; I hope somebody
> else verifies the w32 semantics and details.  ;-)
> 
> Thanks for writing this!
> 
>> (I have not actually tested the code samples. Yet)
> 
> Thanks in advance!  :-)

Should have done that before the OP.  Oh well.  Here's a 3rd attempt
with actual tested and working code.  The lessons I relearned during
testing should also have improved the descriptions in the text.



Windows DLLs.
-

This topic describes a couple of ways to portably create Windows Dynamic
Link Libraries (DLLs).  Libtool knows how to create DLLs using GNU tools
and using Microsoft tools.

A typical library has a "hidden" implementation with an interface
described in a header file.  On just about every system, the interface
could be something like this:

Example foo.h:

#ifndef FOO_H
#define FOO_H

int one (void);
int two (void);
extern int three;

#endif /* FOO_H */

And the implementation could be something like this:

Example foo.c:

#include "foo.h"

int one (void)
{
  return 1;
}

int two (void)
{
  return three - one ();
}

int three = 3;


When using contemporary GNU tools to create the Windows DLL, the above
code will work there too, thanks to its auto-import/auto-export
features.  But that is not the case when using older GNU tools or perhaps
more interesting when using proprietary tools.  In those cases the code
will need additional decorations on the interface symbols with
__declspec(dllimport) and __declspec(dllexport) depending on if the
library is built or if it's consumed and how it's built and consumed.
However, it should be noted that it would have worked also with
Microsoft tools, if only the variable three hadn't been there, due to
the fact the Microsoft tools will automatically import functions (but
sadly not variables) and Libtool will automatically export non-static
symbols as described next.

With Microsoft tools, Libtool will dig through the object files that
make up the library, looking for non-static symbols to automatically
export.  I.e., Libtool with Microsoft tools is trying to mimic the auto-
export feature of the contemporary GNU tools.  It should be noted that
the GNU auto-export feature is turned off when an explicit
__declspec(dllexport) is seen.  The GNU tools do this to not make more
symbols visible for projects that have already taken the trouble to
decorate symbols.  There is no similar way to limit which symbols are
visible in the code when Libtool is using Microsoft tools.  In order to
limit symbol visibility in that case you need to use one of the options
-export-symbols or -export-symbols-regex.

No matching help with auto-import is provided by Libtool, which is why
variables must be decorated to import them from a DLL for everything but
contemporary GNU tools.  As stated above, functions are automatically
imported by both contemporary GNU tools and Microsoft tools, but for
other proprietary tools the auto-import status of functions is unknown.

When the objects that form the library are built, there are generally
two copies built for each object.  One copy is used when linking the DLL
and one copy is used for the static library.  On Windows systems, a pair
of defines are commonly used to discriminate how the interface symbols
should be decorated.  The first define is -DDLL_EXPORT which is
automatically provided by Libtool when Libtool builds the copy of the
object that is destined for the DLL.  The second define is -DLIBFOO_BUILD
(or similar) which is often added by the package providing the library
and is used when building the library, but not when consuming the
library.

However, the matching double compile is not performed when consuming
libraries.  It is therefore not possible to reliably distinguish if the
consumer is importing from a DLL or if it is going to use a static
library.

With contemporary GNU tools, auto-import often saves the day, but see
the GNU ld documentation and its --enable-auto-import option for some
corner cases when it does not.

With Microsoft tools you typically get away with always compiling the
code such that variables are expected to be imported from a DLL and
functions are expected to be found in a static library.  The tools will
then automatically import the function from a DLL if that is where they
are found.  If the variables are not imported from a DLL as expected, but
are found in a static library that is otherwise pulled in by some
function, the linker will issue a warning (LNK4217) that a locally
defined symbol is imported, but it still works.  In other words, this
scheme will not work to only consume variables from a library.  There is
also a price connected to this liberal use of imports in that an extra
indirection is intro

Re: [RFC] w32 and Libtool.

[Peter Rosin]

Den 2010-10-14 13:09 skrev Simon Josefsson:
> Peter Rosin  writes:
> 
>>> For comparison, in my projects I'm using a variant of this:
>>>
>>> # ifndef GSASL_API
>>> #  if defined GSASL_BUILDING && defined HAVE_VISIBILITY && HAVE_VISIBILITY
>>> #   define GSASL_API __attribute__((__visibility__("default")))
>>> #  elif defined GSASL_BUILDING && defined _MSC_VER && ! defined GSASL_STATIC
>>> #   define GSASL_API __declspec(dllexport)
>>> #  elif defined _MSC_VER && ! defined GSASL_STATIC
>>> #   define GSASL_API __declspec(dllimport)
>>> #  else
>>> #   define GSASL_API
>>> #  endif
>>> # endif
>>
>> I'm desperately trying to get away from having to specify (the
>> equivalence of) GSASL_STATIC when consuming libraries.
> 
> This was added to permit use of MSC to build static libraries, if I
> recall correctly.

It is with high probability not needed, see my 3rd version for how to
get rid of GSASL_STATIC.

> Another advantage with my variant is that it is possible to provide
> -DGSASL_API=foo during the build if you want to set some other attribute
> on the APIs.

That is a nice property that should perhaps be added to my variant in some
form. Good idea!

> The first issue (i.e., MSC static builds) could be handled by the means
> in the second point (i.e., project specifying -DGSASL_API="") though.
> Then there would be no need for GSASL_STATIC.
> 
> Anyway, I think the block will likely need to be adapted by each
> project.  I'm not trying to push for my version, just to offer it for
> comparison.

The only changes that should be needed is visibility attributes (which I
didn't want to discuss too much in the already complex text) and the
obvious s/LIBFOO_/LIBBAR_/ change. What other adaptations are needed?

BTW, I think it is somewhat ugly to mention HAVE_ defines in installed
headers, but since they are hidden behind GSASL_BUILDING it's acceptable.

Cheers,
Peter

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: [RFC] w32 and Libtool.

[Peter Rosin]

Den 2010-10-14 12:31 skrev Peter Rosin:
> Den 2010-10-13 20:50 skrev Ralf Wildenhues:
>> Hi Peter,
>>
>> * Peter Rosin wrote on Wed, Oct 13, 2010 at 08:19:27PM CEST:
>>> Can you spot any errors?
>>
>> See below.  I've only checked for things obvious to me; I hope somebody
>> else verifies the w32 semantics and details.  ;-)
>>
>> Thanks for writing this!
>>
>>> (I have not actually tested the code samples. Yet)
>>
>> Thanks in advance!  :-)
> 
> Should have done that before the OP.  Oh well.  Here's a 3rd attempt
> with actual tested and working code.  The lessons I relearned during
> testing should also have improved the descriptions in the text.

This time as a patch.  Ok to push, or did I screw up the texification?

Cheers,
Peter

>From f5fea8ca059f47028799d470d6eccf2c3960bb5d Mon Sep 17 00:00:00 2001
From: Peter Rosin 
Date: Fri, 29 Oct 2010 21:58:51 +0200
Subject: [PATCH] docs: Windows DLLs and headers.

* doc/libtool.texi (Platform quirks): Add new subsection
'Windows DLLs'.

Signed-off-by: Peter Rosin 
---
 ChangeLog|6 ++
 doc/libtool.texi |  190 ++
 2 files changed, 196 insertions(+), 0 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index df41497..ea53815 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2010-10-29  Peter Rosin  
+
+   docs: Windows DLLs and headers.
+   * doc/libtool.texi (Platform quirks): Add new subsection
+   'Windows DLLs'.
+
 2010-10-15  Gary V. Vaughan  
 
libtool: remove redundant unsubstituted shell var defaults.
diff --git a/doc/libtool.texi b/doc/libtool.texi
index 076b67b..04e31f1 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -225,6 +225,7 @@ Platform quirks
 * Archivers::   Programs that create static archives.
 * Cross compiling:: Issues that arise when cross compiling.
 * File name conversion::Converting file names between platforms.
+* Windows DLLs::Windows header defines.
 
 @end detailmenu
 @end menu
@@ -5768,6 +5769,7 @@ write your own.
 * Archivers::   Programs that create static archives.
 * Cross compiling:: Issues that arise when cross compiling.
 * File name conversion::Converting file names between platforms.
+* Windows DLLs::Windows header defines.
 @end menu
 
 @node References
@@ -6321,6 +6323,194 @@ the source or build directory trees, and all 
@option{-M*} options to
 This is quite a fragile setup, but it has been in historical use, and so is
 documented here.
 
+...@node Windows DLLs
+...@subsection Windows DLLs
+...@cindex Windows DLLs
+
+This topic describes a couple of ways to portably create Windows Dynamic
+Link Libraries (DLLs).  Libtool knows how to create DLLs using GNU tools
+and using Microsoft tools.
+
+A typical library has a "hidden" implementation with an interface
+described in a header file.  On just about every system, the interface
+could be something like this:
+
+Example @file{foo.h}:
+
+...@example
+#ifndef FOO_H
+#define FOO_H
+
+int one (void);
+int two (void);
+extern int three;
+
+#endif /* FOO_H */
+...@end example
+
+And the implementation could be something like this:
+
+Example @file{foo.c}:
+
+...@example
+#include "foo.h"
+
+int one (void)
+...@{
+  return 1;
+...@}
+
+int two (void)
+...@{
+  return three - one ();
+...@}
+
+int three = 3;
+...@end example
+
+When using contemporary GNU tools to create the Windows DLL, the above
+code will work there too, thanks to its auto-import/auto-export
+features.  But that is not the case when using older GNU tools or perhaps
+more interesting when using proprietary tools.  In those cases the code
+will need additional decorations on the interface symbols with
+...@code{__declspec(dllimport)} and @code{__declspec(dllexport)} depending
+on if the library is built or if it's consumed and how it's built and
+consumed. However, it should be noted that it would have worked also
+with Microsoft tools, if only the variable three hadn't been there, due
+to the fact the Microsoft tools will automatically import functions (but
+sadly not variables) and Libtool will automatically export non-static
+symbols as described next.
+
+With Microsoft tools, Libtool will dig through the object files that
+make up the library, looking for non-static symbols to automatically
+export.  I.e., Libtool with Microsoft tools is trying to mimic the auto-
+export feature of the contemporary GNU tools.  It should be noted that
+the GNU auto-export feature is turned off when an explicit
+...@code{__declspec(dllexport)} is seen.  The GNU tools do this to not make
+more symbols visible for projects that have already taken the trouble to
+decorate symbols.  There is no similar way to limit which symbols are
+visible in the code when Libtool 

Re: Unwanted shared runtime libraries getting added

[Peter Rosin]

Hi Ethan,

Den 2010-11-08 21:39 skrev Ethan A Mallove:
> On 10/21/10 00:13, Ralf Wildenhues wrote:
>> Hello Ethan,
>>
>> * Ethan Mallove wrote on Wed, Oct 20, 2010 at 10:32:11PM CEST:
 It looks like that gives us the link line we want, yet we still get the
 libimf.so dependency:

 $ /bin/sh ../../../libtool --tag=CC   --mode=link icpc  -O3 -DNDEBUG -Wall 
 -static-intel -m64 -finline-functions -fexceptions -pthread -version-info 
 0:0:0 -export-dynamic  -fexceptions  -o libmpi_cxx.la -rpath 
 /opt/SUNWhpc/HPC9.0/intel/lib/lib64 mpicxx.lo intercepts.lo comm.lo 
 datatype.lo win.lo file.lo ../../../ompi/libmpi.la -lnsl  -lutil 
 libtool: link: icc -shared  .libs/mpicxx.o .libs/intercepts.o .libs/comm.o 
 .libs/datatype.o .libs/win.o .libs/file.o   -Wl,-rpath -Wl,$ORIGIN 
 -Wl,-rpath -Wl,$ORIGIN/.. -Wl,-rpath -Wl,$ORIGIN/../../lib/64 -Wl,-rpath 
 -Wl,$ORIGIN -Wl,-rpath -Wl,$ORIGIN/.. -Wl,-rpath -Wl,$ORIGIN/../../lib/64 
 ../../../ompi/.libs/libmpi.so -ldl -lnsl -lutil  -m64 -pthread   -pthread 
 -Wl,-soname -Wl,libmpi_cxx.so.0 -o .libs/libmpi_cxx.so.0.0.0
 $ ldd .libs/libmpi_cxx.so.0.0.0
 libmpi.so.0 => not found
 libdl.so.2 => /lib64/libdl.so.2 (0x2b35a9499000)
 libnsl.so.1 => /lib64/libnsl.so.1 (0x2b35a969e000)
 libutil.so.1 => /lib64/libutil.so.1 (0x2b35a98b6000)
 libimf.so => not found
 libsvml.so => not found
 libm.so.6 => /lib64/libm.so.6 (0x2b35a9aba000)
 libintlc.so.5 => not found
 libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x2b35a9d3e000)
 libpthread.so.0 => /lib64/libpthread.so.0 (0x2b35a9f4c000)
 libc.so.6 => /lib64/libc.so.6 (0x2b35aa167000)
 /lib64/ld-linux-x86-64.so.2 (0x003a2000)
>>> The problem is that Libtool is stripping -static-intel from the link
>>> line.  How can I prevent this?
>>
>> Pass -Wc,-static-intel instead.
>>
>> Cheers,
>> Ralf
> Thanks. 
> 
> It looks like some subdirs in the same source tree require different syntax. 
> E.g., here it barfs on -Wc,-static-intel (after it changes -Wc to -Wl!):

A fix for the -Wc -> $wl mixup when linking was commited September 4
2009 (v2.2.6-139-gc9bbeef). What version of Libtool are you using? 
You can circumvent that bug in older libtool by using
"-Xcompiler -static-intel" instead of "-Wc,-static-intel".

> $ /bin/sh ../../../libtool --tag=CC --mode=link icc -O3 -DNDEBUG -Wall 
> -Wc,-static-intel -m32 -finline-functions -fno-strict-aliasing -restrict 
> -fexceptions -pthread -fvisibility=hidden -export-dynamic -fexceptions -o 
> opal_wrapper opal_wrapper.o ../../../opal/libopen-pal.la -lnsl -lutil
> libtool: link: icc -O3 -DNDEBUG -Wall -Wl,-static-intel -m32 
> -finline-functions -fno-strict-aliasing -restrict -fexceptions -pthread 
> -fvisibility=hidden -fexceptions -o .libs/opal_wrapper opal_wrapper.o 
> -Wl,--export-dynamic  ../../../opal/.libs/libopen-pal.so -ldl -lnsl -lutil 
> -pthread -Wl,-rpath -Wl,$ORIGIN -Wl,-rpath -Wl,$ORIGIN/.. -Wl,-rpath 
> -Wl,$ORIGIN/../lib
> ipo: warning #11015: Warning unknown option -static-intel
> ld: unrecognized -a option `tic-intel'
> 
> Remove the -Wc, and the problem seems to go away:
> 
> $ /bin/sh ../../../libtool --tag=CC --mode=link icc -O3 -DNDEBUG -Wall 
> -static-intel -m32 -finline-functions -fno-strict-aliasing -restrict 
> -fexceptions -pthread -fvisibility=hidden -export-dynamic -fexceptions -o 
> opal_wrapper opal_wrapper.o ../../../opal/libopen-pal.la -lnsl -lutil
> libtool: link: icc -O3 -DNDEBUG -Wall -static-intel -m32 -finline-functions 
> -fno-strict-aliasing -restrict -fexceptions -pthread -fvisibility=hidden 
> -fexceptions -o .libs/opal_wrapper opal_wrapper.o -Wl,--export-dynamic  
> ../../../opal/.libs/libopen-pal.so -ldl -lnsl -lutil -pthread -Wl,-rpath 
> -Wl,$ORIGIN -Wl,-rpath -Wl,$ORIGIN/.. -Wl,-rpath -Wl,$ORIGIN/../lib
> 
> Is there a way to remove the -Wc in one subdirectory?  Do I need to set 
> libmpi_cxx_la_LINK in this subdir also?

I don't expect that to be necessary with the above workaround.

Cheers,
Peter

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: func_convert_file_cygwin_to_w32 woes

[Peter Rosin]

Den 2011-01-01 04:53 skrev Dan McMahill:
> I am trying to build a program under cygwin but using the mingw tool
> chain in a fake cross build way.  In my configure environment, I have:
> 
>  export lt_cv_to_tool_file_cmd=func_convert_file_cygwin_to_w32
> 
> as suggested by the libtool manual.  I'm using libtool 2.4.
> 
> Everything goes smoothly until install time when libtool calls ranlib
> (the mingw one) on an absolute path and of course the cygwin absolute
> path doesn't make sense to the mingw ranlib.  I thought that's what the
> func_convert... bit was for.

It is. My guess is that you have hit a bug, unfortunately I'm drowning
in work at the moment, so it will be a while before I can have a deeper
look. Ranlib invocations are also pretty spread out so the fix might
be intrusive...

> A full understanding of libtool internals escapes me.  Is there
> something else I should be doing or can anyone suggest good ways to
> troubleshoot this?

I'm not sure, but maybe you can skip ranlib altogether? (i.e. try
RANLIB=: when you configure)

Cheers,
Peter

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: func_convert_file_cygwin_to_w32 woes

[Peter Rosin]

Den 2011-01-04 05:39 skrev Dan McMahill:
> On 1/2/2011 12:37 AM, Ralf Wildenhues wrote:
>> Hi Dan,
>>
>> * Dan McMahill wrote on Sat, Jan 01, 2011 at 04:53:25AM CET:
>>> I am trying to build a program under cygwin but using the mingw tool
>>> chain in a fake cross build way.  In my configure environment, I have:
>>>
>>>  export lt_cv_to_tool_file_cmd=func_convert_file_cygwin_to_w32
>>>
>>> as suggested by the libtool manual.  I'm using libtool 2.4.
>>>
>>> Everything goes smoothly until install time when libtool calls ranlib
>>> (the mingw one) on an absolute path and of course the cygwin absolute
>>> path doesn't make sense to the mingw ranlib.  I thought that's what the
>>> func_convert... bit was for.
>>
>> Please copy and paste 'libtool --mode={link,relink,install}' commands
>> for the libraries and programs involved.  We may provide better help
>> then.
> 
> attached.

Ok, I found a couple of minutes to look at this. Can you check if this
patch helps?

(It still needs a ChangeLog etc...)

Cheers,
Peter

>From 589ec246bb679612441a849d852b153cf4820466 Mon Sep 17 00:00:00 2001
From: Peter Rosin 
Date: Tue, 4 Jan 2011 17:39:06 +0100
Subject: [PATCH] Convert ranlib argument to toolchain format.

---
 libltdl/config/ltmain.m4sh |4 
 libltdl/m4/libtool.m4  |6 +++---
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 336d97b..036fa1b 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -2412,6 +2412,8 @@ func_mode_install ()
 
   # Set up the ranlib parameters.
   oldlib="$destdir/$name"
+  func_to_tool_file "$oldlib" func_convert_file_msys_to_w32
+  tool_oldlib=$func_to_tool_file_result
 
   func_show_eval "$install_prog \$file \$oldlib" 'exit $?'
 
@@ -8370,6 +8372,8 @@ EOF
esac
  done
fi
+   func_to_tool_file "$oldlib" func_convert_file_msys_to_w32
+   tool_oldlib=$func_to_tool_file_result
eval cmds=\"$old_archive_cmds\"
 
func_len " $cmds"
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 4239395..c144755 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -1448,13 +1448,13 @@ old_postuninstall_cmds=
 if test -n "$RANLIB"; then
   case $host_os in
   openbsd*)
-old_postinstall_cmds="$old_postinstall_cmds~\$RANLIB -t \$oldlib"
+old_postinstall_cmds="$old_postinstall_cmds~\$RANLIB -t \$tool_oldlib"
 ;;
   *)
-old_postinstall_cmds="$old_postinstall_cmds~\$RANLIB \$oldlib"
+old_postinstall_cmds="$old_postinstall_cmds~\$RANLIB \$tool_oldlib"
 ;;
   esac
-  old_archive_cmds="$old_archive_cmds~\$RANLIB \$oldlib"
+  old_archive_cmds="$old_archive_cmds~\$RANLIB \$tool_oldlib"
 fi
 
 case $host_os in
-- 
1.7.2.3


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: func_convert_file_cygwin_to_w32 woes

[Peter Rosin]

Den 2011-01-05 05:30 skrev Dan McMahill:
> On 1/4/2011 11:44 AM, Peter Rosin wrote:
>> Den 2011-01-04 05:39 skrev Dan McMahill:
>>> On 1/2/2011 12:37 AM, Ralf Wildenhues wrote:
>>>> Hi Dan,
>>>>
>>>> * Dan McMahill wrote on Sat, Jan 01, 2011 at 04:53:25AM CET:
>>>>> I am trying to build a program under cygwin but using the mingw tool
>>>>> chain in a fake cross build way.  In my configure environment, I have:
>>>>>
>>>>>  export lt_cv_to_tool_file_cmd=func_convert_file_cygwin_to_w32
>>>>>
>>>>> as suggested by the libtool manual.  I'm using libtool 2.4.
>>>>>
>>>>> Everything goes smoothly until install time when libtool calls ranlib
>>>>> (the mingw one) on an absolute path and of course the cygwin absolute
>>>>> path doesn't make sense to the mingw ranlib.  I thought that's what the
>>>>> func_convert... bit was for.
>>>>
>>>> Please copy and paste 'libtool --mode={link,relink,install}' commands
>>>> for the libraries and programs involved.  We may provide better help
>>>> then.
>>>
>>> attached.
>>
>> Ok, I found a couple of minutes to look at this. Can you check if this
>> patch helps?
>>
>> (It still needs a ChangeLog etc...)
>>
>> Cheers,
>> Peter
>>
> 
> 
> I'm not running a git version but applying the patch to the libtool-2.4
> I was using worked.  This seems to address the problem.
> 
> Many thanks.

And thank you Dan, for confirming!  Is it ok to add your name to the THANKS
file?

Before I tie up the lose ends with this patch, I wonder if Ralf (or someone
else) could tell me if I should also fix the other assignments of
old_archive_cmds -- such as in the below snippet -- or is that completely
irrelevant?

Cheers,
Peter

  irix5* | irix6*)
case $cc_basename in
  CC*)
# SGI C++
_LT_TAGVAR(archive_cmds, $1)='$CC -shared -all -multigot 
$predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -soname 
$soname `test -n "$verstring" && func_echo_all "-set_version $verstring"` 
-update_registry ${output_objdir}/so_locations -o $lib'

# Archives containing C++ object files must be created using
# "CC -ar", where "CC" is the IRIX C++ compiler.  This is
# necessary to make sure instantiated templates are included
# in the archive.
_LT_TAGVAR(old_archive_cmds, $1)='$CC -ar -WR,-u -o $oldlib 
$oldobjs'
;;

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Libtool is looking for main() when linking shared library

[Peter Rosin]

Den 2011-03-21 07:36 skrev Satz Klauer:
> Hi,
> 
> I try to use libtool to limit the number of symbols exported by a
> shared library. My previous call to create this library looked like
> this and worked fine:
> 
> g++ -shared   -o ../libmylib.so libmylib.o -pthread -ldl
> 
> Now I modified it so that my resulting libmylib.so only exports
> symbols that start with mylib_ :
> 
> libtool --mode=link g++ -shared   -o ../libmylib.so libmylib.o
> -pthread -ldl -export-symbols-regex mylib_
> 
> But despite the keyword "shared" now libtool complains about a missing
> function main(), means it tries to create an executable program
> instead of a shared library.
> 
> What am I doing wrong here?

-shared is not how you tell libtool to build a shared library (and you do
not want to build a shared library behind the back of libtool by manually
passing -shared to g++, that would defeat the purpose of libtool). You need
to specify "-rpath /where/to/install" to make libtool build what is called
a "libtool library".  If a "libtool library" ends up shared, static or
both depends on the system and on how libtool was configured (see
configure options --disable-shared and --disable-static).  You also want
to link with .lo files instead of .o files, i.e. "libtool objects" instead
of ordinary plain old objects.  "Libtool objects" are created with e.g.
"libtool --mode=compile g++ -o foo.lo foo.cpp" instead of plain old
"g++ -o foo.o foo.cpp"

So,

libtool --mode=compile g++ -o libmylib.lo libmylib.cpp
libtool --mode=link g++ -o ../libmylib.la libmylib.lo -pthread -ldl 
-export-symbols-regex mylib_ -rpath /usr/local/lib

might work better (untested)

Cheers,
Peter

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Libtool is looking for main() when linking shared library

[Peter Rosin]

Den 2011-03-21 12:34 skrev Satz Klauer:
> On 3/21/11, Peter Rosin wrote:
>> So,
>>
>> libtool --mode=compile g++ -o libmylib.lo libmylib.cpp
>> libtool --mode=link g++ -o ../libmylib.la libmylib.lo -pthread -ldl
>> -export-symbols-regex mylib_ -rpath /usr/local/lib
>>
>> might work better (untested)
> 
> That works a bit better - so at least I get a shared library now.

Now I have tested my suggestion, and I had forgotten the -c in the
compile step...

> Unfortunately the -export-symbols-regex  seem not to work, it still
> exports all symbols, not only the ones that start with/contain
> "mylib_".

...but after adding that it works for me to limit symbol visibility with
the above.  So, it might be that libtool does not support limiting symbol
visibility on your system?  I couldn't tell, and am probably not the
right person to further debug this.

So, please post further details on your OS etc.  See section 2 in

http://git.savannah.gnu.org/cgit/libtool.git/tree/README

Cheers,
Peter

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows

[Peter Rosin]

Den 2011-06-17 01:15 skrev Bob Friesenhahn:
> On Thu, 16 Jun 2011, Vadim Zeitlin wrote:
>> BF>
>> BF> In what way was libtool specifically requested to build a DLL?
>>
>> I'm not sure about the details (please keep in mind that we're speaking
>> about libxml2 here and not my own project) but configure[*] is passed
>> --disable-static option and AFAIK this is handled by AM_PROG_LIBTOOL as
>> meaning that [only] shared libraries should be built, isn't it?
> 
> It does seem like falling back to building a static library when 
> --disable-static has been specified is a bug.
> 
>> IOW I don't think an example when proceeding ahead is a viable solution is
>> possible. Do you have anything concrete in mind?
> 
> As it happens, GCC under MinGW and Cygwin does have an "auto-import" facility
> which magically allows it to work for code built with GCC. Explicit
> dllexport/dllimport is not needed. It does not work for MSVC and might
> not work if GCC is linking against a MSVC-built DLL/library.

Hrmm, hrmm, allow me to step into this conversation and make a note that
there are libraries that work just fine in all kinds of ways when built
with MSVC. Libtool can with those libraries produce both a static and a
shared library and you can write applications that need not know, at
compile time, if they are going to be linked with the shared or the
static library. And it's not that difficult either. Heck, I can do it :-)

Granted, you will probably(?) take an extra pointer dereference if you
are actually linking with the static library, but it works. The libtool
testsuite would have more fails with MSVC if this was not the case.

>> BF> If libtool simply refuses to proceed, then many applications will fail
>> BF> to build and users will also be unhappy.
>>
>> Again, I don't think such change could break anything because applications
>> that would rely on this behaviour wouldn't build even right now.
> 
> I have experienced such issues before but my own application did still build 
> and work.
> 
> A library which is expected to be loaded by another program such as a DLL or
> loadable module would obviously be broken by static linkage.

Yes, I agree, there are obviously cases where a static lib does not
fill the shoes of a shared lib...

Cheers,
Peter

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows

[Peter Rosin]

Den 2011-06-23 11:22 skrev Vadim Zeitlin:
> Charles Wilson  cwilson.fastmail.fm> writes:
> 
>> On 6/21/2011 8:29 AM, Vadim Zeitlin wrote:
>>> Charles Wilson  writes:
 No, I think --disable-static, if specified, should actually *disable
 static*.  That should be sufficient.

 If it's not doing that, then it's a bug IMO.
>>>
>>>  Just to confirm: no, currently it doesn't do this. The example of my
>>> original message came from libxml2 build configured with --disable-static.
>>>
>>>  So should I try to create a patch making libtool fail in this case?
>>
>> I think so.
> 
>  So I did try. Unfortunately I didn't succeed because after looking closer
> at libtool sources, things turned out to be much more complicated than I
> thought -- or at least very different from what I thought that would be.
> 
>  I naively expected the presence of "-no-undefined" in foo_la_LDFLAGS to
> result in passing the equivalent of "-Wl,-no-undefined" to the compiler for
> the platforms where shared libraries with undefined symbols are supported
> (i.e. allow_undefind_flag != "unsupported"). But this is not at all what
> happens. In fact, libtool doesn't seem to have any logic for actually
> ensuring that shared libraries with -no-undefined actually have no
> undefined symbols! Indeed, just look at this transcript:
> 
>   % cat configure.ac
>   AC_INIT([foo],[1.0])
>   AM_INIT_AUTOMAKE
>   AC_CONFIG_SRCDIR([foo.c])
> 
>   LT_INIT([disable-static])
>   AC_PROG_CC
> 
>   AC_CONFIG_FILES([Makefile])
>   AC_OUTPUT
>   % cat Makefile.am
>   lib_LTLIBRARIES = libfoo.la
>   libfoo_la_SOURCES = foo.c
>   libfoo_la_LDFLAGS = -no-undefined
>   % cat foo.c
>   extern void foo();
>   void foo2()
>   {
>   foo();
>   foo();
>   }
>   % mkdir build && cd $_
>   % ../configure >/dev/null
>   % make -s
>   libtool: compile:  gcc -DPACKAGE_NAME=\"foo\" -DPACKAGE_TARNAME=\"foo\"
> -DPACKAGE_VERSION=\"1.0\" "-DPACKAGE_STRING=\"foo 1.0\""
> -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"foo\" 
> -DVERSION=\"1.0\"
> -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
> -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
> -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" 
> -I.
> -I.. -g -O2 -MT foo.lo -MD -MP -MF .deps/foo.Tpo -c ../foo.c  -fPIC -DPIC -o
> .libs/foo.o
>   libtool: link: gcc -shared  -fPIC -DPIC  .libs/foo.o-O2   
> -Wl,-soname
> -Wl,libfoo.so.0 -o .libs/libfoo.so.0.0.0
>   libtool: link: (cd ".libs" && rm -f "libfoo.so.0" && ln -s 
> "libfoo.so.0.0.0"
> "libfoo.so.0")
>   libtool: link: (cd ".libs" && rm -f "libfoo.so" && ln -s 
> "libfoo.so.0.0.0"
> "libfoo.so")
>   libtool: link: ( cd ".libs" && rm -f "libfoo.la" && ln -s "../libfoo.la"
> "libfoo.la" )
> 
> 
> I.e. it created a shared library with undefined symbols without any
> problems because it never actually passed -no-undefined to g++/ld.
> 
>  I have no idea whether -no-undefined is supposed to work like this but in
> any case it seems to me that it's perfectly useless right now. It's not
> checked at all under normal Unix systems so it can't be used to ensure that
> a shared library actually doesn't have any undefined symbols and so could
> be created under Windows too. And it *must* be always specified under
> Windows as otherwise DLL are never created at all.

If you really are targeting Windows (or some other platform which needs
-no-undefined to build libtool libraries) then you really do get a failure
if there are undefined symbols.

>  And setting allow_undefined to "yes" in the beginning of func_mode_link()
> (after commenting out the line above that sets it to "no") illustrates the
> same point: all this logic is at best useless and at worst broken as long
> as libtool doesn't have any support for actually determining whether a
> library has any undefined symbols because the *only* reasonable thing to do
> for any project that targets Windows is to use -no-undefined in LDFLAGS and
> hope for the best. In particular, the default case of having an LTLIBRARY
> that does not include -no-undefined in its LDFLAGS does not work at all
> under Windows as it will never actually create a DLL.
> 
>  Frankly, more I think about it, less I understand how could this be done
> intentionally. Am I misunderstanding something fundamental here or is all
> this just one big horrible bug?
> 
>  In any case, I'm afraid I simply don't understand the current code well
> enough (this is an euphemism, actually it doesn't make any sense at all to
> me...) to provide any useful patches.

Quoting the docs for the libtool -no-undefined option:

`-no-undefined'
 Declare that OUTPUT-FILE does not depend on any libraries other
 than the ones listed on the command line, i.e., after linking, it
 will not have unresolved symbols.  Some platforms require all
 symbols in shar

Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows

[Peter Rosin]

Den 2011-06-23 14:25 skrev Vadim Zeitlin:
> On Thu, 23 Jun 2011 13:12:42 +0200 Peter Rosin  wrote:
> 
> PR> Den 2011-06-23 11:22 skrev Vadim Zeitlin:
> PR> >  I have no idea whether -no-undefined is supposed to work like this but 
> in
> PR> > any case it seems to me that it's perfectly useless right now. It's not
> PR> > checked at all under normal Unix systems so it can't be used to ensure 
> that
> PR> > a shared library actually doesn't have any undefined symbols and so 
> could
> PR> > be created under Windows too. And it must be always specified under
> PR> > Windows as otherwise DLL are never created at all.
> PR> 
> PR> If you really are targeting Windows (or some other platform which needs
> PR> -no-undefined to build libtool libraries) then you really do get a failure
> PR> if there are undefined symbols.
> 
>  Yes but *only* if you had "-no-undefined" in your Makefile.am. If you do
> not specify "-no-undefined", you practically silently (not quite as it does
> output "libtool: link: warning: undefined symbols not allowed in $host
> shared libraries" but this is very easy to miss) get a static library
> instead, whether there are any undefined symbols or not.
> 
>  This is even worse than the original problem that I had because at least
> you had a big fat warning with plenty of asterisks in that case because
> there was another problem in that case. But if all goes perfectly well you
> still never get a shared library without "no-undefined". Even if you
> specified --disable-static as you did in my example (although IMO even
> without it silently creating static library when a shared one was requested
> is wrong). Am I the only one to think that this behaviour is singularly
> unhelpful?

Of course not, others have stated that a patch would be welcome to
fix --disable-static (and --enable-shared) to error out if it is not
possible to create a shared library (due to a missing -no-undefined).
But fixing that is a separate issue from what the default behavior
should be when -no-undefined is not specified. The think the push-
back you are sensing is because you are mixing those two issues.

The thing is, if you really do have undefined symbols, *and* are
targeting Windows (or other platforms needing -no-undefined for "normal"
libraries), there is no (clean & simple) way to explicitly declare that
you don't want libtool to attempt to build the shared lib, you can
only implicitly declare that fact by *not* specifying -no-undefined. At
the same time, you want failures to be reported back and interrupt the
build, for cases where you really do hit undefined symbols.

Let me attempt to line up all the cases:

A. We know that there are no undefined symbols, -no-undefined is
   specified.
B. We know that there are undefined symbols, -no-undefined is
   not specified.
C. Noone has bothered to check for undefined symbols, package was
   never ported to Windows, -no-undefined is not specified.

1. --disable-static in effect
2. --disable-shared in effect
3. Build both static and shared, or whatever is possible.

For A1 and B1 we want to error out on Windows if we can't find
shared versions of all dependencies, because we do not want to
risk including static libs in the resulting shared lib, and we
don't want to fall back to a static lib since a shared lib was
explicitly requested. IMO there is a bug for this case, since
currently libtool falls back to creating a static lib when it
can satisfy missing symbols with static dependencies. You also
think this is a bug, and I don't think anyone disagrees with
you, me, Bob and Chuck that it really is a bug.

For A2, B2 and C2, there is no problem, you get a static lib.
For A3 and B3, there is no problem, but you don't get a shared lib
on Windows (as desired, don't want to risk static dependencies
inside the shared lib).

For C1, it would perhaps be nice to go looking for shared versions
of all dependencies and then attempt to link the library and fail
if any of that didn't work out. But see below (-*-).

For C3, I can agree that libtool *could* look for shared versions
of all dependencies and if found, libtool *could* attempt to create
the shared lib, hoping that there would be no undefined symbols.
I.e. just as in C1, but then not error out if any of that fails but
instead just ignore the failure and proceed with a static-only
result as if nothing happened. But I must say that it would be kind
of surprising to one day get both a static lib and a shared lib, and
the next day "silently" only get a static lib because some bozo
broke something (completely unrelated) for Windows. True, the bozo
code would perhaps fail on Windows for the static case as well,
but maybe not.

And since it is a bit fragile to make that

Re: different linker parameters from similar Makefiles when building MSVC DLLs in cygwin (with erlang wrappers)

[Peter Rosin]

Den 2011-06-28 13:47 skrev Dave Cottlehuber:
> Hi libtoolers,
> 
> I am building 2 Win32 DLLs to be loaded into the erlang runtime VM as NIFs,
> based on snappy (mixed C & C++) and ejson/yajl (in C), all part of porting
> latest CouchDB trunk to Windows - config is at [8].
> 
> They use a similar Makefile.am [2],[3] and share configure.ac [1], but during
> compile & linking ejson succeeds [7] and snappy doesn't [6], despite the
> Makefiles being almost identical.
> 
> There are 2 errors reported;
> - output filename is specified twice & therefore fails
> 
> LINK : fatal error LNK1149: output filename matches input
> filename 'C:\cygwin\relax\git_couch\src\snappy\.libs\snappy_nif.dll'
> 
> - libtool adds unwanted flags, instead of -DLL (per working build)
> 
> LINK : warning LNK4044: unrecognized option '/shared'; ignored
> LINK : warning LNK4044: unrecognized option '/nostdlib'; ignored
> LINK : warning LNK4044: unrecognized option
> '/-enable-auto-image-base'; ignored
> LINK : warning LNK4044: unrecognized option '/Xlinker'; ignored
> LINK : warning LNK4044: unrecognized option '/-out-implib'; ignored
> LINK : warning LNK4044: unrecognized option '/Xlinker'; ignored
> 
> Only the final link phases differ materially in the parameters passed. If [7] 
> is
> manually run with these changes, bringing it into line with [6], it works:
> 
> - remove '-Xlinker --out-implib -Xlinker \$lib'
> - swap '-shared -nostdlib' ' for '-dll'
> 
> When libtool is hacked up [4], I can get a cleanish link [5] but this clearly
> isn't the Right Thing To Do.
> 
> What do I need to change, to ensure libtool passes the linker the same options
> in both DLLs? What am I missing?
> 
> Finally, given we are using these makefiles/configure.ac on multiple platforms
> have you got any other suggestions to improve things?

Lots of questions. Here's a a couple of my questions...
What is cc.sh? Some kind of wrapper I suppose? Have you checked how the
libtool testsuite fares when run with that wrapper?
How did you configure the different packages?
Have you tried to build with MinGW?

In my experience, attempting to write ad-hoc wrappers that makes MSVC look
like gcc is not what works best. I dearly recommend that you ditch the
cc.sh wrapper and instead use the compile wrapper from automake and trigger
its use with AM_PROG_CC_C_O in your configure.ac. Unfortunately you need
to get copies of a recent version the compile wrapper from the Automake git
repository (master branch, in the lib subdir). Also grab the ar-lib wrapper
script from there. Then configure your packages along these lines:

.../configure CC="cl -nologo" CFLAGS=-MD CXX="cl -nologo" CXXFLAGS=-MD LD=link 
AR=/path/to/ar-lib NM="dumpbin -symbols" STRIP=: RANLIB=:

Cheers,
Peter

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: different linker parameters from similar Makefiles when building MSVC DLLs in cygwin (with erlang wrappers)

[Peter Rosin]

Den 2011-06-28 16:00 skrev Peter Rosin:
> Den 2011-06-28 13:47 skrev Dave Cottlehuber:
>> Hi libtoolers,
>>
>> I am building 2 Win32 DLLs to be loaded into the erlang runtime VM as NIFs,
>> based on snappy (mixed C & C++) and ejson/yajl (in C), all part of porting
>> latest CouchDB trunk to Windows - config is at [8].
>>
>> They use a similar Makefile.am [2],[3] and share configure.ac [1], but during
>> compile & linking ejson succeeds [7] and snappy doesn't [6], despite the
>> Makefiles being almost identical.
>>
>> There are 2 errors reported;
>> - output filename is specified twice & therefore fails
>>
>> LINK : fatal error LNK1149: output filename matches input
>> filename 'C:\cygwin\relax\git_couch\src\snappy\.libs\snappy_nif.dll'
>>
>> - libtool adds unwanted flags, instead of -DLL (per working build)
>>
>> LINK : warning LNK4044: unrecognized option '/shared'; ignored
>> LINK : warning LNK4044: unrecognized option '/nostdlib'; ignored
>> LINK : warning LNK4044: unrecognized option
>> '/-enable-auto-image-base'; ignored
>> LINK : warning LNK4044: unrecognized option '/Xlinker'; ignored
>> LINK : warning LNK4044: unrecognized option '/-out-implib'; ignored
>> LINK : warning LNK4044: unrecognized option '/Xlinker'; ignored
>>
>> Only the final link phases differ materially in the parameters passed. If 
>> [7] is
>> manually run with these changes, bringing it into line with [6], it works:
>>
>> - remove '-Xlinker --out-implib -Xlinker \$lib'
>> - swap '-shared -nostdlib' ' for '-dll'
>>
>> When libtool is hacked up [4], I can get a cleanish link [5] but this clearly
>> isn't the Right Thing To Do.
>>
>> What do I need to change, to ensure libtool passes the linker the same 
>> options
>> in both DLLs? What am I missing?
>>
>> Finally, given we are using these makefiles/configure.ac on multiple 
>> platforms
>> have you got any other suggestions to improve things?
> 
> Lots of questions. Here's a a couple of my questions...
> What is cc.sh? Some kind of wrapper I suppose? Have you checked how the
> libtool testsuite fares when run with that wrapper?
> How did you configure the different packages?
> Have you tried to build with MinGW?
> 
> In my experience, attempting to write ad-hoc wrappers that makes MSVC look
> like gcc is not what works best. I dearly recommend that you ditch the
> cc.sh wrapper and instead use the compile wrapper from automake and trigger
> its use with AM_PROG_CC_C_O in your configure.ac. Unfortunately you need
> to get copies of a recent version the compile wrapper from the Automake git
> repository (master branch, in the lib subdir). Also grab the ar-lib wrapper
> script from there. Then configure your packages along these lines:
> 
> .../configure CC="cl -nologo" CFLAGS=-MD CXX="cl -nologo" CXXFLAGS=-MD 
> LD=link AR=/path/to/ar-lib NM="dumpbin -symbols" STRIP=: RANLIB=:

Oops, forgot to say, you need to do that from an MSYS shell, not a Cygwin
shell. Sorry about that...

Cheers,
Peter

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: different linker parameters from similar Makefiles when building MSVC DLLs in cygwin (with erlang wrappers)

[Peter Rosin]

Hi Dave,

Please keep replies on the list. Thanks!

Den 2011-06-29 04:20 skrev Dave Cottlehuber:
>> Den 2011-06-28 13:47 skrev Dave Cottlehuber:
>>> Hi libtoolers,
>>>
>>> I am building 2 Win32 DLLs to be loaded into the erlang runtime VM as NIFs,
>>> based on snappy (mixed C & C++) and ejson/yajl (in C), all part of porting
>>> latest CouchDB trunk to Windows - config is at [8].
>>>
>>> They use a similar Makefile.am [2],[3] and share configure.ac [1], but 
>>> during
>>> compile & linking ejson succeeds [7] and snappy doesn't [6], despite the
>>> Makefiles being almost identical.
>>>
>>> There are 2 errors reported;
>>> - output filename is specified twice & therefore fails
>>>
>>> LINK : fatal error LNK1149: output filename matches input
>>> filename 'C:\cygwin\relax\git_couch\src\snappy\.libs\snappy_nif.dll'
>>>
>>> - libtool adds unwanted flags, instead of -DLL (per working build)
>>>
>>> LINK : warning LNK4044: unrecognized option '/shared'; ignored
>>> LINK : warning LNK4044: unrecognized option '/nostdlib'; ignored
>>> LINK : warning LNK4044: unrecognized option
>>> '/-enable-auto-image-base'; ignored
>>> LINK : warning LNK4044: unrecognized option '/Xlinker'; ignored
>>> LINK : warning LNK4044: unrecognized option '/-out-implib'; ignored
>>> LINK : warning LNK4044: unrecognized option '/Xlinker'; ignored
>>>
>>> Only the final link phases differ materially in the parameters passed. If 
>>> [7] is
>>> manually run with these changes, bringing it into line with [6], it works:
>>>
>>> - remove '-Xlinker --out-implib -Xlinker \$lib'
>>> - swap '-shared -nostdlib' ' for '-dll'
>>>
>>> When libtool is hacked up [4], I can get a cleanish link [5] but this 
>>> clearly
>>> isn't the Right Thing To Do.
>>>
>>> What do I need to change, to ensure libtool passes the linker the same 
>>> options
>>> in both DLLs? What am I missing?
>>>
>>> Finally, given we are using these makefiles/configure.ac on multiple 
>>> platforms
>>> have you got any other suggestions to improve things?
>>> Thanks,
>>> Dave
> On 29 June 2011 02:00, Peter Rosin  wrote:
> 
> Thanks Peter for your reply. Inline.
> 
>> Lots of questions. Here's a a couple of my questions...
>> What is cc.sh? Some kind of wrapper I suppose?
> yup, provided with Erlang/OTP as part of their build chain under
> windows & other platforms.

Is cc.sh available for anyone to have a peek at it?

>> Have you checked how the libtool testsuite fares when run with that wrapper?
> Built from git; passes make -k without issue.

In that case, why do you need the -k option? Did you imply the "check" argument
to make or are you only saying that you can build libtool without issue?

>> Have you tried to build with MinGW?
> No; Erlang doesn't AFAIK work under MinGW yet.
> 
> 
>> How did you configure the different packages?
> Only CouchDB gets a configure; the rest are part of the couch source tree:
> 
> ./configure \
> --prefix=$ERL_TOP/release/win32 \
> --with-erlang=$ERL_TOP/release/win32/usr/include \
> --with-win32-icu-binaries=/relax/icu \
> --with-win32-curl=/relax/curl \
> --with-openssl-bin-dir=/relax/openssl/bin \
> --with-msvc-redist-dir=/relax \
> --with-js-lib=/relax/tracemonkey-57a6ad20eae9/js/src/dist/lib \
> --with-js-include=/relax/tracemonkey-57a6ad20eae9/js/src/dist/include \
> 2>&1 | tee $COUCH_TOP/build_configure.txt

How is the compiler selected as cc.sh? I wouldn't guess that autoconf
would find a compiler named cc.sh without help.

>> In my experience, attempting to write ad-hoc wrappers that makes MSVC look
>> like gcc is not what works best. I dearly recommend that you ditch the
> 
> Agreed but I'm not in a position to do that without breaking how
> Erlang is built :-(
> 
>> cc.sh wrapper and instead use the compile wrapper from automake and trigger
>> its use with AM_PROG_CC_C_O in your configure.ac. Unfortunately you need
>> to get copies of a recent version the compile wrapper from the Automake git
>> repository (master branch, in the lib subdir). Also grab the ar-lib wrapper
>> script from there. Then configure your packages along these lines:
>>
>> .../configure CC="cl -nologo" CFLAGS=-MD CXX="cl -nologo" CXXFLAGS=-

Re: Obsoleting LT_SCOPE

[Peter Rosin]

Gary V. Vaughan skrev 2011-10-25 12:51:
> Hi Chuck,
> 
> I note that no other GNU projects that I'm aware of jump through all the
> __declspec hoops that the libltdl API tries to provide through LT_SCOPE.
> Is any of this stuff still required on any non-museum Windows compiler
> that would break if I removed it?
> 
> Here's what I'm proposing to do for the upcoming libtool alpha release:
> 
>   1. Remove all traces of LT_SCOPE, and just use plain 'extern' in
>  public header files.
>   2. Remove the code for setting and passing LTDL_DLL_IMPORT.
>   3. I can then safely eliminate $prefix/include/libltdl/lt_system.h,
>  and simplify the public headers for libltdl considerably.
> 
> Do you forsee any issues on Windows with my doing that?
> 
> I'm almost certain that modern gcc and hence cygwin and variants will
> continue to work correctly without LT_SCOPE, LTDL_DLL_IMPORT and friends,
> but I have no clue whether vendor compilers that currently work (or at
> least are supported and supposed to work) with the current release are
> relying on LT_SCOPE magic from libltdl.

I'm fairly certain that removing LT_SCOPE wholesale would break Libtool
in one way or the other for Microsoft Visual C. Please don't do it
without checking the effects on the testsuite first.

I can check if you provide a patch.

Cheers,
Peter

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Obsoleting LT_SCOPE

[Peter Rosin]

Bob Friesenhahn skrev 2011-10-25 16:00:
> On Tue, 25 Oct 2011, Gary V. Vaughan wrote:
> 
>> Hi Chuck,
>>
>> I note that no other GNU projects that I'm aware of jump through all the
>> __declspec hoops that the libltdl API tries to provide through LT_SCOPE.
>> Is any of this stuff still required on any non-museum Windows compiler
>> that would break if I removed it?
> 
> Isn't this functionality required for every Windows compiler other than GCC?

(testsuites for 2.4.2-no-lt-scope, at 113 in the new testsuite, and 2.4.2,
at 106, currently running. No visible difference so far, but the massive
Link option thorough search test is still todo for both. Stay tuned)

IIRC, for Microsoft Visual C, the minimal cruft in this area is to let
libtool dig out the exports when building DLLs and export them and then to
always declare symbols dllimport when using the library, even if you link
with a static version of the library. But IIRC it will not work to link
with a DLL unless you have declared the symbols dllimport so I can't see
how it's going to work with only an extern.

Do we not have any tests where the dynamic version of libltdl is used?
Because I'm surprised to not have seen any new testsuite fails by now...

Also, by removing LT_SCOPE you will cause regressions for gcc users in
projects that declare other symbols dllexport, because doing that for any
one symbol will disable the autoexport of other symbols (e.g. if you build
a shared lib that contains a libltdl convenience lib). I think.
I.e., the current behavior has potentially forced others to declare symbols
dllexport, and now those dllexports prevent Libtool from removing its
own dllexports without introducing a flag day. I think.

Cheers,
Peter

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Obsoleting LT_SCOPE

[Peter Rosin]

Gary V. Vaughan skrev 2011-10-25 14:17:
> Hi Peter,
> 
> On 25 Oct 2011, at 18:12, Peter Rosin wrote:
>> Gary V. Vaughan skrev 2011-10-25 12:51:
>>> I note that no other GNU projects that I'm aware of jump through all the
>>> __declspec hoops that the libltdl API tries to provide through LT_SCOPE.
>>> Is any of this stuff still required on any non-museum Windows compiler
>>> that would break if I removed it?
>>>
>>> Here's what I'm proposing to do for the upcoming libtool alpha release:
>>>
>>>  1. Remove all traces of LT_SCOPE, and just use plain 'extern' in
>>> public header files.
>>>  2. Remove the code for setting and passing LTDL_DLL_IMPORT.
>>>  3. I can then safely eliminate $prefix/include/libltdl/lt_system.h,
>>> and simplify the public headers for libltdl considerably.
>>>
>>> Do you forsee any issues on Windows with my doing that?
>>>
>>> I'm almost certain that modern gcc and hence cygwin and variants will
>>> continue to work correctly without LT_SCOPE, LTDL_DLL_IMPORT and friends,
>>> but I have no clue whether vendor compilers that currently work (or at
>>> least are supported and supposed to work) with the current release are
>>> relying on LT_SCOPE magic from libltdl.
>>
>> I'm fairly certain that removing LT_SCOPE wholesale would break Libtool
>> in one way or the other for Microsoft Visual C. Please don't do it
>> without checking the effects on the testsuite first.
>>
>> I can check if you provide a patch.
> 
> Awesome, thanks.
> 
> I put up a set of tarballs from a make distcheck of the 2.4.2 release with
> a minimal patch that simply forces LT_SCOPE to always be extern.  You can get
> them here:
> 
>   http://vaughan.pe/libtool/libtool-2.4.2-no-lt-scope.tar.gz
>   http://vaughan.pe/libtool/libtool-2.4.2-no-lt-scope.tar.xz
> 
> Obviously they passed a full distcheck on my machine, and I'm quietly hoping
> there'll be no regressions on your machines compared to the raw 2.4.2
> release I put out recently.  If so, that covers point 1 of my original post,
> and I can seriously tidy up the installed files from libltdl and start
> thinking more about point 2 as well.
> 
> Let me know how you get on.

I configures both the way I usually configure libtool for msvc, i.e.

../configure autobuild_mode=msvc CC="/c/cygwin/home/peda/automake/lib/compile 
cl" CFLAGS="-MD -Zi -EHsc" CXX="/c/cygwin/home/peda/automake/lib/compile cl" 
CXXFLAGS="-MD -Zi -EHsc" LD=link NM="dumpbin -symbols" STRIP=: 
AR="/c/cygwin/home/peda/automake/lib/ar-lib lib" RANLIB=: F77=no FC=no GCJ=no

The testsuite result seems identical, with two good old failures:

old testsuite:
FAIL: tests/demo-deplibs.test

new testsuite:
107: test --with-pic FAILED (with-pic.at:40)

But see my response to Bob's mail for further fodder for thought...

I should also state that this is the first time I tried the Libtool testsuite
with the real Visual Studio 2010, and that I don't have any older version
installed on my newish machine (yet). So, conclusions are a bit unreliable...

Cheers,
Peter

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Obsoleting LT_SCOPE

[Peter Rosin]

Gary V. Vaughan skrev 2011-10-25 18:07:
> I should also add:
> 
> On 25 Oct 2011, at 21:34, Peter Rosin wrote:
>> Bob Friesenhahn skrev 2011-10-25 16:00:
>>> On Tue, 25 Oct 2011, Gary V. Vaughan wrote:
>>>> I note that no other GNU projects that I'm aware of jump through all the
>>>> __declspec hoops that the libltdl API tries to provide through LT_SCOPE.
>>>> Is any of this stuff still required on any non-museum Windows compiler
>>>> that would break if I removed it?
>>>
>>> Isn't this functionality required for every Windows compiler other than GCC?
> 
> That certainly used to be the case, and at the time we introduced it, even
> gcc on windows couldn't build a libltdl DLL that worked correctly without it.
> 
> But, it seems to me that we are the only project (at least that I'm able to
> find easily) that goes to this trouble.  Not that I want to break our support
> for additional platforms at all, but I wonder whether we might be clinging to
> the past a little with LT_SCOPE?
> 
>> (testsuites for 2.4.2-no-lt-scope, at 113 in the new testsuite, and 2.4.2,
>> at 106, currently running. No visible difference so far, but the massive
>> Link option thorough search test is still todo for both. Stay tuned)
>>
>> IIRC, for Microsoft Visual C, the minimal cruft in this area is to let
>> libtool dig out the exports when building DLLs and export them and then to
>> always declare symbols dllimport when using the library, even if you link
>> with a static version of the library. But IIRC it will not work to link
>> with a DLL unless you have declared the symbols dllimport so I can't see
>> how it's going to work with only an extern.
> 
> My recollection is that it was only necessary for data exports, but our
> entire API is defined in terms of function exports now... and the comment
> in lt_system.h says:
> 
> /* DLL building support on win32 hosts;  mostly to workaround their
>ridiculous implementation of data symbol exporting. */
> 
> Still crossing my fingers that there's room for us to simplify and remove
> some cruft.

Ahhh, data exports.  That's it.  Now I have actually looked up what I'm
doing in a library project that has data exports.

Export variables: extern
Export functions: /* nothing, but extern would also work, famous last words */
Import variables: extern __declspec(dllimport)
Import functions: extern

And this works (with some warnings) even if linking against a static version
of the library in question (which is nice since you are therefore not
required to know at compile time if you are going to link against the
shared or the static lib).

So one question is if libltdl really is free from data exports. I think not,
what about lt_preloaded_symbols?

Another question is what to do about cccl users.  Libtool is not capable
of auto-exporting symbols in the cccl case, Libtool only does that in case
MSVC is used w/o cccl.  I bet there are users out there still using cccl,
but I could not get in contact with them when I was working on Libtool.
I have no desire to dig into the cccl code in Libtool. One reason is that
I don't know what version of cccl I should use, everybody and his brother
seem to have added hacks of their own with no clear upstream. Another is
that it would take too much of my precious spare time with little reward.

Cheers,
Peter

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Obsoleting LT_SCOPE

[Peter Rosin]

Charles Wilson skrev 2011-10-25 17:34:
> On 10/25/2011 11:03 AM, Peter Rosin wrote:
>> Gary V. Vaughan skrev 2011-10-25 14:17:
>> I configures both the way I usually configure libtool for msvc, i.e.
>>
>> ../configure autobuild_mode=msvc 
>> CC="/c/cygwin/home/peda/automake/lib/compile cl" CFLAGS="-MD -Zi -EHsc" 
>> CXX="/c/cygwin/home/peda/automake/lib/compile cl" CXXFLAGS="-MD -Zi -EHsc" 
>> LD=link NM="dumpbin -symbols" STRIP=: 
>> AR="/c/cygwin/home/peda/automake/lib/ar-lib lib" RANLIB=: F77=no FC=no GCJ=no
>>
>> The testsuite result seems identical, with two good old failures:
> 
> Be sure and check the exports from libltdl*.dll from  and ...

Right, good suggestion:

$ diff -u libtool-2.4.2/msvc/libltdl/.libs/ltdl.dll.lib.nm 
libtool-2.4.2-no-lt-scope/msvc/libltdl/.libs/ltdl.dll.lib.nm
--- libtool-2.4.2/msvc/libltdl/.libs/ltdl.dll.lib.nm2011-10-25 20:44:58 
+0200
+++ libtool-2.4.2-no-lt-scope/msvc/libltdl/.libs/ltdl.dll.lib.nm
2011-10-25 20:44:21 +0200
@@ -21,15 +21,6 @@
  I .idata$4
  I .idata$5
  I .idata$6
- T .text
- U __IMPORT_DESCRIPTOR_ltdl-7
- I __imp__loadlibrary_LTX_get_vtable
- T _loadlibrary_LTX_get_vtable
-
-ltdl-7.dll:
- I .idata$4
- I .idata$5
- I .idata$6

 ltdl-7.dll:
  I .idata$4

I'm not sure what the implication is, but I think it's benign. I suspect that
the loadlibrary convenience lib is preloaded by libltdl and that stock 2.4.2
dllimports the symbol even though it's not really the right thing to do since
the symbol is right there in the static convenience lib.

However, and more importantly, I also found this in the build logs of both
stock 2.4.2 and 2.4.2-no-lt-scope:

cl -link -EXPORT:lt__alloc_die,DATA
...
   -link -EXPORT:lt_ltdl_LTX_preloaded_symbols,DATA
...

So, there are indeed data exports in libltdl. Anyone trying to make use of
those exports w/o LT_SCOPE doing the dllimport dance will probably fail. So,
we need a test case exercising one or the other of those exports. Or both.

Cheers,
Peter

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Obsoleting LT_SCOPE

[Peter Rosin]

Peter Rosin skrev 2011-10-25 21:11:

*snip*

> However, and more importantly, I also found this in the build logs of both
> stock 2.4.2 and 2.4.2-no-lt-scope:
> 
> cl -link -EXPORT:lt__alloc_die,DATA
> ...
>-link -EXPORT:lt_ltdl_LTX_preloaded_symbols,DATA
> ...
> 
> So, there are indeed data exports in libltdl. Anyone trying to make use of
> those exports w/o LT_SCOPE doing the dllimport dance will probably fail. So,
> we need a test case exercising one or the other of those exports. Or both.

I tried briefly to write tests for those two and quickly ran into
problems coming up with any meaningful test...

It appears that lt__alloc_die is only ever used by internal functions of
libltdl, so it should not need to be an export (LT_SCOPE). A plain extern
should be enough for that symbol, always. The symbol is also not visible
in any public header, so any (ab)users deserve to lose big time.

For the other exported data symbol (lt_ltdl_LTX_preloaded_symbols), it
appears that it is also an internal artifact that is not really a part
of the API and also not really meant to be touched by anything external
to the finished library. The symbol is also not exported when building
with gcc (although named lt_libltdl_LTX_preloaded_symbols there), as it
is a plain extern (and since there are other symbols explicitly declared
dllexport, this one is not exported, so switching over to plain extern
everywhere and relying on auto-export would expose this symbol for gcc
builds as well). It is visible when using MSVC since Libtool exports all
non-static symbols for MSVC (unless you use one of the -export-symbols*
options).

I.e., there are no data symbols to import, just data symbols leaking out.
In other words, no need to dllimport anything since MSVC auto-imports
functions.


So, to sum up my current understanding of the situation:

* For gcc, there would be a flag day due to the troubles described by
  me [1] and by Roumen [2]. I think we describe the same issue. I'm not
  sure it is possible to give a warning in advance without adding an
  option to activate the new non-LT_SCOPE-style extern declaration and
  warn if that option is not present (or force a backwards-compatibility
  option to activate the old behavior, but when to warn in that case?)
* For MSVC with cccl, it would probably break horribly. But Libtool with
  cccl is already severely broken and not even close to the level of
  support as without cccl, at least according to the testsuite. BUT,
  that is only with the versions of cccl that I have tried, there might
  be some version of cccl that works beautifully and that would break
  horribly. Search me...
* For MSVC without cccl, it is perfectly fine to drop LT_SCOPE. Given
  that the analysis about the two data exports holds of course.
* We have not discussed other compilers. Intel C Compiler anyone?
  Portland Group? Watcom? Borland? But I suppose any current Libtool
  support for those are sketchy at best and any future work could always
  piggyback on the Libtool auto-export code currently active for
  MSVC without cccl. MSVC with cccl could also add Libtool style
  auto-export I suppose. But someone has to do the legwork.
* OS/2. That's a dead end, right?

The "gcc flag-day" thing is the big issue with "MSVC with cccl" a distant
second if you ask me.

Cheers,
Peter

[1] http://lists.gnu.org/archive/html/libtool/2011-10/msg00030.html
[2] http://lists.gnu.org/archive/html/libtool/2011-10/msg00037.html

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Obsoleting LT_SCOPE

[Peter Rosin]

Sorry to reply to self.

Peter Rosin skrev 2011-10-31 12:54:
> Peter Rosin skrev 2011-10-25 21:11:
> 
> *snip*
> 
>> However, and more importantly, I also found this in the build logs of both
>> stock 2.4.2 and 2.4.2-no-lt-scope:
>>
>> cl -link -EXPORT:lt__alloc_die,DATA
>> ...
>>-link -EXPORT:lt_ltdl_LTX_preloaded_symbols,DATA
>> ...
>>
>> So, there are indeed data exports in libltdl. Anyone trying to make use of
>> those exports w/o LT_SCOPE doing the dllimport dance will probably fail. So,
>> we need a test case exercising one or the other of those exports. Or both.
> 
> I tried briefly to write tests for those two and quickly ran into
> problems coming up with any meaningful test...
> 
> It appears that lt__alloc_die is only ever used by internal functions of
> libltdl, so it should not need to be an export (LT_SCOPE). A plain extern
> should be enough for that symbol, always. The symbol is also not visible
> in any public header, so any (ab)users deserve to lose big time.
> 
> For the other exported data symbol (lt_ltdl_LTX_preloaded_symbols), it
> appears that it is also an internal artifact that is not really a part
> of the API and also not really meant to be touched by anything external
> to the finished library. The symbol is also not exported when building
> with gcc (although named lt_libltdl_LTX_preloaded_symbols there), as it
> is a plain extern (and since there are other symbols explicitly declared
> dllexport, this one is not exported, so switching over to plain extern
> everywhere and relying on auto-export would expose this symbol for gcc
> builds as well). It is visible when using MSVC since Libtool exports all
> non-static symbols for MSVC (unless you use one of the -export-symbols*
> options).
> 
> I.e., there are no data symbols to import, just data symbols leaking out.
> In other words, no need to dllimport anything since MSVC auto-imports
> functions.
> 
> 
> So, to sum up my current understanding of the situation:
> 
> * For gcc, there would be a flag day due to the troubles described by
>   me [1] and by Roumen [2]. I think we describe the same issue. I'm not
>   sure it is possible to give a warning in advance without adding an
>   option to activate the new non-LT_SCOPE-style extern declaration and
>   warn if that option is not present (or force a backwards-compatibility
>   option to activate the old behavior, but when to warn in that case?)
> * For MSVC with cccl, it would probably break horribly. But Libtool with
>   cccl is already severely broken and not even close to the level of
>   support as without cccl, at least according to the testsuite. BUT,
>   that is only with the versions of cccl that I have tried, there might
>   be some version of cccl that works beautifully and that would break
>   horribly. Search me...
> * For MSVC without cccl, it is perfectly fine to drop LT_SCOPE. Given
>   that the analysis about the two data exports holds of course.
> * We have not discussed other compilers. Intel C Compiler anyone?
>   Portland Group? Watcom? Borland? But I suppose any current Libtool
>   support for those are sketchy at best and any future work could always
>   piggyback on the Libtool auto-export code currently active for
>   MSVC without cccl.

Hmm, but what if the others don't do auto-import? Didn't think of that...

>  MSVC with cccl could also add Libtool style
>   auto-export I suppose. But someone has to do the legwork.
> * OS/2. That's a dead end, right?
> 
> The "gcc flag-day" thing is the big issue with "MSVC with cccl" a distant
> second if you ask me.
> 
> Cheers,
> Peter
> 
> [1] http://lists.gnu.org/archive/html/libtool/2011-10/msg00030.html
> [2] http://lists.gnu.org/archive/html/libtool/2011-10/msg00037.html

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Several questions about libtool

[Peter Rosin]

Russ Allbery skrev 2012-01-07 03:13:
> Bob Friesenhahn  writes:
>> Libtool's mode of operation works with static builds and on systems
>> where all libraries have to be supplied at link time.
> 
> Of which there are very few still in existence in terms of widespread use,
> since most systems now use ELF or (like Mac OS X) some other object format
> that doesn't require this.  Solaris is definitely not one of them.  I
> believe you may still need this on such platforms as AIX or HP-UX that use
> a much different object format, but I'm not at all certain of that; it's
> been years since I've used them.

You are somehow forgetting Windows, probably the most widespread system of
them all.  On Windows, you have to specify all libraries at link time and
Libtool helps with that.

Cheers,
Peter

___
https://lists.gnu.org/mailman/listinfo/libtool

Broken workflow

[Peter Rosin]

Hi!

I used to use Cygwin/git to manage my libtool repo, and bootstrap it
with Cygwin.  I would then build the bootstrapped libtool tree from
MSYS when I needed to do changes there, or check for regressions from
the Cygwin side.

This appears to no longer be possible, if I run "make check" from
MSYS, it complains with:

$ make check
  GENpublic-submodule-commit
/bin/sh: line 2: git: command not found
maint.mk: found non-public submodule commit
make: *** [public-submodule-commit] Error 1
make: Target `check' not remade because of errors.

Alas, git is not available for MSYS.  (And before you ask, msysgit is
*not* a real MSYS git, it is a MinGW git bundled with a forked MSYS
environment, i.e. a different animal altogether with an unfortunate
name)

If the only way around this is to "make dist" and untar the whole
thing in MSYS and work w/o backing of Cygwin/git while "in" MSYS, I
must say that it's a *major* fail for me, and it would be extremely
unpleasant to work with that.

Can anything be done to make things work in a git checkout without
having git available after bootstrap?  Please?

Cheers,
Peter

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Broken workflow

[Peter Rosin]

Eric Blake skrev 2012-03-16 22:58:
> On 03/16/2012 03:54 PM, Peter Rosin wrote:
>> Hi!
>>
>> I used to use Cygwin/git to manage my libtool repo, and bootstrap it
>> with Cygwin.  I would then build the bootstrapped libtool tree from
>> MSYS when I needed to do changes there, or check for regressions from
>> the Cygwin side.
>>
>> This appears to no longer be possible, if I run "make check" from
>> MSYS, it complains with:
>>
>> $ make check
>>   GENpublic-submodule-commit
>> /bin/sh: line 2: git: command not found
>> maint.mk: found non-public submodule commit
>> make: *** [public-submodule-commit] Error 1
>> make: Target `check' not remade because of errors.
> 
>> Can anything be done to make things work in a git checkout without
>> having git available after bootstrap?  Please?
> 
> It should already be possible.  To skip that check, run:
> 
> make check gl_public_submodule_commit=

Thanks!  That appears to work around it.

Cheers,
Peter

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: mingw-w64's libuuid.a : *** Warning: linker path does not have real file for library -luuid.

[Peter Rosin]

On 2012-07-20 17:49, Vincent Torri wrote:
> hey
> 
> I'm using mingw-w64 gcc (4.8.0 experimental)
> 
> I have to link a library (named Evil) against libuuid.a. That is, in
> Makefile.am :
> 
> libevil_la_LIBADD = -luuid etc..
> 
> I have the warning that I pasted in the topic:
> 
> ** Warning: linker path does not have real file for library -luuid.
> etc...
> 
> and no DLL is produced. I have worked around that by adding before LT_INIT :
> 
> lt_cv_deplibs_check_method='pass_all'
> 
> and I have now the DLL. I thought that it would have been sufficient.
> It's not. Because of the .la files (dependency_libs fieldcontains
> -luuid) , each time I link against Evil, -luuid is passed and I have
> the warning above, and no DLL is produced. Even worse, some binaries
> can not be compiled at all.
> 
> So I would like to know how I can forbid libtool to pass -luuid each
> time I link against Evil.

I ended up with the following in a separate file to work around this
craziness.  I'd also like a cleaner way to use libuuid.a/libdxguid.a
from a DLL...

Cheers,
Peter


/* libtool fails to link a dll against libdxguid.a which
 * is what we really want to do here. When libtool can do
 * that, kill this file and add -ldxguid to the link
 * command line.
 * IMHO, this is a horrid workaround. But it works, and we
 * get a dll instead of a static lib.
 */

typedef struct _IID
{
unsigned long  x;
unsigned short s1;
unsigned short s2;
unsigned char  c[8];
} IID;

typedef IID GUID;
typedef IID CLSID;

const CLSID CLSID_DirectInput   = 
{0x25E609E0,0xB259,0x11CF,{0xBF,0xC7,0x44,0x45,0x53,0x54,0x00,0x00}};
const IID  IID_IDirectInput2A   = 
{0x5944e662,0xaa8a,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const IID  IID_IDirectInputDevice2A = 
{0x5944e682,0xc92e,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const GUID GUID_Key = 
{0x55728220,0xd33c,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const GUID GUID_XAxis   = 
{0xa36d02e0,0xc9f3,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const GUID GUID_YAxis   = 
{0xa36d02e1,0xc9f3,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const GUID GUID_ZAxis   = 
{0xa36d02e2,0xc9f3,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const GUID GUID_RxAxis  = 
{0xa36d02f4,0xc9f3,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const GUID GUID_RyAxis  = 
{0xa36d02f5,0xc9f3,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const GUID GUID_RzAxis  = 
{0xa36d02e3,0xc9f3,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const GUID GUID_Slider  = 
{0xa36d02e4,0xc9f3,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const GUID GUID_POV = 
{0xa36d02f2,0xc9f3,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const GUID GUID_SysKeyboard = 
{0x6f1d2b61,0xd5a0,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const GUID GUID_SysMouse= 
{0x6f1d2b60,0xd5a0,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: mingw-w64's libuuid.a : *** Warning: linker path does not have real file for library -luuid.

[Peter Rosin]

On 2012-07-21 13:16, Vincent Torri wrote:
> another solution is to just kill the stupid .la file. There is

I don't think the .la file is stupid as it lists other important
dependencies.

> absolutely NO reason to add to the linker static libraries that are
> ONLY used in my Evil library and that are not used elsewhere.
> 
> I think that it is the best solution

That disables (easy) static linking. I, as a library author, do not
like to make that policy decision for the application author.

Cheers,
Peter

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: mingw-w64's libuuid.a : *** Warning: linker path does not have real file for library -luuid.

[Peter Rosin]

On 2012-07-21 14:49, Vincent Torri wrote:
> On Sat, Jul 21, 2012 at 2:41 PM, Peter Rosin  wrote:
>> On 2012-07-21 13:16, Vincent Torri wrote:
>>> another solution is to just kill the stupid .la file. There is
>>
>> I don't think the .la file is stupid as it lists other important
>> dependencies.
> 
> so what ? There is a HUGE problem, here. Currently, if a lib uses
> symbols in libuuid, it just can't be used to create progs/shared lib
> because the .la file lists it while it should (must) not. Static libs
> must not appear in the dependency_libs field.

Oh, but static libs do need to be listed in dependency_libs as long
as there is no other place to put them. That, or static linking is not
working well at all. I'm not willing to sacrifice static linking.

>>> absolutely NO reason to add to the linker static libraries that are
>>> ONLY used in my Evil library and that are not used elsewhere.
>>>
>>> I think that it is the best solution
>>
>> That disables (easy) static linking. I, as a library author, do not
>> like to make that policy decision for the application author.
> 
> on Windows  DLL are good. I already pass --disable-static to all my
> Windows builds.

That has been argued elsewhere, but I can still see the value of the
other side. So again, I, as a library author, do not like to shove that
policy decision down the throat of my library consumers.

Cheers,
Peter

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: mingw-w64's libuuid.a : *** Warning: linker path does not have real file for library -luuid.

[Peter Rosin]

On 2012-07-22 04:00, JonY wrote:
> On 7/22/2012 00:43, Peter Rosin wrote:
>> On 2012-07-21 14:49, Vincent Torri wrote:
>>> On Sat, Jul 21, 2012 at 2:41 PM, Peter Rosin  wrote:
>>>> On 2012-07-21 13:16, Vincent Torri wrote:
>>>>> absolutely NO reason to add to the linker static libraries that are
>>>>> ONLY used in my Evil library and that are not used elsewhere.
>>>>>
>>>>> I think that it is the best solution
>>>>
>>>> That disables (easy) static linking. I, as a library author, do not
>>>> like to make that policy decision for the application author.
>>>
>>> on Windows  DLL are good. I already pass --disable-static to all my
>>> Windows builds.
>>
>> That has been argued elsewhere, but I can still see the value of the
>> other side. So again, I, as a library author, do not like to shove that
>> policy decision down the throat of my library consumers.
> 
> So how are you supposed to build it if *I* want it as a DLL?
> 
> Rhetoric notwithstanding, how are you supposed to build a DLL that uses
> libuuid.a? No, cloning UUID constants is not a proper fix.

By not using Libtool, I suppose, or by mucking about with Libtool
internals.

Libtool needs to change to handle this situation cleanly. I don't know
how. Care should perhaps be taken so that libtool doesn't export stuff
from static libraries such as libuuid though, since the DLL consumer
could be using libuuid as well without knowing that some consumed DLL
is also pulling it in.

Cheers,
Peter

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: cannot build from git/no daily snapshots

[Peter Rosin]

On 2012-09-17 16:02, Bob Friesenhahn wrote:
> On Mon, 17 Sep 2012, Gary V. Vaughan wrote:
> 
>> Hi Bob,
>>
>> On 17 ก.ย. 2012, at 2:48, Bob Friesenhahn  
>> wrote:
> 
>>> Please make it so that it is possible to use a source tree which has a .hg 
>>> directory
>>> even if there is no 'git' program available and even if autotools are not 
>>> the exact
>>> same version used to bootstrap the tree.
>>
>> I don't have (or want) access to Windows, but bootstrap has a '--skip-git' 
>> option.
>> If you rebootstrap on your machine with that option, and the other tools 
>> (autotools,
>> m4 etc) are new enough, and it doesn't work then you've found a bug. Some 
>> warnings
>> about not finding a fit binary, and possibly out of date gnulib files are 
>> normal in
>> this scenario.
> 
> The 'm4' on this MinGW install is not a blessed version and a simple 
> build/install
> of latest m4 produces an m4 which does not work. :-(

Was that an MSYS-m4 or a MinGW-m4? Assuming it was MinGW-m4, I
think it is too much to ask to require MSYS-tools for simple
libtool hacking. If it was MSYS-m4, even worse. And the suggestion
to build a tarball and use that when developing for MinGW is
just asking too much. Insane work flow.

You have to remember that these extra steps lands on the people
spending the most time fighting (and waiting for) the build
system. I haven't touched Libtool in a while now, I wonder why,
but it was not a conscious decision. Maybe it wasn't fun anymore
for some reason? These changes does not seem attractive though.

Cheers,
Peter


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: cannot build from git/no daily snapshots

[Peter Rosin]

On 2012-09-18 03:33, Gary V. Vaughan wrote:
> Hi Bob, Peter,
> 
> On 17 ก.ย. 2012, at 23:22, Bob Friesenhahn  
> wrote:
>> On Mon, 17 Sep 2012, Peter Rosin wrote:
>>>>
>>>> The 'm4' on this MinGW install is not a blessed version and a simple 
>>>> build/install
>>>> of latest m4 produces an m4 which does not work. :-(
>>>
>>> Was that an MSYS-m4 or a MinGW-m4? Assuming it was MinGW-m4, I
>>
>> The one that came with the MSYS install was surely a MSYS-m4 and the one
>> I built was surely a native Windows m4.  The native Windows m4 I built
>> likely produces/consumes Windows text line terminations and that is why
>> it did not work (even though libtool configure accepted it).
> 
> bootstrap (and Autoconf from where I cribbed the m4 worthiness test)
> only check the supplied m4 has a version number greater than or
> equal-to the minimum known working version.
> 
> The real bug here seems to lie somewhere between modern m4 not building
> properly on Windows, and Autoconf requiring a newer m4 than supplied by
> MSYS/mingw.

There is no evidence that modern m4 does not build properly on MSYS, which
is what is interesting. A MinGW-m4 is not all that interesting in the
autotools context. What Bob tried (a MinGW-m4) was simply wrong, but the
reason for the attempt was surely because he had no tools to build MSYS
binaries installed. Very few do, and I suspect that most that do have them
installed don't know exactly what they're doing...

>>> think it is too much to ask to require MSYS-tools for simple
>>> libtool hacking. If it was MSYS-m4, even worse. And the suggestion
>>> to build a tarball and use that when developing for MinGW is
>>> just asking too much. Insane work flow.
> 
> Do people really want to do full-bore Libtool development (as opposed
> to using it to develop an occasional bugfix) on Windows?  Why?!?  Not
> being flippant here, but I'd be surprised to find that the kinds of
> people who want Libtool to work on Windows, and know enough about
> Libtool to keep it working don't have access to a pleasant OS for
> actual development, with Windows relegated to being a test machine.

I don't know if my contributions count as more than an occasional bugfix,
but I weigh-in at 100+ commits. I did all of that on Windows. I used the
occasional Linux VM, but that was exceptional. I also tested on more
esoteric systems over the Internet, but virtually all coding was done
on Windows. I don't like doing development over the Internet or in a
VM, it's too flakey for me. Maybe I'm just stupid?

> For all the Unix architectures I have access to, my workflow is to
> put an unpacked `make dist` tarball on an NFS drive, and make VPATH
> builds in a subdirectory for each machine.  Windows has some network
> mounting facility too, so that doesn't seem insane to me.

My workflow is to bootstrap on Cygwin (which is much more up to date
in the tools department) and just build on MinGW in the same checkout
but with a different build dir. What I don't want is any extra steps
such as being required to build a tarball on Cygwin just to test
MinGW.

>>> You have to remember that these extra steps lands on the people
>>> spending the most time fighting (and waiting for) the build
>>> system. I haven't touched Libtool in a while now, I wonder why,
>>> but it was not a conscious decision. Maybe it wasn't fun anymore
>>> for some reason? These changes does not seem attractive though.
> 
> What changes are you referring to?  If there is some particular
> changeset(s) that have broken previously working Windows support,
> then we should definitely figure out why, and fix the problem.

Bob wrote this:

"Please make it so that it is possible to use a source tree
which has a .hg directory even if there is no 'git' program
available and even if autotools are not the exact same
version used to bootstrap the tree."

Assuming he meant a .git directory, this is something I need for my
workflow and something which has worked, so it is a regression. I'm
not sure if I want to --skip-git in my bootstrap, because then the
Cygwin side of things are not "as usual".

Cheers,
Peter


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: cannot build from git/no daily snapshots

[Peter Rosin]

On 2012-09-18 16:44, Gary V. Vaughan wrote:
> Hi Bob,
> 
> On 18 ก.ย. 2012, at 21:23, Bob Friesenhahn  
> wrote:
>> It used to be possible to run the libtool test suite in a MSYS shell
>> using a CIFS mount of the same source tree that I use for my Unix type
>> systems.  I used to do that on a periodic basis.  Since the bootstrap
>> improvements, this does not seem to be possible.  Perhaps I might
>> encounter a MSYS install which includes the newer m4 and a workable 'git'.
> 
> I'd like to fix that.

What used to work was this:

In Cygwin:

cd to the libtool dir
git checkout master
./bootstrap --copy
mkdir ../cygwin
cd ../cygwin
../libtool/configure
make
make check

Then in MSYS:

cd to the libtool dir
mkdir ../mingw
cd ../mingw
../libtool/configure
make
make check



The above now misbehaves in the "make" step, with:

/bin/sh: line 13: git: command not found
/bin/sed -e s|@MACRO_VERSION\@|2.4.2.176-30304|g -e 
s|@MACRO_REVISION\@|UNKNOWN|g -e s|@MACRO_SERIAL\@|0|g -e 
s|@PACKAGE\@|libtool|g -e s|@PACKAGE_BUGREPORT\@|bug-libt...@gnu.org|g -e 
s|@PACKAGE_URL\@|http://www.gnu.org/software/libtool/|g -e 
s|@PACKAGE_NAME\@|GNU Libtool|g -e s|@package_revision\@|UNKNOWN|g -e 
s|@PACKAGE_STRING\@|GNU Libtool 2.4.2.176-30304|g -e 
s|@PACKAGE_TARNAME\@|libtool|g -e s|@PACKAGE_VERSION\@|2.4.2.176-30304|g -e 
s|@VERSION\@|2.4.2.176-30304|g '../libtool/m4/ltversion.in' > 
'../libtool/m4/ltversion.m4'
CDPATH="${ZSH_VERSION+.}:" && cd ../libtool && /bin/sh 
/c/Cygwin/home/peda/libtool/git/libtool/build-aux/missing --run aclocal-1.11 -I 
m4
 cd ../libtool && /bin/sh 
/c/Cygwin/home/peda/libtool/git/libtool/build-aux/missing --run automake-1.11 
--gnu
CDPATH="${ZSH_VERSION+.}:" && cd ../libtool && /bin/sh 
/c/Cygwin/home/peda/libtool/git/libtool/build-aux/missing --run autoconf
/bin/sh ./config.status --recheck

make should not trigger aclocal/automake/autoconf at this point, and some of 
the substitutions above are really bad as can also be seen below (look for 
UNKNOWN):

cat ../libtool/m4/ltversion.m4
# ltversion.m4 -- version numbers   -*- Autoconf -*-
#
#   Copyright (C) 2004, 2011-2012 Free Software Foundation, Inc.
#   Written by Scott James Remnant, 2004
#
# This file is free software; the Free Software Foundation gives
# unlimited permission to copy and/or distribute it, with or without
# modifications, as long as this notice is preserved.

# @configure_input@

# serial 0 ltversion.m4
# This file is part of GNU Libtool

m4_define([LT_PACKAGE_VERSION], [2.4.2.176-30304])
m4_define([LT_PACKAGE_REVISION], [UNKNOWN])

AC_DEFUN([LTVERSION_VERSION],
[macro_version='2.4.2.176-30304'
macro_revision='UNKNOWN'
_LT_DECL(, macro_version, 0, [Which release of libtool.m4 was used?])
_LT_DECL(, macro_revision, 0)
])


On a side note, I find it surprising that "./bootstrap --force --copy"
does not remove symlinks and copy the actual gnulib files over. I had
to remove the symlinks by hand, then "./bootstrap --copy". That took
a while to disentangle, as do all build system changes. Especially on
Windows.

Cheers,
Peter


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: cannot build from git/no daily snapshots

[Peter Rosin]

On 2012-09-18 21:21, Peter Rosin wrote:
> On 2012-09-18 16:44, Gary V. Vaughan wrote:
>> Hi Bob,
>>
>> On 18 ก.ย. 2012, at 21:23, Bob Friesenhahn  
>> wrote:
>>> It used to be possible to run the libtool test suite in a MSYS shell
>>> using a CIFS mount of the same source tree that I use for my Unix type
>>> systems.  I used to do that on a periodic basis.  Since the bootstrap
>>> improvements, this does not seem to be possible.  Perhaps I might
>>> encounter a MSYS install which includes the newer m4 and a workable 'git'.
>>
>> I'd like to fix that.
> 
> What used to work was this:
> 
> In Cygwin:
> 
> cd to the libtool dir
> git checkout master
> ./bootstrap --copy
> mkdir ../cygwin
> cd ../cygwin
> ../libtool/configure
> make
> make check
> 
> Then in MSYS:
> 
> cd to the libtool dir
> mkdir ../mingw
> cd ../mingw
> ../libtool/configure
> make
> make check
> 
> 
> 
> The above now misbehaves in the "make" step, with:
> 
> /bin/sh: line 13: git: command not found
> /bin/sed -e s|@MACRO_VERSION\@|2.4.2.176-30304|g -e 
> s|@MACRO_REVISION\@|UNKNOWN|g -e s|@MACRO_SERIAL\@|0|g -e 
> s|@PACKAGE\@|libtool|g -e s|@PACKAGE_BUGREPORT\@|bug-libt...@gnu.org|g -e 
> s|@PACKAGE_URL\@|http://www.gnu.org/software/libtool/|g -e 
> s|@PACKAGE_NAME\@|GNU Libtool|g -e s|@package_revision\@|UNKNOWN|g -e 
> s|@PACKAGE_STRING\@|GNU Libtool 2.4.2.176-30304|g -e 
> s|@PACKAGE_TARNAME\@|libtool|g -e s|@PACKAGE_VERSION\@|2.4.2.176-30304|g -e 
> s|@VERSION\@|2.4.2.176-30304|g '../libtool/m4/ltversion.in' > 
> '../libtool/m4/ltversion.m4'
> CDPATH="${ZSH_VERSION+.}:" && cd ../libtool && /bin/sh 
> /c/Cygwin/home/peda/libtool/git/libtool/build-aux/missing --run aclocal-1.11 
> -I m4
>  cd ../libtool && /bin/sh 
> /c/Cygwin/home/peda/libtool/git/libtool/build-aux/missing --run automake-1.11 
> --gnu
> CDPATH="${ZSH_VERSION+.}:" && cd ../libtool && /bin/sh 
> /c/Cygwin/home/peda/libtool/git/libtool/build-aux/missing --run autoconf
> /bin/sh ./config.status --recheck
> ...

The below appears to fix at least some issues for me. Maybe
--fallback is sane to add to more git-version-gen invocations?

Cheers,
Peter

--- gnulib/build-aux/git-version-gen2012-09-18 19:09:51.962446500 +0200
+++ build-aux/git-version-gen   2012-09-18 23:11:00.722895100 +0200
@@ -86,6 +86,7 @@
 Options:

--prefix   prefix of git tags (default 'v')
+   --fallback fallback version to use if \"git --version\" fails

--help display this help and exit
--version  output version information and exit
@@ -93,12 +94,14 @@
 Running without arguments will suffice in most cases."

 prefix=v
+fallback=

 while test $# -gt 0; do
   case $1 in
 --help) echo "$usage"; exit 0;;
 --version) echo "$version"; exit 0;;
 --prefix) shift; prefix="$1";;
+--fallback) shift; fallback="$1";;
 -*)
   echo "$0: Unknown option '$1'." >&2
   echo "$0: Try '--help' for more information." >&2
@@ -184,8 +187,10 @@
 # Remove the "g" in git describe's output string, to save a byte.
 v=`echo "$v" | sed 's/-/./;s/\(.*\)-g/\1-/'`;
 v_from_git=1
-else
+elif test -z "$fallback" || git --version >& /dev/null; then
 v=UNKNOWN
+else
+v=$fallback
 fi

 v=`echo "$v" |sed "s/^$prefix//"`

--- gnulib/top/maint.mk 2012-09-18 19:09:55.207252200 +0200
+++ maint.mk2012-09-18 23:43:31.314929500 +0200
@@ -1327,7 +1327,7 @@

 .PHONY: no-submodule-changes
 no-submodule-changes:
-   $(AM_V_GEN)if test -d $(srcdir)/.git; then  \
+   $(AM_V_GEN)if test -d $(srcdir)/.git && git --version >& /dev/null; 
then \
  diff=$$(cd $(srcdir) && git submodule -q foreach  \
  git diff-index --name-only HEAD)  \
|| exit 1;  \
@@ -1345,7 +1345,7 @@
 # cannot be built from a fresh clone.
 .PHONY: public-submodule-commit
 public-submodule-commit:
-   $(AM_V_GEN)if test -d $(srcdir)/.git; then  \
+   $(AM_V_GEN)if test -d $(srcdir)/.git && git --version >& /dev/null; 
then \
  cd $(srcdir) &&   \
  git submodule --quiet foreach test '$$(git rev-parse $$sha1)' \
  = '$$(git merge-base origin $$sha1)'  \


diff --git a/Makefile.am b/Makefile.am
index 359b394..44a885b 100644
--- a/Makefile.a

Re: cannot build from git/no daily snapshots

[Peter Rosin]

On 2012-09-18 23:50, Peter Rosin wrote:
> On 2012-09-18 21:21, Peter Rosin wrote:
>> On 2012-09-18 16:44, Gary V. Vaughan wrote:
>>> Hi Bob,
>>>
>>> On 18 ก.ย. 2012, at 21:23, Bob Friesenhahn  
>>> wrote:
>>>> It used to be possible to run the libtool test suite in a MSYS shell
>>>> using a CIFS mount of the same source tree that I use for my Unix type
>>>> systems.  I used to do that on a periodic basis.  Since the bootstrap
>>>> improvements, this does not seem to be possible.  Perhaps I might
>>>> encounter a MSYS install which includes the newer m4 and a workable 'git'.
>>>
>>> I'd like to fix that.
>>
>> What used to work was this:
>>
>> In Cygwin:
>>
>> cd to the libtool dir
>> git checkout master
>> ./bootstrap --copy
>> mkdir ../cygwin
>> cd ../cygwin
>> ../libtool/configure
>> make
>> make check
>>
>> Then in MSYS:
>>
>> cd to the libtool dir
>> mkdir ../mingw
>> cd ../mingw
>> ../libtool/configure
>> make
>> make check
>>
>>
>>
>> The above now misbehaves in the "make" step, with:
>>
>> /bin/sh: line 13: git: command not found
>> /bin/sed -e s|@MACRO_VERSION\@|2.4.2.176-30304|g -e 
>> s|@MACRO_REVISION\@|UNKNOWN|g -e s|@MACRO_SERIAL\@|0|g -e 
>> s|@PACKAGE\@|libtool|g -e s|@PACKAGE_BUGREPORT\@|bug-libt...@gnu.org|g -e 
>> s|@PACKAGE_URL\@|http://www.gnu.org/software/libtool/|g -e 
>> s|@PACKAGE_NAME\@|GNU Libtool|g -e s|@package_revision\@|UNKNOWN|g -e 
>> s|@PACKAGE_STRING\@|GNU Libtool 2.4.2.176-30304|g -e 
>> s|@PACKAGE_TARNAME\@|libtool|g -e s|@PACKAGE_VERSION\@|2.4.2.176-30304|g -e 
>> s|@VERSION\@|2.4.2.176-30304|g '../libtool/m4/ltversion.in' > 
>> '../libtool/m4/ltversion.m4'
>> CDPATH="${ZSH_VERSION+.}:" && cd ../libtool && /bin/sh 
>> /c/Cygwin/home/peda/libtool/git/libtool/build-aux/missing --run aclocal-1.11 
>> -I m4
>>  cd ../libtool && /bin/sh 
>> /c/Cygwin/home/peda/libtool/git/libtool/build-aux/missing --run 
>> automake-1.11 --gnu
>> CDPATH="${ZSH_VERSION+.}:" && cd ../libtool && /bin/sh 
>> /c/Cygwin/home/peda/libtool/git/libtool/build-aux/missing --run autoconf
>> /bin/sh ./config.status --recheck
>> ...
> 
> The below appears to fix at least some issues for me. Maybe
> --fallback is sane to add to more git-version-gen invocations?
> 
> Cheers,
> Peter
> 
> --- gnulib/build-aux/git-version-gen2012-09-18 19:09:51.962446500 +0200
> +++ build-aux/git-version-gen   2012-09-18 23:11:00.722895100 +0200
> @@ -86,6 +86,7 @@
>  Options:
> 
> --prefix   prefix of git tags (default 'v')
> +   --fallback fallback version to use if \"git --version\" fails
> 
> --help display this help and exit
> --version  output version information and exit
> @@ -93,12 +94,14 @@
>  Running without arguments will suffice in most cases."
> 
>  prefix=v
> +fallback=
> 
>  while test $# -gt 0; do
>case $1 in
>  --help) echo "$usage"; exit 0;;
>  --version) echo "$version"; exit 0;;
>  --prefix) shift; prefix="$1";;
> +--fallback) shift; fallback="$1";;
>  -*)
>echo "$0: Unknown option '$1'." >&2
>echo "$0: Try '--help' for more information." >&2
> @@ -184,8 +187,10 @@
>  # Remove the "g" in git describe's output string, to save a byte.
>  v=`echo "$v" | sed 's/-/./;s/\(.*\)-g/\1-/'`;
>  v_from_git=1
> -else
> +elif test -z "$fallback" || git --version >& /dev/null; then
>  v=UNKNOWN
> +else
> +v=$fallback
>  fi
> 
>  v=`echo "$v" |sed "s/^$prefix//"`
> 
> --- gnulib/top/maint.mk 2012-09-18 19:09:55.207252200 +0200
> +++ maint.mk2012-09-18 23:43:31.314929500 +0200
> @@ -1327,7 +1327,7 @@
> 
>  .PHONY: no-submodule-changes
>  no-submodule-changes:
> -   $(AM_V_GEN)if test -d $(srcdir)/.git; then  \
> +   $(AM_V_GEN)if test -d $(srcdir)/.git && git --version >& /dev/null; 
> then \
>   diff=$$(cd $(srcdir) && git submodule -q foreach  \
>   git diff-index --name-only HEAD)  \
> || exit 1;  \
> @@ -1345,7 +1345,7 @@
>  # cannot be built from a fresh clone.
>  .PHONY: 

func_win32_import_lib_p when file is missing

[Peter Rosin]

Hi!

After getting rid of the legacy testsuite (nice!), I'm
seeing a new failure with MSYS/MSVC in what used to be
the demo group, now demo.at.

I think it's a real libtool bug this time, and not a
simple testsuite issue.

When I do the MSVC run, I also specify that I want to
use "dumpbin -symbols" instead of nm to dig out symbols.
This in turn triggers the below else branch in libtool.m4:

mingw* | pw32*)
  # Base MSYS/MinGW do not provide the 'file' command needed by
  # func_win32_libid shell function, so use a weaker test based on 'objdump',
  # unless we find 'file', for example because we are cross-compiling.
  # func_win32_libid assumes BSD nm, so disallow it if using MS dumpbin.
  if ( test "$lt_cv_nm_interface" = "BSD nm" && file / ) >/dev/null 2>&1; then
lt_cv_deplibs_check_method='file_magic ^x86 archive import|^x86 DLL'
lt_cv_file_magic_cmd='func_win32_libid'
  else
# Keep this pattern in sync with the one in func_win32_libid.
lt_cv_deplibs_check_method='file_magic file format 
(pei*-i386(.*architecture: i386)?|pe-arm-wince|pe-x86-64)'
lt_cv_file_magic_cmd='$OBJDUMP -f'
  fi
  ;;

So, I end up with objdump as file magic command. Note that there
are some other ways to end up with objdump instead of func_win32_libid,
so this is not a problem confined to MSVC.

demo.at fails for me since func_generate_dlsyms then doesn't
recognize an import library and puts the name of import library
instead of the name of the dll in the S.c file.
libltdl then of course doesn't find any symbols in the import
library, and I get this when I run the helldl program:

stdout:
Welcome to *modular* GNU Hell!
found file: @PROGRAM@
found file: hello.dll.lib
stderr:
did not find the `nothing' variable
did not find the `foo' function
did not find the `hello' function

Of course, stderr should have been empty and the last line of stdout
should have listed the dll and not the import lib, like this:
found file: hello-2.dll


Now the question. How is the below function supposed to work
when $file_magic_cmd is '$OBJDUMP -f' and not 'func_win32_libid'?
objdump doesn't output "import" for me, at least not for any
import lib I have given it. Chunk?

# func_win32_import_lib_p ARG
# True if ARG is an import lib, as indicated by $file_magic_cmd
func_win32_import_lib_p ()
{
$debug_cmd

case `eval $file_magic_cmd \"\$1\" 2>/dev/null | $SED -e 10q` in
*import*) : ;;
*) false ;;
esac
}

Cheers,
Peter

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: func_win32_import_lib_p when file is missing

[Peter Rosin]

On 2012-10-07 06:04, Gary V. Vaughan wrote:
> Hi Peter,
> 
> On 7 Oct 2012, at 06:53, Peter Rosin  wrote:
>> How is the below function supposed to work
>> when $file_magic_cmd is '$OBJDUMP -f' and not 'func_win32_libid'?
> 
> I have no idea :(
> 
>> objdump doesn't output "import" for me, at least not for any
>> import lib I have given it. Chunk?
>>
>> # func_win32_import_lib_p ARG
>> # True if ARG is an import lib, as indicated by $file_magic_cmd
>> func_win32_import_lib_p ()
>> {
>>$debug_cmd
>>
>>case `eval $file_magic_cmd \"\$1\" 2>/dev/null | $SED -e 10q` in
>>*import*) : ;;
>>*) false ;;
>>esac
>> }
> 
> Does '$OBJDUMP -f' output anything that can be used to distinguish an
> import library?

Don't think so.

> If so, add that to the *import* leg of the case statement above.  If not,

"objdump -f" output from normal static lib:
--8<---
In archive ../msvc/tests/testsuite.dir/035/.libs/hello.lib:

libhello_la-foo.obj: file format pe-i386
architecture: i386, flags 0x003d:
HAS_RELOC, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
start address 0x

libhello_la-hello.obj: file format pe-i386
architecture: i386, flags 0x003d:
HAS_RELOC, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
start address 0x
--8<---

And from an import lib:

--8<---
In archive ../msvc/tests/testsuite.dir/034/.libs/hello.dll.lib:

hello-2.dll: file format pe-i386
architecture: i386, flags 0x003d:
HAS_RELOC, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
start address 0x

hello-2.dll: file format pe-i386
architecture: i386, flags 0x003d:
HAS_RELOC, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
start address 0x

hello-2.dll: file format pe-i386
architecture: i386, flags 0x003d:
HAS_RELOC, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
start address 0x

hello-2.dll: file format pei-i386
architecture: i386, flags 0x0018:
HAS_DEBUG, HAS_SYMS
start address 0x

hello-2.dll: file format pei-i386
architecture: i386, flags 0x0018:
HAS_DEBUG, HAS_SYMS
start address 0x

hello-2.dll: file format pei-i386
architecture: i386, flags 0x0018:
HAS_DEBUG, HAS_SYMS
start address 0x
--8<---

I don't imagine any of the differences to be really useful. I don't
know though... pe-i386 vs. pei-i386 looks promising, but I don't
possess enough PE-COFF-fuu to tell for sure. I think it would
have been used previously if it really did work?

> then file_magic_cmd should not be set to '$OBJDUMP -f' for at least that
> particular combination of MSVC/objdump/mingw that you are using:

I don't think this is particular to my specific objdump, as it
is the one from GNU binutils, and I believe this problem with
func_win32_import_lib_p to be generic to all known objdumps out
there. I don't think this has ever worked as intended.

>> mingw* | pw32*)
>>  # Base MSYS/MinGW do not provide the 'file' command needed by
>>  # func_win32_libid shell function, so use a weaker test based on 'objdump',
>>  # unless we find 'file', for example because we are cross-compiling.
>>  # func_win32_libid assumes BSD nm, so disallow it if using MS dumpbin.
>>  if ( test "$lt_cv_nm_interface" = "BSD nm" && file / ) >/dev/null 2>&1; then
>>lt_cv_deplibs_check_method='file_magic ^x86 archive import|^x86 DLL'
>>lt_cv_file_magic_cmd='func_win32_libid'
>>  else
>># Keep this pattern in sync with the one in func_win32_libid.
>>lt_cv_deplibs_check_method='file_magic file format 
>> (pei*-i386(.*architecture: i386)?|pe-arm-wince|pe-x86-64)'
>>lt_cv_file_magic_cmd='$OBJDUMP -f'
> 
>  lt_cv_file_magic_cmd='func_win32_libid'
> 
> ??

func_win32_libid requires file(1) to be present (wasn't always the
case on MSYS) and that "$NM -f posix -A " is useful (obviously
not the case when NM="dumpbin -symbols").

I suppose one way forward is to flesh out func_win32_libid to also
handle $lt_cv_nm_interface = "MS dumpbin" and then rely on file to
be present. That would make MSVC work on modern but not legacy
MSYS, which does not seem like much of an issue. But that would not
solve matters for wince and old MSYS lacking file(1), and any solution
for those would perhaps be a solution for NM="dumpbin -symbols" as
well, and piggybacking like that is always nice.

Cheers,
Peter


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: func_win32_import_lib_p when file is missing

[Peter Rosin]

On 2012-10-07 14:48, Gary V. Vaughan wrote:
> Hi Peter,
> 
> On Oct 7, 2012, at 4:37 PM, Peter Rosin  wrote:
>> On 2012-10-07 06:04, Gary V. Vaughan wrote:
>>> On 7 Oct 2012, at 06:53, Peter Rosin  wrote:
>>>> objdump doesn't output "import" for me, at least not for any
>>>> import lib I have given it. Chunk?
>>>>
>>>> # func_win32_import_lib_p ARG
>>>> # True if ARG is an import lib, as indicated by $file_magic_cmd
>>>> func_win32_import_lib_p ()
>>>> {
>>>>   $debug_cmd
>>>>
>>>>   case `eval $file_magic_cmd \"\$1\" 2>/dev/null | $SED -e 10q` in
>>>>   *import*) : ;;
>>>>   *) false ;;
>>>>   esac
>>>> }
>>>
>>> Does '$OBJDUMP -f' output anything that can be used to distinguish an
>>> import library?
>>
>> "objdump -f" output from normal static lib:
>> --8<---
>> In archive ../msvc/tests/testsuite.dir/035/.libs/hello.lib:
>>
>> libhello_la-foo.obj: file format pe-i386
>> architecture: i386, flags 0x003d:
>> HAS_RELOC, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
>> start address 0x
>>
>> libhello_la-hello.obj: file format pe-i386
>> architecture: i386, flags 0x003d:
>> HAS_RELOC, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
>> start address 0x
>> --8<---
>>
>> And from an import lib:
>>
>> --8<---
>> In archive ../msvc/tests/testsuite.dir/034/.libs/hello.dll.lib:
>>
>> hello-2.dll: file format pe-i386
>> architecture: i386, flags 0x003d:
>> HAS_RELOC, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
>> start address 0x
>>
>> hello-2.dll: file format pe-i386
>> architecture: i386, flags 0x003d:
>> HAS_RELOC, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
>> start address 0x
>>
>> hello-2.dll: file format pe-i386
>> architecture: i386, flags 0x003d:
>> HAS_RELOC, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
>> start address 0x
>>
>> hello-2.dll: file format pei-i386
>> architecture: i386, flags 0x0018:
>> HAS_DEBUG, HAS_SYMS
>> start address 0x
>>
>> hello-2.dll: file format pei-i386
>> architecture: i386, flags 0x0018:
>> HAS_DEBUG, HAS_SYMS
>> start address 0x
>>
>> hello-2.dll: file format pei-i386
>> architecture: i386, flags 0x0018:
>> HAS_DEBUG, HAS_SYMS
>> start address 0x
>> --8<---
>>
>> I don't imagine any of the differences to be really useful. I don't
>> know though... pe-i386 vs. pei-i386 looks promising, but I don't
>> possess enough PE-COFF-fuu to tell for sure. I think it would
>> have been used previously if it really did work?
> 
> Am I crazy, or isn't it a matter of file naming conventions here?
> 
> If all import libs are named foo.dll.lib, and regular dlls are named foo.dll,
> then it's easy to write a case statement to distinguish the two :)

Alas, that's too naive.  You really have to look *in* the file to know,
and there are many import libraries in the wild that does not have
".dll." in their name. The trouble spot is to tell ordinary static
libraries and import libraries (a special kind of static library)
apart.

> That sounds too simple to be true though, so what about testing for the
> property that the import library has a bunch of references to a dll matching:
> 
>   /^[^:]*\.dll:/
> 
> Where the static library has a bunch of references to object files matching:
> 
>   /^[^:]*\.(o|lo|obj):/
> 
> ??
> 
> Are either of those a step in the right direction?

Unfortunately, that's also too naive. Import libraries on Cygwin/MinGW
does not match that...

Here's output from a Cygwin import library:

-8<-
$ objdump -f tests/testsuite.dir/034/.libs/libhello.dll.a
In archive tests/testsuite.dir/034/.libs/libhello.dll.a:

d04.o: file format pe-i386
architecture: i386, flags 0x0038:
HAS_DEBUG, HAS_SYMS, HAS_LOCALS
start address 0x


d00.o: file format pe-i386
architecture: i386, flags 0x0039:
HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
start address 0x


d03.o: file format pe-i386
architecture: i386, flags 0x0039:
HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
start address 0x


d02.o: file format pe-i386
architecture: i386, flags 0x0039:
HAS_RELOC, HAS_DEBUG, HAS_

Re: [RFC] Moving ltmain.sh and libtool.m4 into Automake

[Peter Rosin]

Hi Gary!

[dropping Automake@, since that part seems to have been shot down]

On 2012-10-17 11:41, Gary V. Vaughan wrote:
> Autotoolers,
> 
> For quite some time now I've been thinking about simplifying Libtool,
> but I'm interested in feedback and more particularly buy-in from
> Automake maintainers before I start the work, so that I have a better
> idea of what direction I'm heading in...
> 
> Libtool is just (a complicated) compiler wrapper, to make building and
> linking against libraries easy to specify... be that on the command
> line with a direct libtool invocation, or from Makefile.am
> specifications.  I'm considering splitting the current libtool project
> in two:
> 
>   1. libltdl as a standalone runtime loader wrapper
>   2. libtool.m4/ltmain.sh to generate the libtool script
> 
> I think (2) belongs better into Automake alongside the other tool
> wrappers it already carries, where it can decide whether to run the
> libtool m4 macros and roll an appropriate compiler wrapper tailored for
> the project using it (no need for all the C++/Java/Fortran goo in a C-
> only project for example).
> 
> Another consideration is that rolling Libtool into Automake would make
> using Libtool as a standalone script rather more difficult.  Having
> said that, my impression is that Libtool is rarely used that way in
> any case, and further simplification may be possible by deliberately
> dropping explicit support for that use case.
> 
> If I make this split and contribute the macros and ltmain.sh to Automake,
> is this something anyone else would like?  If so, do you like it enough
> to wire it into Automake with an appropriate hunk of Perl?
> 
> If the consensus is that Automake is not a good home for the libtool
> compiler wrapper, then I still plan to split Libtool into two projects
> as outlined above to decouple and simplify somewhat -- although I have
> some other things to attend to first, so it will not happen right away,
> but more likely after the next release.
> 
> Thoughts? 

I'm working on some libltdl preloader issues with MSVC, and I must say
that the preloader is rather tightly coupled with libtool, with symbol
lookup table generation for libltdl in the libtool script. Your description
above feels like an attempt to describe the situation in a way that is
a little bit too simplistic. The patches I currently have for the MSVC
issues feels like the kind of stuff you would not want to coordinate
between two packages. So, what's the plan regarding the preloader in the
libltdl/libtool split? Where will e.g. func_generate_dlsyms sit? That
function is clearly an libltdl thing which interacts with libltdl
internals, but I don't see any really good alternative to having that
code inside the libtool script.

Cheers,
Peter


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool 2.4.2 fails to compile on Solaris 10

[Peter Rosin]

Hi Dennis!

On 2012-11-06 04:08, Dennis Clarke wrote:
> 
> Firstly, I am willingto look at a git clone but I would prefer to work with a 
> version that is considered "stable" and "released" and not alpha or beta 
> grade. However, having said that : 
> 
> $ uname -a 
> SunOS node002 5.10 Generic_147440-23 sun4v sparc SUNW,T5240
> $ cc -V
> cc: Sun C 5.12 SunOS_sparc 2011/11/16
> $ psrinfo -pv 
> The physical processor has 64 virtual processors (0-63)
>   UltraSPARC-T2+ (chipid 0, clock 1582 MHz)
> The physical processor has 64 virtual processors (64-127)
>   UltraSPARC-T2+ (chipid 1, clock 1582 MHz)
> 
> 
> $ pwd
> /usr/local/build
> $ ls $SRC/libt*
> /usr/local/src/libtasn1-2.13.tar.gz 
> /usr/local/src/libtool-2.4.2.tar.gz
> /usr/local/src/libtasn1-2.14.tar.gz 
> /usr/local/src/libtool_git_Mon_Nov_05_2012.star.gz
> 
> $ /usr/sfw/bin/openssl dgst -sha1 /usr/local/src/libtool-2.4.2.tar.gz
> SHA1(/usr/local/src/libtool-2.4.2.tar.gz)= 
> 22b71a8b5ce3ad86e1094e7285981cae10e6ff88
> $ /usr/sfw/bin/openssl dgst -md5 /usr/local/src/libtool-2.4.2.tar.gz
> MD5(/usr/local/src/libtool-2.4.2.tar.gz)= d2f3b7d4627e69e13514a40e72a24d50
> 
> 
> $ gzip -dc /usr/local/src/libtool-2.4.2.tar.gz | tar -xf - 
> $ date 
> Tue Nov  6 01:53:02 GMT 2012
> $ mv libtool-2.4.2 libtool-2.4.2_Nov_06_0153_SunOS5.10_sparcv9
> $ cd libtool-2.4.2_Nov_06_0153_SunOS5.10_sparcv9
> 
> $ env | sort  
> AR=/usr/ccs/bin/ar
> AS=/usr/ccs/bin/as
> BUILD=/usr/local/build
> CC=/opt/solarisstudio12.3/bin/cc
> CFLAGS=-errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 
> -xmemalign=8s -xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g 
> -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 
> -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -D_TS_ERRNO 
> -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE
> COLUMNS=124
> CONFIG_SHELL=/bin/bash
> CPPFLAGS=-I/usr/local/include -I/usr/sfw/include
> CXX=/opt/solarisstudio12.3/bin/CC
> CXXFLAGS=-dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 
> -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 
> -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs 
> -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO
> EDITOR=/usr/xpg4/bin/vi
> HOME=/export/home/dclarke
> LANG=C
> LC_ALL=C
> LC_COLLATE=C
> LC_CTYPE=C
> LC_MESSAGES=C
> LC_MONETARY=C
> LC_NUMERIC=C
> LC_TIME=C
> LD=/usr/ccs/bin/ld
> LD_LIBRARY_PATH=/usr/local/lib:/usr/sfw/lib/sparcv9:/opt/mysql/mysql/lib
> LD_OPTIONS=-R/usr/local/lib/$ISALIST:/usr/sfw/lib/$ISALIST:/usr/local/lib:/usr/sfw/lib:/opt/mysql/mysql/lib
>  
> -L/usr/local/lib/$ISALIST:/usr/sfw/lib/$ISALIST:/usr/local/lib:/usr/sfw/lib:/opt/mysql/mysql/lib
> LD_RUN_PATH=/usr/local/lib/$ISALIST:/usr/sfw/lib/$ISALIST:/opt/mysql/mysql/lib
> LINES=44
> LOGNAME=dclarke
> M4=/usr/local/bin/gm4
> MACHTYPE=sparc-sun-solaris
> MAIL=/usr/mail/dclarke
> MANPATH=/usr/local/man:/usr/local/share/man:/usr/share/man:/usr/X11/share/man
> NM=/usr/ccs/bin/nm
> OSTYPE=solaris
> PAGER=/usr/xpg4/bin/more
> PATH=/usr/local/bin:/usr/local/sbin:/usr/xpg6/bin:/usr/xpg4/bin:/usr/ccs/bin:/opt/solarisstudio12.3/bin:/usr/bin:/sbin:/bin:/usr/sbin:/usr/dt/bin:/usr/openwin/bin:/opt/schily/bin:/usr/local/texlive/2012/bin/sparc-solaris
> PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
> PWD=/usr/local/build/libtool-2.4.2_Nov_06_0153_SunOS5.10_sparcv9
> SED=/usr/local/bin/gsed
> SHELL=/bin/ksh
> SRC=/usr/local/src
> TERM=vt100
> TZ=GMT0
> USER=dclarke
> VISUAL=/usr/xpg4/bin/vi
> WINDOW=3
> _=/usr/xpg4/bin/env
> 
> Whic is a bit noisey but works real well with building php and apache etc etc 
> 
> 
> $ ./configure --enable-dependency-tracking --enable-ltdl-install
> ## - ##
> ## Configuring libtool 2.4.2 ##
> ## - ##
> 
> checking for a BSD-compatible install... libltdl/config/install-sh -c
> checking whether build environment is sane... yes
> checking for a thread-safe mkdir -p... libltdl/config/install-sh -c -d
> checking for gawk... no
> checking for mawk... no
> checking for nawk... nawk
> checking whether make sets $(MAKE)... yes
> checking build system type... sparc-sun-solaris2.10
> checking host system type... sparc-sun-solaris2.10
> configure: autobuild project... GNU Libtool
> configure: autobuild revision... 2.4.2 ()
> configure: autobuild hostname... node002
> configure: autobuild mode... default
> configure: autobuild timestamp... 20121106T015422Z
> checking for gcc... /opt/solarisstudio12.3/bin/cc
> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.out
> checking for suffix of executables... 
> checking whether we are cross compiling... no
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... no
> checking whether /opt/solarisstudio12.3/bin/cc accepts -g... yes
> checking for /opt/solarisstudio12.3/bin/cc option to accept ISO C89... none 
> needed
> checking fo

Re: libtool 2.4.2 fails to compile on Solaris 10

[Peter Rosin]

On 2012-11-06 12:45, Peter Rosin wrote:
> The lt_libltdl_LTX_preloaded_symbols symbol is supposed to be in an 
> automatically
> generated file, which isn't generated because configure does not recognize the
> $NM output. Libtool wants BSD style output.
> 
>   
> 
> e.g.
> 0118 T _foobar
> 
> Try to set NM to something that outputs lines as above when given object files
> from your compiler.

Looking at [1], you should try NM="/usr/ccs/bin/nm -p". But I'm not 100%
sure that page is relevant to your case...

> BTW, does config.log provide any hint as to what went wrong in the above
> configure test?

Please also provide the output of "./libtool --config", if the above does
not work.

Cheers,
Peter

[1] http://docs.oracle.com/cd/E23823_01/html/816-5165/nm-1.html


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool 2.4.2 fails to compile on Solaris 10

[Peter Rosin]

On 2012-11-16 21:02, Dennis Clarke wrote:
> So I guess we have progress here .. sort of. 

Good!

> $ pwd
> /usr/local/build/libtool-2.4.2_Nov_06_0153_SunOS5.10_sparcv9
> $ cp -p ./test-suite.log 
> libtool-2.4.2_Nov_06_0153_SunOS5.10_sparcv9_test-suite.log
> 
> see attached testsuite log file. 

If you don't need fortran, just disable it with

F77=no
FC=no

in the environment. Otherwise, you could perhaps try to point them to GNU
fortran. But I know next to nothing about fortran, and it has been a long
time since I used it, so what do I know?

Cheers,
Peter


___
https://lists.gnu.org/mailman/listinfo/libtool

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

[Peter Rosin]

Follow-up Comment #10, sr #108201 (project libtool):

Dropping -no-undefined from LDFLAGS in export.at kills the test
on Windows and it's unacceptable to assume that elfdump
exists. Passing -no-undefined to libtool is NOT a misnomer and
-no-undefined is in fact a perfectly valid libtool option, not a
compiler driver or linker option. On most systems libtool simply
removes -no-undefined, I believe.

I know it was stated that it was a "feeble and first attempt",
but I wanted to spell out that the current form of the patch is
problematic before anyone started thinking that it was ok to
push the changes as is.

Cheers,
Peter


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

[Peter Rosin]

Follow-up Comment #14, sr #108201 (project libtool):

Regarding the -no-undefined issue, I believe it is correct to
set -no-undefined in LDFLAGS in export.at. This is the case
since libtool is used to link in that test, and nothing else.

Or is LDFLAGS special in some way on Solaris, so that it gets
picked up automatically by the compiler driver? That would be
highly surprising since normal Makefile usage of LDFLAGS during
linking would then cause duplicate options to be passed...

If -no-undefined does not work properly on Solaris, that seems
like a platform specific problem that should not be used as an
excuse to clobber export.at for platforms that handles the
option correctly.

As for the patch to add SONAME, I am not qualified to say if
it is good or bad, but it looks sane enough to me. The only
issue I have with that part was that the test for it requires
elfdump to exist (and work) and that the shared library happens
to be named .libs/liba.so, which is not generally true. It also
assumes that there is a shared library at all, which is also
wrong. Not all platforms have something called SONAME. Etc. All
I tried to do was to point out these problems with the patch;
there needs to be a path past the new check in case any of the
above is not as it is on Solaris.

No single "maintainer" possesses knowledge on all platforms
libtool support. The knowledge is spread out and I'm just
speaking from my corner. Punting the issues to some
"export.at maintainer" is not going to work, because there is
none. "We" maintain it.

So, this new check needs to be special cased for Solaris, and
possibly any number or other unnamed systems where it is
appropriate. It should not be a burden to systems and/or
configurations where it simply is an invalid check. You (or
someone) need to find some criteria for when the new check is
sure to be valid, and skip past it otherwise.

SONAME is ELF-specific. Not everything is ELF.

Cheers,
Peter


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

[Peter Rosin]

Follow-up Comment #16, sr #108201 (project libtool):

I had an old git checkout from some time back (with some totally
unrelated work in it) and I used that to run the export test.
I'm not wasting hours on a full testsuite runs for this.
I tested once configuring with CC=g++ and once with CC=gcc. Both
times I then did

make CC=g++ check-local TESTSUITEFLAGS="-d -k export"

and both times the test passed on Cygwin for me.

I'm attaching testsuite.log from one of the runs.


(file #27101)
___

Additional Item Attachment:

File name: testsuite.log  Size:16 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

[Peter Rosin]

Follow-up Comment #18, sr #108201 (project libtool):

I believe gcc 4.5.3 is the latest stable for Cygwin. I do not
trust myself to be able to build a new gcc and verify that it
actually works for Cygwin without investing far more time than I
think is warranted. I imagine that there is some good reason for
Cygwin gcc to remain 4.5.3... And, the gcc version is not likely
to affect if libtool passes -un-undefined on to the toolchain
or if libtool handles the flag correctly.

The libtool I used was git master as of 2012-11-02 (34fe402efa1)
plus a couple of local changes which do not affect things in
any relevant way. Besides, any change will have to be against
master anyway, so you might as well test that first, instead
of asking me to go digging in the history.

However, my prediction is that master and 2.4.2 will behave the
same for you in this regard.

So, all in all, I don't think it is productive for me to test
with different versions.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

[Peter Rosin]

Follow-up Comment #22, sr #108201 (project libtool):

I had a look in the code and it is only for Solaris that
old_archive_cmds and archive_cmds are rigged to include
$LDFLAGS. This is clearly a buggy thing to do and it explains
why -no-undefined is passed down to gcc for you.

However, I have little Solaris expertise and will therefore
leave the resolution of the issue to someone more capable.

All in all, it's the Solaris part/port of libtool that is
buggy, and -no-undefined should stay in LDFLAGS in all those
test cases.

Cheers,
Peter


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

[Peter Rosin]

Follow-up Comment #24, sr #108201 (project libtool):

Hi again!

I have no quarel with the original change to augment
archive_expsym_cmds with ${wl}-h $wl$soname. That looks
like a no-brainer as it just matches archive_cmds. That
can go in at any time, as far as I'm concerned.

The testsuite change still needs work, even with the
change to use objdump. Enumerated list of problems:

1. objdump exists on non-ELF systems also, and is not
required to output a line with "SONAME" in it.
2. The check assumes that the generated library is named
liba.so.
3. The check assumes that a shared library is generated at
all.
4. Even if objdump (or elfdump) is present in $PATH, it
may not be valid to run it on the output from the toolchain
in use. Think cross-compiles. E.g. Cygwin provides elfedit,
but I don't think it has anything to do with the output of
Cygwin gcc/ld, it is provided for working with ELF binaries
generated elsewhere. I wouldn't be all that surprised if
binutils grows elfdump in the future, and that elfdump is
eventually included in Cygwin (or if a clash exists somewhere
else already) with obvious problems.

Regarding the zapping of $LDFLAGS, it is obviously wrong
to have it in there, e.g. it breaks the libtool -no-undefined
option. At the same time I'm weary of zapping it as I can
easily imagine that people have setups that might break if it
is removed. At the same time $LDFLAGS isn't included in
archive_expsym_cmds so it can't be all wrong to zap it from
archive_cmds as well. But your patch might indicate that
archive_expsym_cmds isn't used all that much and receives
little testing?

Again, I'm not qualified to resolve these issues, but my
*guess* is that $LDFLAGS could be removed from archive_cmds
with little or no ill effect. However, removing it from
old_archive_cmds (for the Green Hills C++ Compiler) will
probably cause trouble and I'm unsure of what should be added
to old_archive_cmds instead to make it work properly.

The testsuite change still needs work (as enumerated above),
and holding the real change hostage to the testsuite work
might just be enough the get the remaining kinks hammered
out. >;-)  But then again, maybe we should simply punt
and not test the SONAME at all, given that it seems non-
trivial to know when the check should actually run? Anybody
else with an opinion?

A ChangeLog entry is missing BTW...

Cheers,
Peter


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

[Peter Rosin]

Follow-up Comment #26, sr #108201 (project libtool):

I have pushed the code changes to m4/Libtool.m4 (as two separate
commits), but left the testsuite alone. Thank you for your work
on this!

I also added you to THANKS, I hope that was ok?

A libtool release is not on my table though.

Cheers,
Peter


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: [SCM] GNU Libtool branch, master, updated. v2.4.2-345-ge54f2dc

[Peter Rosin]

On 2013-01-01 19:03, Gary V. Vaughan wrote:
> maint: remove unsupported Tested-by: tag.
> 
> * build-aux/git-log-fix: Tested-by: line should not appear in the
> ChangeLog.
> 
> Signed-off-by: Gary V. Vaughan 

Hi Gary,

I just noticed this, and while I'm perfectly fine with Libtool not
wanting Tested-by: tags, I fail to see how they can be
"unsupported".

So, I'm just curious about what damage it was causing? Is it just
that the git origin of the ChangeLog shows, or something more
tangible?

Cheers,
Peter


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: [SCM] GNU Libtool branch, master, updated. v2.4.2-345-ge54f2dc

[Peter Rosin]

On 2013-01-18 17:32, Peter Rosin wrote:
> On 2013-01-01 19:03, Gary V. Vaughan wrote:
>> maint: remove unsupported Tested-by: tag.
>> 
>> * build-aux/git-log-fix: Tested-by: line should not appear in the
>> ChangeLog.
>> 
>> Signed-off-by: Gary V. Vaughan 
> 
> Hi Gary,
> 
> I just noticed this, and while I'm perfectly fine with Libtool not
> wanting Tested-by: tags, I fail to see how they can be
> "unsupported".
> 
> So, I'm just curious about what damage it was causing? Is it just
> that the git origin of the ChangeLog shows, or something more
> tangible?

Now I see, it breaks the ChangeLog format. There's not supposed to
be any extra garbage below the "* file:" lines. Sleeping does
wonders...

Sorry for the noise.

Cheers,
Peter


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: [PATCH] doc: fix an orthographic error

[Peter Rosin]

On 2013-01-28 14:07, Jan Engelhardt wrote:
> ---
>  doc/libtool.texi |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/doc/libtool.texi b/doc/libtool.texi
> index f7787f6..c06ddaa 100644
> --- a/doc/libtool.texi
> +++ b/doc/libtool.texi
> @@ -1696,7 +1696,7 @@ not
>  libdir='/tmp/usr/local/lib'
>  @end example
>  
> -@code{inst-prefix} is also used to insure that if the installed
> +@code{inst-prefix} is also used to ensure that if the installed
>  object must be relinked upon installation, that it is relinked
>  against the libraries in @var{inst-prefix-dir}/@code{prefix},
>  not @code{prefix}.
> 

Hi Jan,

Thanks for the patch!

I have pushed it with a proper commit message, would you like me to
update your email address in THANKS?

Cheers,
Peter


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: [PATCH] doc: fix an orthographic error

[Peter Rosin]

On 2013-01-28 17:33, Jan Engelhardt wrote:
> On Monday 2013-01-28 17:18, Peter Rosin wrote:
>> On 2013-01-28 14:07, Jan Engelhardt wrote:
>>> @@ -1696,7 +1696,7 @@ not
>>>  libdir='/tmp/usr/local/lib'
>>>  @end example
>>>  
>>> -@code{inst-prefix} is also used to insure that if the installed
>>> +@code{inst-prefix} is also used to ensure that if the installed
>>>  object must be relinked upon installation, that it is relinked
>>>  against the libraries in @var{inst-prefix-dir}/@code{prefix},
>>>  not @code{prefix}.
>>>
>>
>> I have pushed it with a proper commit message, would you like me to
>> update your email address in THANKS?
> 
> Yeah, why not.

Done.

Cheers,
Peter


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: bfd and cygpath

[Peter Rosin]

On 2013-04-23 16:12, NightStrike wrote:
> On Tue, Apr 23, 2013 at 4:02 AM, NightStrike  wrote:
>> Building bfd in a particular cross compiler scenario requires that
>> cygpath be set to "echo".  bfd configury has the tools to do this, but
>> it's broken.  Configure properly does this:
>>
>> # test whether we have cygpath
>> if test -z "$CYGPATH_W"; then
>>   if (cygpath --version) >/dev/null 2>/dev/null; then
>> CYGPATH_W='cygpath -w'
>>   else
>> CYGPATH_W=echo
>>   fi
>> fi
>>
>> But then fails to actually use that variable where it counts:
>>
>>   fix_srcfile_path='`cygpath -w "$srcfile"`'
>>
>> and the subsequent build fails because of this.
>>
>> I see this in the resultant configure, but I don't see how it is
>> getting into the bfd configure.  There is a similar gcc bug here:
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56412
>>
>> If it comes from libtool upstream, can somebody from binutils update
>> the libtool stuff?
> 
> Looks like it went in here:
> 
> http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/configure?rev=1.262&content-type=text/x-cvsweb-markup&cvsroot=src
> 
> Directly from updating libtool.
> 
> I can't find it in upstream libtool, though, so can somebody update
> libtool again?

The only code branch in libtool.m4 that in the past did set the
fix_srcfile_path variable can only be entered if libtool thinks
that GNU ld is not in use.

In libtool.m4, near the start of _LT_LINKER_SHLIBS, we have

  case $host_os in
  cygwin* | mingw* | pw32* | cegcc*)
# FIXME: the MSVC++ port hasn't been tested in a lng time
# When not using gcc, we currently assume that we are using
# Microsoft Visual C++.
if test yes != "$GCC"; then
  with_gnu_ld=no
fi
;;

So, either "$GCC" is not "yes", or with_gnu_ld ends up "no"
somewhere else, otherwise you can't hit the below code branch.

I will go out on a limb here and say that even if you "fix" the
symptom (fix_srcfile_path), you still do NOT want the other
assignments in that code branch and that you will be much
better off examining why you end up there, and fix that instead.
I'm including those assignments here, so that you can see
clearly why...

  *)
# Assume MSVC wrapper
_LT_TAGVAR(hardcode_libdir_flag_spec, $1)=' '
_LT_TAGVAR(allow_undefined_flag, $1)=unsupported
# Tell ltmain to make .lib files, not .a files.
libext=lib
# Tell ltmain to make .dll files, not .so files.
shrext_cmds=.dll
# FIXME: Setting linknames here is a bad hack.
_LT_TAGVAR(archive_cmds, $1)='$CC -o $lib $libobjs $compiler_flags 
`func_echo_all "$deplibs" | $SED '\''s/ -lc$//'\''` -link -dll~linknames='
# The linker will automatically build a .lib file if we build a DLL.
_LT_TAGVAR(old_archive_from_new_cmds, $1)='true'
# FIXME: Should let the user specify the lib program.
_LT_TAGVAR(old_archive_cmds, $1)='lib -OUT:$oldlib$oldobjs$old_deplibs'
-   _LT_TAGVAR(fix_srcfile_path, $1)='`cygpath -w "$srcfile"`'
_LT_TAGVAR(enable_shared_with_static_runtimes, $1)=yes
;;

(the fix_srcfile_path line was removed by commit d243a1ec5, first
released in Libtool 2.4)

Cheers,
Peter


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: bfd and cygpath

[Peter Rosin]

On 2013-04-24 18:29, NightStrike wrote:
> On Wed, Apr 24, 2013 at 12:17 PM, NightStrike  wrote:
>> On Wed, Apr 24, 2013 at 11:55 AM, NightStrike  wrote:
>>> On Wed, Apr 24, 2013 at 2:47 AM, Peter Rosin  wrote:
>>>> On 2013-04-23 16:12, NightStrike wrote:
>>>
>>>>> I can't find it in upstream libtool, though, so can somebody update
>>>>> libtool again?
>>>>
>>>> The only code branch in libtool.m4 that in the past did set the
>>>> fix_srcfile_path variable can only be entered if libtool thinks
>>>> that GNU ld is not in use.
>>>>
>>>> In libtool.m4, near the start of _LT_LINKER_SHLIBS, we have
>>>>
>>>>   case $host_os in
>>>>   cygwin* | mingw* | pw32* | cegcc*)
>>>> # FIXME: the MSVC++ port hasn't been tested in a lng time
>>>> # When not using gcc, we currently assume that we are using
>>>> # Microsoft Visual C++.
>>>> if test yes != "$GCC"; then
>>>>   with_gnu_ld=no
>>>> fi
>>>> ;;
>>>>
>>>> So, either "$GCC" is not "yes", or with_gnu_ld ends up "no"
>>>> somewhere else, otherwise you can't hit the below code branch.
>>>
>>> Thank you for this analysis!  Do you think setting the --with-gnu-ld
>>> configure option will do the trick?  (I'm using gnu ld)
>>>
>>> I'll try it now and see what happens.
>>
>> At first crack, --with-gnu-ld does nothing to change the outcome.
>> We're still trying to use cygpath and getting a cygpath not found
>> error instead of using $(CYGPATH_W), which is still set to echo.
>>
>> Interestingly, with_gnu_ld="no" still appears in the bfd/libtool
>> script.  Does the --with-gnu-ld option not do what I think it does?
> 
> Looks like it gets set right all the way through, until the very end
> when libtool takes over:
> 
> # Whether we are building with GNU ld or not.
> with_gnu_ld=$lt_with_gnu_ld
> 
> Why on earth does it do that?

The way I read it, --with-gnu-ld means that libtool should look for
GNU ld (in $PATH, skipping past any other ld that doesn't pass
muster), it is not meant to force libtool into using some random ld
as if it was GNU ld.

So, it appears that LT_PATH_LD does not like your ld? I'd look into
that. Btw, is $GCC "yes"?

Cheers,
Peter


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: bfd and cygpath

[Peter Rosin]

On 2013-04-24 22:24, NightStrike wrote:
> On Wed, Apr 24, 2013 at 4:16 PM, NightStrike  wrote:
>> On Wed, Apr 24, 2013 at 4:01 PM, Peter Rosin  wrote:
>>> So, it appears that LT_PATH_LD does not like your ld? I'd look into
>>> that.
>>
>> Where is the actual test that runs when that option is set?  I can't find it.

It's in the LT_PATH_LD macro, a loop is broken out of like this:

  case `"$lt_cv_path_LD" -v 2>&1 &5 | tr -d '\015'` ;;
  *)
ac_prog=`($CC -print-prog-name=ld) 2>&5` ;;
  esac

Does your $host match *-*-mingw*?


> I found this:
> configure:5654: checking for ld used by gcc
> configure:5721: result:
> c:/mingw32/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld.exe
> configure:5728: checking if the linker
> (c:/mingw32/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld.exe)
> is GNU ld
> configure:5743: result: no

The above is (partial) output from LT_PATH_LD.

> So here's a problem...   It's getting that linker instead of just
> using $CC because it grabbed the output of gcc -print-prog, which is
> using a windows style path.

Windows style pathnames shouldn't be a problem on MSYS. I assume you are
on MSYS?

It's perhaps time to send the full config.log...

> What I don't understand is why it isn't just using gcc as the linker,
> instead of ld.

It's the way it has been done for a long time, I think originally bugs
(bugs now long gone) caused libtool devs to sidestep the frontend when
linking (instead of fixing upstream). And you are not the first to ask.
I'm sure most would be happy to see this change. I'm also sure some
will be upset by regressions...

Cheers,
Peter


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: bfd and cygpath

[Peter Rosin]

On 2013-04-26 13:58, NightStrike wrote:
> On Wed, Apr 24, 2013 at 8:52 PM, Peter Rosin  wrote:
>> On 2013-04-24 22:24, NightStrike wrote:
>>> On Wed, Apr 24, 2013 at 4:16 PM, NightStrike  wrote:
>>>> On Wed, Apr 24, 2013 at 4:01 PM, Peter Rosin  wrote:
>>>>> So, it appears that LT_PATH_LD does not like your ld? I'd look into
>>>>> that.
>>>>
>>>> Where is the actual test that runs when that option is set?  I can't find 
>>>> it.
>>
>> It's in the LT_PATH_LD macro, a loop is broken out of like this:
>>
>>   case `"$lt_cv_path_LD" -v 2>&1 >   *GNU* | *'with BFD'*)
>> test no != "$with_gnu_ld" && break
>> ;;
>>   *)
>> test yes != "$with_gnu_ld" && break
>> ;;
>>   esac
>>
>> But reading it more carefully, it appears as if $LD is not clobbered if 
>> already
>> set by the user (and if $LD is preset by the user I read it as if 
>> --with-gnu-ld
>> indeed forces libtool to treat $LD is GNU ld). Do you feed a preset $LD to
>> configure? Does anything else in configure set $LD before the expansion of
>> LT_PATH_LD runs?
> 
> I don't explicitly set LD in top level configure, no.  I thought it
> was being set via the output of gcc -print-prog-name=ld, as per my
> last post.  I could be wrong.

I had a look in the binutils src (2.23.51) and its top level configure
has this:

# We must set the default linker to the linker used by gcc for the correct
# operation of libtool.  If LD is not defined and we are using gcc, try to
# set the LD default to the ld used by gcc.
if test -z "$LD"; then
  if test "$GCC" = yes; then
case $build in
*-*-mingw*)
  gcc_prog_ld=`$CC -print-prog-name=ld 2>&1 | tr -d '\015'` ;;
*)
  gcc_prog_ld=`$CC -print-prog-name=ld 2>&1` ;;
esac
case $gcc_prog_ld in
# Accept absolute paths.
[\\/]* | [A-Za-z]:[\\/]*)
  LD="$gcc_prog_ld" ;;
esac
  fi
fi


Notice that it does not canonicalize gcc_prog_ld prior to the assignment
of LD (which is done in the LT_PATH_LD macro). I think this is what
causes LD to have the value it has in the bfd configure. I notice that
you are using a configure cache as well, which might me responsible for
carrying the LD value over to bfd.

But 
c:/mingw32/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld.exe
or c:/mingw32/i686-w64-mingw32/bin/ld.exe
should be mear cosmetics (since you are not playing mount/symlink games).

What do you get if you run:

c:/mingw32/i686-w64-mingw32/bin/ld.exe -v > The reason I ask is because your $LD result
>> 
>> c:/mingw32/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld.exe
>> hasn't been canonicalized. I'd expect it to be
>> c:/mingw32/i686-w64-mingw32/bin/ld.exe
>> but the canonicalized version is only assigned to $LD if $LD isn't set
>> already.
>>
>> BTW, have you played mount games that perhaps fools the naive c14n?
> 
> I don't know what c14n is.  I'm not trying to play mount games, but I
> am running in a hybrid wine environment.

c14n -> canonicalization, like i18n and l10n.

>> Hmm, I also see this:
>>
>>   case $host in
>>   *-*-mingw*)
>> # gcc leaves a trailing carriage return which upsets mingw
>> ac_prog=`($CC -print-prog-name=ld) 2>&5 | tr -d '\015'` ;;
>>   *)
>> ac_prog=`($CC -print-prog-name=ld) 2>&5` ;;
>>   esac
>>
>> Does your $host match *-*-mingw*?
> 
> Yes, build==host==target==i686-w64-mingw32 using 32-bit wine on linux.

Ok.

>>> I found this:
>>> configure:5654: checking for ld used by gcc
>>> configure:5721: result:
>>> c:/mingw32/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld.exe
>>> configure:5728: checking if the linker
>>> (c:/mingw32/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld.exe)
>>> is GNU ld
>>> configure:5743: result: no
>>
>> The above is (partial) output from LT_PATH_LD.
>>
>>> So here's a problem...   It's getting that linker instead of just
>>> using $CC because it grabbed the output of gcc -print-prog, which is
>>> using a windows style path.
>>
>> Windows style pathnames shouldn't be a problem on MSYS. I assume you are
>> on MSYS?
> 
> Nope.  wine.
> 
>> It's perhaps time to send the full config.log...
> 
> Ok, will try setting LD and will send with and without that.

You 

Re: bfd and cygpath

[Peter Rosin]

On 2013-04-26 18:51, NightStrike wrote:
> On Fri, Apr 26, 2013 at 4:06 AM, Peter Rosin  wrote:
>> On 2013-04-26 13:58, NightStrike wrote:
>>> On Wed, Apr 24, 2013 at 8:52 PM, Peter Rosin  wrote:
>>>> On 2013-04-24 22:24, NightStrike wrote:
>>>>> On Wed, Apr 24, 2013 at 4:16 PM, NightStrike  
>>>>> wrote:
>>>>>> On Wed, Apr 24, 2013 at 4:01 PM, Peter Rosin  wrote:
>>>>>>> So, it appears that LT_PATH_LD does not like your ld? I'd look into
>>>>>>> that.
>>>>>>
>>>>>> Where is the actual test that runs when that option is set?  I can't 
>>>>>> find it.
>>>>
>>>> It's in the LT_PATH_LD macro, a loop is broken out of like this:
>>>>
>>>>   case `"$lt_cv_path_LD" -v 2>&1 >>>   *GNU* | *'with BFD'*)
>>>> test no != "$with_gnu_ld" && break
>>>> ;;
>>>>   *)
>>>> test yes != "$with_gnu_ld" && break
>>>> ;;
>>>>   esac
>>>>
>>>> But reading it more carefully, it appears as if $LD is not clobbered if 
>>>> already
>>>> set by the user (and if $LD is preset by the user I read it as if 
>>>> --with-gnu-ld
>>>> indeed forces libtool to treat $LD is GNU ld). Do you feed a preset $LD to
>>>> configure? Does anything else in configure set $LD before the expansion of
>>>> LT_PATH_LD runs?
>>>
>>> I don't explicitly set LD in top level configure, no.  I thought it
>>> was being set via the output of gcc -print-prog-name=ld, as per my
>>> last post.  I could be wrong.
>>
>> I had a look in the binutils src (2.23.51) and its top level configure
>> has this:
>>
>> # We must set the default linker to the linker used by gcc for the correct
>> # operation of libtool.  If LD is not defined and we are using gcc, try to
>> # set the LD default to the ld used by gcc.
>> if test -z "$LD"; then
>>   if test "$GCC" = yes; then
>> case $build in
>> *-*-mingw*)
>>   gcc_prog_ld=`$CC -print-prog-name=ld 2>&1 | tr -d '\015'` ;;
>> *)
>>   gcc_prog_ld=`$CC -print-prog-name=ld 2>&1` ;;
>> esac
>> case $gcc_prog_ld in
>> # Accept absolute paths.
>> [\\/]* | [A-Za-z]:[\\/]*)
>>   LD="$gcc_prog_ld" ;;
>> esac
>>   fi
>> fi
>>
>> Notice that it does not canonicalize gcc_prog_ld prior to the assignment
>> of LD (which is done in the LT_PATH_LD macro). I think this is what
>> causes LD to have the value it has in the bfd configure. I notice that
>> you are using a configure cache as well, which might me responsible for
>> carrying the LD value over to bfd.
> 
> But if I set LD myself in the configure line, then it shouldn't
> exercise this code and should pass the LD over to bfd configure
> unmodified.

Right, that was more a note that cleared up why the LD value wasn't
canonicalized, which confused me at first.

>> But 
>> c:/mingw32/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld.exe
>> or c:/mingw32/i686-w64-mingw32/bin/ld.exe
>> should be mear cosmetics (since you are not playing mount/symlink games).
>>
>> What do you get if you run:
>>
>> c:/mingw32/i686-w64-mingw32/bin/ld.exe -v >
>> (which is what _LT_PATH_LD_GNU runs to determine if you are using GNU ld)
> 
> No such file or directory, which is to be expected.  It's a wine path.
>  Gcc can execute that because gcc is running under wine.  But I can't
> run that directly from a bash shell.

And that is the crux of the matter. No matter what you do, libtool
will still check $LD to see if it is gnu ld. Besides, if libtool
can't execute $LD, things look pretty bleak. So, I guess you will
have to override $LD.

>>>> The reason I ask is because your $LD result
>>>> 
>>>> c:/mingw32/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld.exe
>>>> hasn't been canonicalized. I'd expect it to be
>>>> c:/mingw32/i686-w64-mingw32/bin/ld.exe
>>>> but the canonicalized version is only assigned to $LD if $LD isn't set
>>>> already.
>>>>
>>>> BTW, have you played mount games that perhaps fools the naive c14n?
>>>
>>> I don't know what c14n is.  I'm not trying to play mount 

Re: bfd and cygpath

[Peter Rosin]

On 2013-04-26 23:48, Peter Rosin wrote:
> On 2013-04-26 18:51, NightStrike wrote:
>> On Fri, Apr 26, 2013 at 4:06 AM, Peter Rosin  wrote:
>>> You had LD=i686-w64-mingw32-gcc, which will not make libtool happy. You
>>> might try LD=i686-w64-mingw32-ld instead, but you shouldn't need to
>>> specify LD...
>>
>> I'll try LD=i68...-ld, but libtool should really fix that.
> 
> I humbly disagree. What you are doing is not supported. You are effectively
> "lying" (using the terminology of the libtool manual) to configure (by
> claiming you are on a MinGW host, when in fact you are on a Linux host).
> Compare with the Libtool manual section 15.3.7.6
> 
> http://www.gnu.org/software/libtool/manual/libtool.html#Cygwin-to-MinGW-Cross
> 
> but think Linux/Wine instead of Cygwin as the build. When you have fixed
> this issue, you will probably bump into something else. E.g., I guess you
> should specify:
>  export lt_cv_to_host_file_cmd=func_convert_file_nix_to_w32
>  export lt_cv_to_tool_file_cmd=func_convert_file_nix_to_w32
> 
> Further, will not the dependency tracking output from the MinGW gcc
> generate a bunch of w32 paths that mixes badly with Linux make?
> 
> Are you absolutely sure that you have to "lie" to configure? Why not do
> the decent thing and leave --host unspecified so that config.guess can

Oops, --build, not --host.

> do its thing?
> 
> And if you don't "lie", you might as well use a linux-hosted cross-compiler
> targeting mingw and just rely on wine to run testsuites etc. But even if
> you move from the "lying" case to the "fake" case (i.e. still using the
> mingw-hosted native compiler in wine), chances are that it will work
> better that the "lying" case. But I don't know that, haven't tried...
> 
> The reason the "lying" and "fake" cases work when crossing from Cygwin
> to MinGW is that the true build system (Cygwin) understands w32 based
> paths (most of the time anyway). Your true build system (Linux) does not,
> so you are in uncharted territory.

Cheers,
Peter


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Two-month patch ping: Re: powerpc*le-linux support

[Peter Rosin]

On 2013-08-22 09:40, Gary V. Vaughan wrote:
>> Can we please get this simple patch pushed?
> 
> Done.

To me, it appears as if what you actually pushed was not what was posted?

Cheers,
Peter


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Two-month patch ping: Re: powerpc*le-linux support

[Peter Rosin]

On 2013-08-22 10:20, Gary V. Vaughan wrote:
> Hi Peter,
> 
> On Aug 22, 2013, at 2:54 PM, Peter Rosin  wrote:
> 
>> On 2013-08-22 09:40, Gary V. Vaughan wrote:
>>>> Can we please get this simple patch pushed?
>>>
>>> Done.
>>
>> To me, it appears as if what you actually pushed was not what was posted?
> 
> I am an idiot.  Thanks for the heads up, fixed in the following change set.

Still not right though, sorry.

You ended up doing:

- ppc64-*linux*|powerpc64-*linux*)
+ powerpcle-*)
+   LD="${LD-ld} -m elf32lppclinux"
+   ;;
+ powerpc-*)

but the original wanted:

- ppc64-*linux*|powerpc64-*linux*)
+ powerpc64le-*)
+   LD="${LD-ld} -m elf32lppclinux"
+   ;;
+ powerpc64-*)

But, the originally supplied version confuses me yet again, so I'm not
committing the fix myself...

How can it be correct to say "-m elf32lppclinux" (32-bit) when $host is
explicitly 64-bit? That seems like utter garbage to me. What am I
missing this time?

Cheers,
Peter


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Two-month patch ping: Re: powerpc*le-linux support

[Peter Rosin]

On 2013-08-22 17:48, Alan Modra wrote:
> On Thu, Aug 22, 2013 at 09:34:10PM +0700, Gary V. Vaughan wrote:
>>> How can it be correct to say "-m elf32lppclinux" (32-bit) when $host is
>>> explicitly 64-bit? That seems like utter garbage to me. What am I
>>> missing this time?
> 
> As far as I understand, this piece of libtool is supplying ld options
> when your host compiler defaults to something other than what $host
> implies.  Which sounds very strange, but consider that on a
> powerpc64-linux host your gcc will usually compile to both 32-bit and
> 64-bit objects.  Both 32-bit and 64-bit objects will run on the host,
> and whether gcc produces 32-bit by default (most common a few years
> ago) or 64-bit (most common now), depends on how gcc was configured.
> 
> So if $host is powerpc64-linux and $CC is gcc and gcc produces 64-bit
> by default, and $LD is powerpc64-linux-ld then no ld options are
> needed.  When generating 32-bit libraries on this system, $host is
> powerpc-linux, $CC is still gcc, and $LD may be powerpc-linux-ld.
> That's a problem because $CC with no options produces 64-bit objects
> but $LD with no options is expecting 32-bit.
> 
> This is all somewhat of a guess on my part, but I've seen these $LD
> and $CC selections.  Most configure scripts seem to prefer
> "powerpc64-linux-ld" over plain "ld" when $host is powerpc64-linux,
> and similarly "powerpc-linux-ld" for $host of powerpc-linux.

Sheesh. You are lying about $host, and get to keep all the pieces when
it breaks. If you have host=powerpc64le-*, but the compiler produces
powerpcle-* output, then why on earth didn't you say host=powerpcle-*
from the beginning? And when there is an obvious mismatch between $host
and the compiler output, that seems like a reason to abort to me, and
not a reason to use the obviously wrong value of $host to infer
something about what the compiler produces and spread the lie to ld.

I mean, if the compiler produces powerpcle output and $host matches
powerpc64-*, it is just dead wrong to feed -m elf32ppclinux to ld.
And similar for other three cases of crossing both the 32/64 boundary
and the endian boundary.

Taking one example I know of (I'm sure there are plenty), my Octave will
print this (among other things) when it starts up:

Octave was configured for "i686-pc-cygwin".

I bet this is just a copy of $host. If you lie about $host when you
build software, that lie is going to spread like mad. So, there are
multiple reasons why this model is not sane. The only sane model is
to trust $host.

If you are building for 32le, say host=powerpcle-*
If you are building for 32be, say host=powerpc-*
If you are building for 64le, say host=powerpc64le-*
If you are building for 64be, say host=powerpc64-*

If you then want to avoid the cross-compile mode of autotools (which
is what all this boils down to, methinks), it is probably better to lie
about $build, it is not used nearly as much as $host. 

I realize that it is probably too late for the above. Sad. And I haven't
tried any of it either, so no doubt it's going to fail in some spectacular
way, but it seems much saner to me...

Given all the pain the "avoid cross-compile mode at all costs" mentality
is causing, it would be really nice if autotools could be taught (or told
how) to run run-time checks even in cross-compile mode, whenever that is
possible to do as in cases like this.

Crosses to MinGW from Cygwin or *ix with Wine come to mind as other
examples when people lie about $host/$build to evade the cross-compile
mode.

Cheers,
Peter


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool woes

[Peter Rosin]

On 2013-09-10 00:34, JonY wrote:
> On 9/10/2013 02:12, Ozkan Sezer wrote:
>>
>> *** Warning: linker path does not have real file for library -lole32.
>> *** I have the capability to make that library automatically link in when
>> *** you link to this library.  But I can only do this if you have a
>> *** shared version of the library, which you do not appear to have
>> *** because I did check the linker path looking for a file starting
>> *** with libole32 but no candidates were found. (...for file magic test)
>>
>> *** Warning: linker path does not have real file for library -ldsound.
>> *** I have the capability to make that library automatically link in when
>> *** you link to this library.  But I can only do this if you have a
>> *** shared version of the library, which you do not appear to have
>> *** because I did check the linker path looking for a file starting
>> *** with libdsound but no candidates were found. (...for file magic test)
>>
>> *** Warning: linker path does not have real file for library -lwinmm.
>> *** I have the capability to make that library automatically link in when
>> *** you link to this library.  But I can only do this if you have a
>> *** shared version of the library, which you do not appear to have
>> *** because I did check the linker path looking for a file starting
>> *** with libwinmm but no candidates were found. (...for file magic test)
>> *** The inter-library dependencies that have been dropped here will be
>> *** automatically added whenever a program is linked with this library
>> *** or is declared to -dlopen it.
>>
>> I am stuck with this. Can anyone see what I am doing wrong?
>>
> 
> This needs to be taken up with the libtool developers.
> 
> libtool is technically correct, but libole32.a is a mixed shared lib
> with static data inserted.
> 
> libtool should use dlltool --identify when available.

Just to clarify, sufficiently new libtools (since 2.4) do in fact make
use of dlltool --identify when available, and I do not have any problem
handling -lole32 -ldsound -lwinmm when I try. We need more context to
help.

Wild guess, could it be a missing -L /lib/w32api at play?

Cheers,
Peter


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool woes

[Peter Rosin]

On 2013-09-10 09:08, Ozkan Sezer wrote:
> Tell me if you need anything else.

Let's focus on the libtool 2.4.2.393-5d4a if that's ok with
you.

Can you provide the output from "libtool --config" and
config.log? I'm not set up to easily duplicate your
environment...

Cheers,
Peter


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool woes

[Peter Rosin]

On 2013-09-10 09:47, Ozkan Sezer wrote:
> On 9/10/13, Peter Rosin  wrote:
>> On 2013-09-10 09:08, Ozkan Sezer wrote:
>>> Tell me if you need anything else.
>>
>> Let's focus on the libtool 2.4.2.393-5d4a if that's ok with
>> you.
>>
>> Can you provide the output from "libtool --config" and
>> config.log? I'm not set up to easily duplicate your
>> environment...
>>
>> Cheers,
>> Peter
>>
>>
> 
> Attached ./libtool --config output after configuration. Attached
> config.log.

Your error messages indicate that libtool cannot find any files
matching the various things associated with -lole32 (and other
w32 libraries). I.e. it's not that the any files found are not
considered good enough, it's that libtool doesn't find them
at all. So, the dlltool --identify code path is in all likelihood
perfectly fine, it's just that nothing is being fed to dlltool
in the first place.

So, something seems to be fishy with your library search path.
I notice this in your libtool --config:

# Compile-time system search path for libraries.
sys_lib_search_path_spec="/opt/W64_180676/lib/gcc 
/opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64 "

Do you have any libole32.a (or something such) in any of those
places? If not, where are they? (and why didn't libtool pick
that up when it did $host-gcc --print-search-dirs?)

Cheers,
Peter


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool woes

[Peter Rosin]

On 2013-09-10 10:55, Ozkan Sezer wrote:
> On 9/10/13, Peter Rosin  wrote:
>> On 2013-09-10 09:47, Ozkan Sezer wrote:
>>> On 9/10/13, Peter Rosin  wrote:
>>>> On 2013-09-10 09:08, Ozkan Sezer wrote:
>>>>> Tell me if you need anything else.
>>>>
>>>> Let's focus on the libtool 2.4.2.393-5d4a if that's ok with
>>>> you.
>>>>
>>>> Can you provide the output from "libtool --config" and
>>>> config.log? I'm not set up to easily duplicate your
>>>> environment...
>>>>
>>>> Cheers,
>>>> Peter
>>>>
>>>>
>>>
>>> Attached ./libtool --config output after configuration. Attached
>>> config.log.
>>
>> Your error messages indicate that libtool cannot find any files
>> matching the various things associated with -lole32 (and other
>> w32 libraries). I.e. it's not that the any files found are not
>> considered good enough, it's that libtool doesn't find them
>> at all. So, the dlltool --identify code path is in all likelihood
>> perfectly fine, it's just that nothing is being fed to dlltool
>> in the first place.
>>
>> So, something seems to be fishy with your library search path.
>> I notice this in your libtool --config:
>>
>> # Compile-time system search path for libraries.
>> sys_lib_search_path_spec="/opt/W64_180676/lib/gcc
>> /opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64 "
>>
>> Do you have any libole32.a (or something such) in any of those
>> places? If not, where are they? (and why didn't libtool pick
>> that up when it did $host-gcc --print-search-dirs?)
>>
> 
> You are on the right track, and I think my new msg hasn't arrived yet.

The messages crossed each other, yes. :-)

> See the attached new file libtool--config-1.5.out which is the output
> if I use libtool-1.5, and yes the the important difference is
> sys_lib_search_path_spec. With 2.4.2.393-5d4a, it is:
> sys_lib_search_path_spec="/opt/W64_180676/lib/gcc
> /opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64
> "
> 
> With 1.5, it is:
> sys_lib_search_path_spec="
> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/
> /opt/W64_180676/bin/../lib/gcc/
> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/4.5.4/
> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/../lib64/
> /opt/W64_180676/bin/../../cross_win64/mingw/lib/x86_64-w64-mingw32/4.5.4/
> /opt/W64_180676/bin/../../cross_win64/mingw/lib/../lib64/
> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/
> /opt/W64_180676/bin/../../cross_win64/mingw/lib/"
> 
> The correct path should be /opt/W64_180676/x86_64-w64-mingw32/lib
> i.e. /x86_64-w64-mingw32/lib, but 2.4 is not doing it and
> using /x86_64-w64-mingw32/lib64 instead for reasons
> unfathomable to me. /x86_64-w64-mingw32/lib64 does exist,
> but it only holds gcc's libs, and as a result, the necessary libs
> aren't found.

So, what output do you get from

x86_64-w64-mingw32-gcc --print-search-dirs

I get:

$ x86_64-w64-mingw32-gcc --print-search-dirs
install: /usr/lib/gcc/x86_64-w64-mingw32/4.5.3/
programs: 
=/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/bin/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/bin/
libraries: 
=/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/lib/../lib64/:/usr/x86_64-w64-mingw32/sys-root/mingw/lib/x86_64-w64-mingw32/4.5.3/:/usr/x86_64-w64-mingw32/sys-root/mingw/lib/../lib64/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/lib/:/usr/x86_64-w64-mingw32/sys-root/mingw/lib/


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool woes

[Peter Rosin]

On 2013-09-10 11:26, Ozkan Sezer wrote:
> On 9/10/13, Peter Rosin  wrote:
>> On 2013-09-10 10:55, Ozkan Sezer wrote:
>>> On 9/10/13, Peter Rosin  wrote:
>>>> On 2013-09-10 09:47, Ozkan Sezer wrote:
>>>>> On 9/10/13, Peter Rosin  wrote:
>>>>>> On 2013-09-10 09:08, Ozkan Sezer wrote:
>>>>>>> Tell me if you need anything else.
>>>>>>
>>>>>> Let's focus on the libtool 2.4.2.393-5d4a if that's ok with
>>>>>> you.
>>>>>>
>>>>>> Can you provide the output from "libtool --config" and
>>>>>> config.log? I'm not set up to easily duplicate your
>>>>>> environment...
>>>>>>
>>>>>> Cheers,
>>>>>> Peter
>>>>>>
>>>>>>
>>>>>
>>>>> Attached ./libtool --config output after configuration. Attached
>>>>> config.log.
>>>>
>>>> Your error messages indicate that libtool cannot find any files
>>>> matching the various things associated with -lole32 (and other
>>>> w32 libraries). I.e. it's not that the any files found are not
>>>> considered good enough, it's that libtool doesn't find them
>>>> at all. So, the dlltool --identify code path is in all likelihood
>>>> perfectly fine, it's just that nothing is being fed to dlltool
>>>> in the first place.
>>>>
>>>> So, something seems to be fishy with your library search path.
>>>> I notice this in your libtool --config:
>>>>
>>>> # Compile-time system search path for libraries.
>>>> sys_lib_search_path_spec="/opt/W64_180676/lib/gcc
>>>> /opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64 "
>>>>
>>>> Do you have any libole32.a (or something such) in any of those
>>>> places? If not, where are they? (and why didn't libtool pick
>>>> that up when it did $host-gcc --print-search-dirs?)
>>>>
>>>
>>> You are on the right track, and I think my new msg hasn't arrived yet.
>>
>> The messages crossed each other, yes. :-)
>>
>>> See the attached new file libtool--config-1.5.out which is the output
>>> if I use libtool-1.5, and yes the the important difference is
>>> sys_lib_search_path_spec. With 2.4.2.393-5d4a, it is:
>>> sys_lib_search_path_spec="/opt/W64_180676/lib/gcc
>>> /opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64
>>> "
>>>
>>> With 1.5, it is:
>>> sys_lib_search_path_spec="
>>> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/
>>> /opt/W64_180676/bin/../lib/gcc/
>>> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/4.5.4/
>>> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/../lib64/
>>> /opt/W64_180676/bin/../../cross_win64/mingw/lib/x86_64-w64-mingw32/4.5.4/
>>> /opt/W64_180676/bin/../../cross_win64/mingw/lib/../lib64/
>>> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/
>>> /opt/W64_180676/bin/../../cross_win64/mingw/lib/"
>>>
>>> The correct path should be /opt/W64_180676/x86_64-w64-mingw32/lib
>>> i.e. /x86_64-w64-mingw32/lib, but 2.4 is not doing it and
>>> using /x86_64-w64-mingw32/lib64 instead for reasons
>>> unfathomable to me. /x86_64-w64-mingw32/lib64 does exist,
>>> but it only holds gcc's libs, and as a result, the necessary libs
>>> aren't found.
>>
>> So, what output do you get from
>>
>>  x86_64-w64-mingw32-gcc --print-search-dirs
>>
>> I get:
>>
>> $ x86_64-w64-mingw32-gcc --print-search-dirs
>> install: /usr/lib/gcc/x86_64-w64-mingw32/4.5.3/
>> programs:
>> =/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/bin/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/bin/
>> libraries:
>> =/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/lib/../lib64/:/usr/x86_64-w64-mingw32/sys-root/mi

Re: libtool woes

[Peter Rosin]

On 2013-09-10 11:50, Ozkan Sezer wrote:
> On 9/10/13, Peter Rosin  wrote:
>> On 2013-09-10 11:26, Ozkan Sezer wrote:
>>> On 9/10/13, Peter Rosin  wrote:
>>>> On 2013-09-10 10:55, Ozkan Sezer wrote:
>>>>> On 9/10/13, Peter Rosin  wrote:
>>>>>> On 2013-09-10 09:47, Ozkan Sezer wrote:
>>>>>>> On 9/10/13, Peter Rosin  wrote:
>>>>>>>> On 2013-09-10 09:08, Ozkan Sezer wrote:
>>>>>>>>> Tell me if you need anything else.
>>>>>>>>
>>>>>>>> Let's focus on the libtool 2.4.2.393-5d4a if that's ok with
>>>>>>>> you.
>>>>>>>>
>>>>>>>> Can you provide the output from "libtool --config" and
>>>>>>>> config.log? I'm not set up to easily duplicate your
>>>>>>>> environment...
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Peter
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Attached ./libtool --config output after configuration. Attached
>>>>>>> config.log.
>>>>>>
>>>>>> Your error messages indicate that libtool cannot find any files
>>>>>> matching the various things associated with -lole32 (and other
>>>>>> w32 libraries). I.e. it's not that the any files found are not
>>>>>> considered good enough, it's that libtool doesn't find them
>>>>>> at all. So, the dlltool --identify code path is in all likelihood
>>>>>> perfectly fine, it's just that nothing is being fed to dlltool
>>>>>> in the first place.
>>>>>>
>>>>>> So, something seems to be fishy with your library search path.
>>>>>> I notice this in your libtool --config:
>>>>>>
>>>>>> # Compile-time system search path for libraries.
>>>>>> sys_lib_search_path_spec="/opt/W64_180676/lib/gcc
>>>>>> /opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64
>>>>>> "
>>>>>>
>>>>>> Do you have any libole32.a (or something such) in any of those
>>>>>> places? If not, where are they? (and why didn't libtool pick
>>>>>> that up when it did $host-gcc --print-search-dirs?)
>>>>>>
>>>>>
>>>>> You are on the right track, and I think my new msg hasn't arrived yet.
>>>>
>>>> The messages crossed each other, yes. :-)
>>>>
>>>>> See the attached new file libtool--config-1.5.out which is the output
>>>>> if I use libtool-1.5, and yes the the important difference is
>>>>> sys_lib_search_path_spec. With 2.4.2.393-5d4a, it is:
>>>>> sys_lib_search_path_spec="/opt/W64_180676/lib/gcc
>>>>> /opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64
>>>>> "
>>>>>
>>>>> With 1.5, it is:
>>>>> sys_lib_search_path_spec="
>>>>> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/
>>>>> /opt/W64_180676/bin/../lib/gcc/
>>>>> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/4.5.4/
>>>>> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/../lib64/
>>>>> /opt/W64_180676/bin/../../cross_win64/mingw/lib/x86_64-w64-mingw32/4.5.4/
>>>>> /opt/W64_180676/bin/../../cross_win64/mingw/lib/../lib64/
>>>>> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/
>>>>> /opt/W64_180676/bin/../../cross_win64/mingw/lib/"
>>>>>
>>>>> The correct path should be /opt/W64_180676/x86_64-w64-mingw32/lib
>>>>> i.e. /x86_64-w64-mingw32/lib, but 2.4 is not doing it and
>>>>> using /x86_64-w64-mingw32/lib64 instead for reasons
>>>>> unfathomable to me. /x86_64-w64-mingw32/lib64 does exist,
>>>>> but it only holds gcc's libs, and as a result, the necessary libs
>>>>> aren't found.
>>>>
>>>> So, what output do you get from
>>>>
>>>>x86_64-w64-mingw32-gcc --print-search-dirs
>>>>
>>>> I get:
>>>>
>>>> $ x86_64-w64-mingw32-gcc --print-se

Re: libtool woes

[Peter Rosin]

On 2013-09-10 12:25, Ozkan Sezer wrote:
> On 9/10/13, Ozkan Sezer  wrote:
>> On 9/10/13, Peter Rosin  wrote:
>>> On 2013-09-10 11:26, Ozkan Sezer wrote:
>>>> On 9/10/13, Peter Rosin  wrote:
>>>>> On 2013-09-10 10:55, Ozkan Sezer wrote:
>>>>>> On 9/10/13, Peter Rosin  wrote:
>>>>>>> On 2013-09-10 09:47, Ozkan Sezer wrote:
>>>>>>>> On 9/10/13, Peter Rosin  wrote:
>>>>>>>>> On 2013-09-10 09:08, Ozkan Sezer wrote:
>>>>>>>>>> Tell me if you need anything else.
>>>>>>>>>
>>>>>>>>> Let's focus on the libtool 2.4.2.393-5d4a if that's ok with
>>>>>>>>> you.
>>>>>>>>>
>>>>>>>>> Can you provide the output from "libtool --config" and
>>>>>>>>> config.log? I'm not set up to easily duplicate your
>>>>>>>>> environment...
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Peter
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Attached ./libtool --config output after configuration. Attached
>>>>>>>> config.log.
>>>>>>>
>>>>>>> Your error messages indicate that libtool cannot find any files
>>>>>>> matching the various things associated with -lole32 (and other
>>>>>>> w32 libraries). I.e. it's not that the any files found are not
>>>>>>> considered good enough, it's that libtool doesn't find them
>>>>>>> at all. So, the dlltool --identify code path is in all likelihood
>>>>>>> perfectly fine, it's just that nothing is being fed to dlltool
>>>>>>> in the first place.
>>>>>>>
>>>>>>> So, something seems to be fishy with your library search path.
>>>>>>> I notice this in your libtool --config:
>>>>>>>
>>>>>>> # Compile-time system search path for libraries.
>>>>>>> sys_lib_search_path_spec="/opt/W64_180676/lib/gcc
>>>>>>> /opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64
>>>>>>> "
>>>>>>>
>>>>>>> Do you have any libole32.a (or something such) in any of those
>>>>>>> places? If not, where are they? (and why didn't libtool pick
>>>>>>> that up when it did $host-gcc --print-search-dirs?)
>>>>>>>
>>>>>>
>>>>>> You are on the right track, and I think my new msg hasn't arrived yet.
>>>>>
>>>>> The messages crossed each other, yes. :-)
>>>>>
>>>>>> See the attached new file libtool--config-1.5.out which is the output
>>>>>> if I use libtool-1.5, and yes the the important difference is
>>>>>> sys_lib_search_path_spec. With 2.4.2.393-5d4a, it is:
>>>>>> sys_lib_search_path_spec="/opt/W64_180676/lib/gcc
>>>>>> /opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64
>>>>>> "
>>>>>>
>>>>>> With 1.5, it is:
>>>>>> sys_lib_search_path_spec="
>>>>>> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/
>>>>>> /opt/W64_180676/bin/../lib/gcc/
>>>>>> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/4.5.4/
>>>>>> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/../lib64/
>>>>>> /opt/W64_180676/bin/../../cross_win64/mingw/lib/x86_64-w64-mingw32/4.5.4/
>>>>>> /opt/W64_180676/bin/../../cross_win64/mingw/lib/../lib64/
>>>>>> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/
>>>>>> /opt/W64_180676/bin/../../cross_win64/mingw/lib/"
>>>>>>
>>>>>> The correct path should be /opt/W64_180676/x86_64-w64-mingw32/lib
>>>>>> i.e. /x86_64-w64-mingw32/lib, but 2.4 is not doing it and
>>>>>> using /x86_64-w64-mingw32/lib64 instead for reasons
>>>>>> unfathomable to me. /x86_64-w64-mingw32/lib64 does exist,
>>>>>> but it only holds gcc's libs, 

Re: libtool woes

[Peter Rosin]

On 2013-09-10 12:52, Ozkan Sezer wrote:
> That effectively cripples libtool for cross-compilers. Can the behavior
> be refined instead?  Can you contact Charles Wilson about this?

He should be reading this list, if he has time...

Anyway, does this work?

Cheers,
Peter

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 4418a1c..59953d1 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -2246,23 +2246,38 @@ if test yes = "$GCC"; then
   done
   lt_search_path_spec=`$ECHO "$lt_tmp_lt_search_path_spec" | awk '
 BEGIN {RS = " "; FS = "/|\n";} {
-  lt_foo = "";
-  lt_count = 0;
+  lt_canon_foo = "";
+  lt_canon_count = 0;
+  lt_multi_foo = "";
+  lt_multi_count = 0;
+  lt_multi = 1;
   for (lt_i = NF; lt_i > 0; lt_i--) {
-if ($lt_i != "" && $lt_i != ".") {
+if ($lt_i == ";") {
+  lt_multi = 0;
+  continue;
+}
+if ($lt_i == "" || $lt_i == ".") continue;
+if (!lt_multi) {
   if ($lt_i == "..") {
-lt_count++;
+lt_canon_count++;
+  } else if (lt_canon_count == 0) {
+lt_canon_foo = "/" $lt_i lt_canon_foo;
   } else {
-if (lt_count == 0) {
-  lt_foo = "/" $lt_i lt_foo;
-} else {
-  lt_count--;
-}
+lt_canon_count--;
   }
 }
+if ($lt_i == "..") {
+  lt_multi_count++;
+} else if (lt_multi_count == 0) {
+  lt_multi_foo = "/" $lt_i lt_multi_foo;
+} else {
+  lt_multi_count--;
+}
   }
-  if (lt_foo != "") { lt_freq[[lt_foo]]++; }
-  if (lt_freq[[lt_foo]] == 1) { print lt_foo; }
+  if (lt_canon_foo != "") { lt_canon_freq[lt_canon_foo]++; }
+  if (lt_canon_freq[lt_multi_foo]) { lt_multi_foo = lt_canon_foo; }
+  if (lt_multi_foo != "") { lt_multi_freq[lt_multi_foo]++; }
+  if (lt_multi_freq[lt_multi_foo] == 1) { print lt_multi_foo; }
 }'`
   # AWK program above erroneously prepends '/' to C:/dos/paths
   # for these hosts.


diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 4418a1c..59953d1 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -2246,23 +2246,38 @@ if test yes = "$GCC"; then
   done
   lt_search_path_spec=`$ECHO "$lt_tmp_lt_search_path_spec" | awk '
 BEGIN {RS = " "; FS = "/|\n";} {
-  lt_foo = "";
-  lt_count = 0;
+  lt_canon_foo = "";
+  lt_canon_count = 0;
+  lt_multi_foo = "";
+  lt_multi_count = 0;
+  lt_multi = 1;
   for (lt_i = NF; lt_i > 0; lt_i--) {
-if ($lt_i != "" && $lt_i != ".") {
+if ($lt_i == ";") {
+  lt_multi = 0;
+  continue;
+}
+if ($lt_i == "" || $lt_i == ".") continue;
+if (!lt_multi) {
   if ($lt_i == "..") {
-lt_count++;
+lt_canon_count++;
+  } else if (lt_canon_count == 0) {
+lt_canon_foo = "/" $lt_i lt_canon_foo;
   } else {
-if (lt_count == 0) {
-  lt_foo = "/" $lt_i lt_foo;
-} else {
-  lt_count--;
-}
+lt_canon_count--;
   }
 }
+if ($lt_i == "..") {
+  lt_multi_count++;
+} else if (lt_multi_count == 0) {
+  lt_multi_foo = "/" $lt_i lt_multi_foo;
+} else {
+  lt_multi_count--;
+}
   }
-  if (lt_foo != "") { lt_freq[[lt_foo]]++; }
-  if (lt_freq[[lt_foo]] == 1) { print lt_foo; }
+  if (lt_canon_foo != "") { lt_canon_freq[lt_canon_foo]++; }
+  if (lt_canon_freq[lt_multi_foo]) { lt_multi_foo = lt_canon_foo; }
+  if (lt_multi_foo != "") { lt_multi_freq[lt_multi_foo]++; }
+  if (lt_multi_freq[lt_multi_foo] == 1) { print lt_multi_foo; }
 }'`
   # AWK program above erroneously prepends '/' to C:/dos/paths
   # for these hosts.
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool woes

[Peter Rosin]

On 2013-09-10 15:00, Ozkan Sezer wrote:
> On 9/10/13, Peter Rosin  wrote:
>> On 2013-09-10 12:52, Ozkan Sezer wrote:
>>> That effectively cripples libtool for cross-compilers. Can the behavior
>>> be refined instead?  Can you contact Charles Wilson about this?
>>
>> He should be reading this list, if he has time...
>>
>> Anyway, does this work?
>>
> 
> No, it does not.  With this patch applied, I see
> sys_lib_search_path_spec="/opt/W64_180676/lib/gcc "
> ..  in the libtool --config output.

Crap, I didn't do any final test and managed to exclude a couple
of critical changes, and I did a couple of silly mistakes too. Sorry
about that. Attached is what I should have sent the first time...

> (Note that, this is not a multilib compiler: it targets only win64.)

Even so, I believe that it outputs ../lib64 when you
-print-multi-os-directory, right?

Cheers,
Peter


diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 4418a1c..b0ec76a 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -2238,31 +2238,46 @@ if test yes = "$GCC"; then
   lt_multi_os_dir=`$CC $CPPFLAGS $CFLAGS $LDFLAGS -print-multi-os-directory 2>/dev/null`
   for lt_sys_path in $lt_search_path_spec; do
 if test -d "$lt_sys_path/$lt_multi_os_dir"; then
-  lt_tmp_lt_search_path_spec="$lt_tmp_lt_search_path_spec $lt_sys_path/$lt_multi_os_dir"
+  lt_tmp_lt_search_path_spec="$lt_tmp_lt_search_path_spec $lt_sys_path/;/$lt_multi_os_dir"
 else
   test -d "$lt_sys_path" && \
-	lt_tmp_lt_search_path_spec="$lt_tmp_lt_search_path_spec $lt_sys_path"
+	lt_tmp_lt_search_path_spec="$lt_tmp_lt_search_path_spec $lt_sys_path/;"
 fi
   done
   lt_search_path_spec=`$ECHO "$lt_tmp_lt_search_path_spec" | awk '
 BEGIN {RS = " "; FS = "/|\n";} {
-  lt_foo = "";
-  lt_count = 0;
+  lt_canon_foo = "";
+  lt_canon_count = 0;
+  lt_multi_foo = "";
+  lt_multi_count = 0;
+  lt_multi = 1;
   for (lt_i = NF; lt_i > 0; lt_i--) {
-if ($lt_i != "" && $lt_i != ".") {
+if ($lt_i == ";") {
+  lt_multi = 0;
+  continue;
+}
+if ($lt_i == "" || $lt_i == ".") continue;
+if (!lt_multi) {
   if ($lt_i == "..") {
-lt_count++;
+lt_canon_count++;
+  } else if (lt_canon_count == 0) {
+lt_canon_foo = "/" $lt_i lt_canon_foo;
   } else {
-if (lt_count == 0) {
-  lt_foo = "/" $lt_i lt_foo;
-} else {
-  lt_count--;
-}
+lt_canon_count--;
   }
 }
+if ($lt_i == "..") {
+  lt_multi_count++;
+} else if (lt_multi_count == 0) {
+  lt_multi_foo = "/" $lt_i lt_multi_foo;
+} else {
+  lt_multi_count--;
+}
   }
-  if (lt_foo != "") { lt_freq[[lt_foo]]++; }
-  if (lt_freq[[lt_foo]] == 1) { print lt_foo; }
+  if (lt_canon_foo != "") { lt_canon_freq[[lt_canon_foo]]++; }
+  if (lt_canon_freq[[lt_multi_foo]]) { lt_multi_foo = lt_canon_foo; }
+  if (lt_multi_foo != "") { lt_multi_freq[[lt_multi_foo]]++; }
+  if (lt_multi_freq[[lt_multi_foo]] == 1) { print lt_multi_foo; }
 }'`
   # AWK program above erroneously prepends '/' to C:/dos/paths
   # for these hosts.
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool woes

[Peter Rosin]

On 2013-09-10 15:29, Ozkan Sezer wrote:
> On 9/10/13, Peter Rosin  wrote:
>> On 2013-09-10 15:00, Ozkan Sezer wrote:
>>> On 9/10/13, Peter Rosin  wrote:
>>>> On 2013-09-10 12:52, Ozkan Sezer wrote:
>>>>> That effectively cripples libtool for cross-compilers. Can the behavior
>>>>> be refined instead?  Can you contact Charles Wilson about this?
>>>>
>>>> He should be reading this list, if he has time...
>>>>
>>>> Anyway, does this work?
>>>>
>>>
>>> No, it does not.  With this patch applied, I see
>>> sys_lib_search_path_spec="/opt/W64_180676/lib/gcc "
>>> ..  in the libtool --config output.
>>
>> Crap, I didn't do any final test and managed to exclude a couple
>> of critical changes, and I did a couple of silly mistakes too. Sorry
>> about that. Attached is what I should have sent the first time...
>>
> 
> Thanks, this one makes it to work. ./libtool --config output now has:
> 
> sys_lib_search_path_spec="/opt/W64_180676/lib/gcc
> /opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64
> /opt/W64_180676/x86_64-w64-mingw32/lib /opt/cross_win64/mingw/lib "
> 
> which is suitable.

*snip*

> Is it hard to implement a way of directly respecting --print-search-dirs
> output of the compiler though?

Which is the crux of the matter, isn't it? The thing is, I'm not at all
comfortable with applying this change, and have no clue if it breaks
any existing setup. I mean, to me it seems obvious that if
-print-search-dirs outputs *both* a .../lib64 and a .../lib variant, then
someone really thought the tools should look in both places even if the
-print-multi-os-directory is ../lib64. But at the same time, it is very
likely that this loop in libtool (which is problematic for this case)
solves a real problem somewhere. Since I do not know why the loop is
there in the first place (the natural thing would be to simply trust
-print-search-dirs, just as you say) I'm uneasy to change it.

Peter O'Gorman (explicitly CC:ed) added the loop [1], hopefully he can
fill in some blanks...

Cheers,
Peter

[1] http://lists.gnu.org/archive/html/libtool-patches/2006-10/msg8.html

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool woes

[Peter Rosin]

On 2013-09-10 15:56, Ozkan Sezer wrote:
> OK then, I'll keep an eye on mails from this list.
> 
> (On an irrelevant note, the archive pages at
> http://lists.gnu.org/archive/html/libtool/2013-09/index.html
> http://lists.gnu.org/archive/html/bug-libtool/2013-09/index.html
> doesn't list any mails from me, but the ones from you from this thread
> are there, so I don't know whether any of the mails I send arrive at
> the list..)

That's strange, but you are correct in that all mails I have
received from you have been coming directly too me, and none have
arrived through the list. Maybe they are stuck in moderation, but
I don't know the details of that???

Anyway, I managed to dig up at least some background, see this thread

http://lists.gnu.org/archive/html/bug-libtool/2006-09/msg00019.html

Cheers,
Peter


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool woes

[Peter Rosin]

On 2013-09-10 16:10, Peter Rosin wrote:
> On 2013-09-10 15:56, Ozkan Sezer wrote:
>> OK then, I'll keep an eye on mails from this list.
>>
>> (On an irrelevant note, the archive pages at
>> http://lists.gnu.org/archive/html/libtool/2013-09/index.html
>> http://lists.gnu.org/archive/html/bug-libtool/2013-09/index.html
>> doesn't list any mails from me, but the ones from you from this thread
>> are there, so I don't know whether any of the mails I send arrive at
>> the list..)
> 
> That's strange, but you are correct in that all mails I have
> received from you have been coming directly too me, and none have
> arrived through the list. Maybe they are stuck in moderation, but
> I don't know the details of that???
> 
> Anyway, I managed to dig up at least some background, see this thread
> 
> http://lists.gnu.org/archive/html/bug-libtool/2006-09/msg00019.html

More background [1], [2]:

Alan Modra hints in [1] that -print-search-dirs was fixed in GCC 4.2,
so that it nowadays automatically appends -print-multi-os-directory
for the applicable directories. I.e. it should no longer be necessary
for libtool to append a second ../lib64 when GCC has already done so.
Also, the multi-os appending crap seems to have been added specifically
for early (arguably broken) bi-arch enabled GCCs that printed -m32
directories even though -m64 was the default. So, my conclusion is
that we want any libtool magic to affect -print-search-dirs output from
contemporary GCCs as little as possible, while continuing to append
the -print-multi-os-directory for the legacy case.

The thing to look out for could be if any of the -print-search-dirs
ends with /$lt_multi_os_dir and use that as an indicator that we have
a sufficiently new GCC, and all -print-search-dirs should be left as
is (we should probably continue prune those that don't exist, though).

I have attached a version that implements the above idea. I feel
pretty good about that one actually, but would still like some
feedback from someone more familiar with multilib...

Or should we just ditch support for those early, arguably broken,
bi-arch GCC versions and start trusting -print-search-dirs
unconditionally???

Cheers,
Peter

[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20425
[2] http://gcc.gnu.org/ml/gcc/2006-09/msg00184.html

>From c3b6fb587942478acdb65f8a25725f51e61281f2 Mon Sep 17 00:00:00 2001
From: Peter Rosin 
Date: Wed, 11 Sep 2013 11:56:56 +0200
Subject: [PATCH] libtool: trust -print-search-dirs from recent GCC

Alan Modra hints in [1] that -print-search-dirs was fixed in
GCC 4.2, so that it nowadays automatically appends
-print-multi-os-directory for the applicable directories. I.e.
it should no longer be necessary for libtool to append a second
../lib64 when GCC has already done so. Also, the multi-os
appending loop seems to have been added specifically for early
(arguably broken) bi-arch enabled GCCs that printed -m32
directories even though -m64 was the default [2]. So, my
conclusion is that we want any libtool magic to affect
-print-search-dirs output from contemporary GCCs as little as
possible, while continuing to append the
-print-multi-os-directory for the legacy case.

Fixes bug#15321 reported by Ozkan Sezer.

[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20425
[2] http://lists.gnu.org/archive/html/bug-libtool/2006-09/msg00019.html

* m4/libtool.m4 (_LT_SYS_DYNAMIC_LINKER): If any of the
directories printed by -print-search-dirs ends with the
content of -print-multi-os-directory, then assume that
GCC adds the multi-os-directory where appropriate all by
itself and hence don't try to second guess when to add
it manually.
* THANKS: Update.
---
 THANKS|1 +
 m4/libtool.m4 |   17 -
 2 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/THANKS b/THANKS
index f49e5d9..3c30f61 100644
--- a/THANKS
+++ b/THANKS
@@ -152,6 +152,7 @@
   Nixn...@esperi.org.uk
   Olaf Lenz			ol...@fias.uni-frankfurt.de
   Olly Betts			o...@muscat.co.uk
+  Ozkan Sezer			seze...@gmail.com
   Pádraig Brady			p...@draigbrady.com
   Patrice Fromy			patrice.fr...@u-psud.fr
   Patrick Welche		pr...@newn.cam.ac.uk
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 4418a1c..bdefd85 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -2233,13 +2233,20 @@ if test yes = "$GCC"; then
 ;;
   esac
   # Ok, now we have the path, separated by spaces, we can step through it
-  # and add multilib dir if necessary.
+  # and add multilib dir if necessary...
   lt_tmp_lt_search_path_spec=
-  lt_multi_os_dir=`$CC $CPPFLAGS $CFLAGS $LDFLAGS -print-multi-os-directory 2>/dev/null`
+  lt_multi_os_dir=/`$CC $CPPFLAGS $CFLAGS $LDFLAGS -print-multi-os-directory 2>/dev/null`
+  # ...but if some path already ends with the multilib dir we assume
+  # that all is fine and trust -print-search-dirs as is (GCC 4.2 or newer).
+  case "$lt_mult

Re: libtool woes

[Peter Rosin]

On 2013-09-17 09:50, Ozkan Sezer wrote:
> Any chance that this patch, or a patch that fixes bug #15321 [1],
> gets applied any time?

Yes, I'll push it in a bit. It's been almost a week, and I suspect
that noone will take the time to review this, so I'm just going to
push it shortly without review.

Thanks for your patience.

Cheers,
Peter


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool woes

[Peter Rosin]

On 2013-09-17 10:23, Peter Rosin wrote:
> On 2013-09-17 09:50, Ozkan Sezer wrote:
>> Any chance that this patch, or a patch that fixes bug #15321 [1],
>> gets applied any time?
> 
> Yes, I'll push it in a bit.

Pushed.

Cheers,
Peter


___
https://lists.gnu.org/mailman/listinfo/libtool