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

[Peter Rosin]

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.

> > 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).

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.

Cheers,
Peter