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

[Peter Rosin]

Den 2009-09-22 02:15 skrev 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:.

My philosophy has been to convert to MSVC style as late as possible,
and by doing so, keep a common code path with MinGW for as long as
possible. It probably also fits better if one package is built with
libtool/pr-msvc-support and some dependency/dependent package is
build with a cl.exe wrapper such as cccl. But that's a bit of
speculation as I'm not exactly a heavy cccl user...

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

In that case it's because you have more limited goals. The end result
of your approach is that everything is pulled into the MSVC world, and
nobody hasn't even got a remote chance of seamless integration when
using the result with MinGW (or whatever).

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

There is code for that in the pr-msvc-support branch. Have a look
at this patch:
http://savannah.gnu.org/patch/?6446
commit 452faf96f7b06e9eccee01553d95c45080d1cc29

And this one is also related:
http://savannah.gnu.org/patch/?6443
commit 7350644a0a5f5922326cfebe073b1822ae028a9b

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

So, you do feed them the -L option after all. The way you
expressed it previously made me think that support for -LIBPATH:
on the libtool command line was somehow required for configure
to work. AFAICT, the only reason to support -LIBPATH: on the
libtool command line is that you end up with -LIBPATH: in your
dependency_libs variable. Since I do not have that problem in
dependency_libs I don't need to handle -LIBPATH: on the libtool
command line. Instead, if I truly want to send a -LIBPATH:
option to the linker (i.e. if for some reason -L doesn't fit,
but I can't really think of a case for that), I feed the option
the same way as I'd feed any other linker specific option, i.e.
with -Wl,-LIBPATH: That way, libtool need not know anything
about numerous linker options. And the libtool "options
namespace" isn't "polluted" with MSVC specifics either.

Cheers,
Peter