Re: pr-msvc-support: building .DLLs with symbols

[Christopher Hulbert]

On Mon, Sep 21, 2009 at 2:47 PM, Peter Rosin <address@hidden> wrote:
> Den 2009-09-21 12:35 skrev Christopher Hulbert:
>>>
>>> Apart from that, your suggestion will "litter" dependency_libs with
>>> -LIBPATH: and it will not work for absolute paths (unless you're
>>> using identity mounts, but that's cheating). That could perhaps be
>>> fixed but I think you will have trouble converting back to a posix
>>> path for dependency_libs in case of -L/absolute/path ->
>>> -LIBPATH:c:/some/mount/absolute/path. There's no api for that in
>>> MSYS (that I know of).
>>
>> I assume you mean the dependency_libs that gets written to the .la
>> file? My dependency_libs in Linux has a number of -L, but I'm not sure
>> if it is my patches. It seems to be in other packages that I have
>> downloaded and built as well, so I suspect that is the normal
>> behavior.
>
> Yes it is normal with a bunch of -L options in dependency_libs. What
> I'm objecting to is that with your version, it will be -LIBPATH:
> instead of -L in dependency_libs. I see that as a problem (see below).
>
>> I am not sure what you mean by the identity mounts, could you explain
>> a little more?
>
> "Identity mount" is where you put the MSYS root in the root of a
> windows drive, so that /absolute/path means the same thing in
> posix-land as in windows-land (given that you have the expected
> current drive, e.g. C:).
>
>> Also, why would you want to convert back to a POSIX
>> path? If the compiler does not understand  posix path, there would be
>> no point that I could see to go back.
>
> I want the .la file to contain -L and the POSIX paths, so that the
> .la file is usable by MSYS/MinGW and looks as much as possible as in
> the MSYS/MinGW case. That way the command line also looks the same
> regardless of if the options came from dependency_libs or from
> somewhere else.

I guess in my case, you would have to convert back (if possible) or
maintain 2 different variables. Neither is probably desired. I don't
mix compilers on Windows, so I guess I have not run into a case where
I want -L after converting to -LIBPATH:.

>
>>> And you still need some way to get FLAG in behind that -link
>>> option in case someone feeds you -Wl,FLAG (which is a much better
>>> way to feed -LIBPATH: options from the outside, compared to having
>>> libtool also recognize -LIBPATH: as an alias for -L IMHO), or you
>>> are stuck with moving options to an envvar (or a command file).
>>
>> I consider myself a libtool "hacker" (not a libtool developer), but it
>> looks like the "-Wl" argument modifies a "linker_flag" variable. Why
>> not just add that, like deplibs, after the -link in the archive_cmds
>> and archive_expsym_cmds that is defined in libtool.m4? Then, it would
>> put those arguments after "-link".
>
> And only do that for MSVC case only, which will force some other variable
> to enable the code path at all, since we don't want to foul up the
> command line for saner cases. But certainly doable, but I fail to see
> the advantage over using the LINK envvar.
>
>> And I would disagree that feeding in the libpath via a bunch of "-Wl"
>> is good. For example, how does an autoconf macro check for a library.
>> Right now with my hacked libtool and a macro I "wrote" that emulates
>> AC_TRY_LINK and AC_LINK_IFELSE using libtool to compile, my autoconf
>> macros that check for libraries can just build up the "-Lpath -la"
>> link information based on a directory passed into the configure
>> argument. Otherwise, I (or another builder of my packages) would have
>> to specify all the -LIBPATH and library files manually. I personally
>> find this much cleaner for building.
>
> You misunderstood me, I meant that
>
> .../libtool ... -Wl,-LIBPATH:C:/foo/bar -lgazonk
>
> is better than
>
> .../libtool ... -LIBPATH:C:/foo/bar -lgazonk
>
> I don't see any reason to support
>
> .../libtool ... -LIBPATH:C:/foo/bar -lgazonk
>
> at all (unless you have -LIBPATH: in dependency_libs of course, but
> that's not "clean" IMHO).

I guess I don't see a reason not to, but maybe we just don't have the
same goals. One issue I am not sure how you address, is that the
linker does not interpret -ljunk as libjunk.lib, junk.lib, etc. I
search the directories in deplibs for the library and translate it
from -l to something the compiler/linker would understand.

>
> And if you have "libtoolized" versions of AC_TRY_LINK and
> AC_LINK_IFELSE (and AC_CHECK_LIB etc) then why not feed them
> -L/some/posix/path? It's not as if cl.exe understands -LIBPATH:
> anyway.

I feed -L and -l to the libtool link command (as if the command
supported it). Libtool translates this to cl.exe ... -link
-libpath:c:/some/path junk.lib, which works perfectly fine. cl.exe
does not support -libpath directly, but does pass flags after -link to
the linker. I like passing linker information to the compiler, because
compilers like the PGI ones can add libraries like the PGI fortran
runtime libraries. link.exe does not know about it unless I tell it.

>
> Cheers,
> Peter
>
>