Re: Windows compilers

[Christopher Hulbert]

On Wed, May 13, 2009 at 2:11 PM, Ralf Wildenhues <address@hidden> wrote:
> Hello Christopher,
>
> * Christopher Hulbert wrote on Wed, May 13, 2009 at 01:14:47PM CEST:
>> 1. What's the future of that branch? Is it ever likely to merge into
>> master to become part of a libtool release and have a larger support
>> base?
>
> Bob addressed this already.
>
>> 2. Based on (1), should I use/modify that branch or make modifications
>> to my own copy of master. I already have a branch modified from master
>> that works well with PGI on Windows.
>
> Well, you can show what you have.  If it overlaps a lot with the branch,
> it would likely be good to base it on that.

It was pretty close to the master before I started adding some stuff
for the Intel compilers. It's still not nearly as different as the
pr-msvc-support branch. Then again, I have not tested it extensively
and I am not intimately familiar with the libtool script, so I am
likely missing some cases. Anyways, the diff and logs are attached.
I've also CC'd the patches list.

>
>> 3. Checking for non-libtool libraries using autoconf (e.g. Intel MKL)
>> requires knowing whether the compiler uses the MSVC or -L/-l format
>> when linking (at least for the few platforms I am working with). Is it
>> possible to develop an LT_TRY_LINK m4 macro that can handle that?
>> Unfortunately I think the libtool program is not created until the end
>> of the configure script. Would a macro like LT_TRY_LINK even be
>> desired by other libtool users? Perhaps it already exists?
>
> You can use LT_OUTPUT which will create the libtool script right then.

Interesting. I'll have to check that out. I was thinking it was done
the same way as AC_CONFIG_FILES. I wonder if you can call AC_OUTPUT
more than once.

>
>> 4. Not being a shell-scripting black-belt and not having a lot of time
>> to spend analyzing the libtool source, the 8000+ line ltmain.m4sh
>> program is extremely difficult to navigate. I have managed relatively
>> small hacks to it, but some sort of flowchart might be really nice for
>> people like myself. Yes, I realize that it takes people time and
>> effort to develop, so don't think I'm just nagging for it. I would be
>> happy to help with it, but again I don't understand enough of libtool
>> to make it happen.
>
> Please describe the things you want to have work or the issues you see
> (both as high level as you can possibly do, as well as as specific as
> you can do, with a command sequence showing failures).

One issue is func_mode_link is gigantic. If I counted right, it's on
the order of 4000+ lines. Trying to find where certain steps occurred
has been a little rough. If there was some sort of flow chart that
showed the steps in there with pointers into the source, that would be
helpful.


Chris

>
> Thanks,
> Ralf
>

hulbert_windows.tar.gz
Description: GNU Zip compressed data