libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Peter Rosin
Subject: Re: pr-msvc-support: building .DLLs with symbols
Date: Sat, 19 Sep 2009 05:17:51 +0200
User-agent: Thunderbird 2.0.0.23 (Windows/20090812)

Den 2009-09-18 14:01 skrev Christopher Hulbert:
On Fri, Sep 18, 2009 at 6:53 AM, Peter Rosin <address@hidden> wrote:
Hi Chris,

Den 2009-09-18 12:16 skrev Christopher Hulbert:
In my windows branch, I use link_search_path_spec as in:

_LT_TAGDECL([], [link_search_path_spec], [1],
   [Flag to add a directory to the linker search path])

Then, somewhere in the "-L*" case of argument processing in
func_mode_link.

       if test -n "$link_search_path_spec"; then
         this_deplib="$link_search_path_spec$dir"
       else
         this_deplib="-L$dir"
       fi

where all cases of the existing "-L$dir" is replaced by
"$this_deplib". Note also that there is an explicit case for
"-LIBPATH:*" so that -LIBPATH can be used in user-defined environment
variables for example. My windows branch seems to work ok for the PGI
and Intel compilers on windows with a couple exceptions:

* running executables (e.g. test programs for the testsuite) that use
DLLs.
* building DLLs with version information.
Are you suggesting that, when given this:

$ .../libtool --mode=link ... -L/foo/bar ...

libtool immediately munges that into an intermediate form:

... -LIBPATH:/foo/bar ...

then, just before linking, moves the -LIBPATH: options to
the LINK envvar:

LINK=" -LIBPATH:c:/some/mount/foo/bar" cl ...

so that link.exe sees them when cl.exe calls link.exe?

Not exactly. In the argument processing of func_mode_link, the deplibs
variable is built up with the dependency libraries. Building that up,
the -L is translated to "$link_search_path_spec", and -LIBPATH is
passed as used.

In libtool.m4 under the cygwin/mingw case of
_LT_LINKER_SHLIBS([TAGNAME]) (when not using GCC), I have a
cc_basename case, and so for the PGI and Intel compilers on these
platforms, I have the commands for building the libraries which
includes "$deplibs" after  a "-link" for the intel compiler because it
follows the MSVC convention. The PGI compilers behave more like Linux
so I don't have to worry about this. My case snippet is below.

*snip snippet*

Ah, you are also adding -link right before all the $deplibs. Didn't
think of that, but I'm not 100% sure if $deplibs can contain anything
that has to be seen by cl.exe? I hope not...

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

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

But I guess I could borrow your variable name and use my
implementation. Ralf, is link_search_path_spec (or perhaps
linker_search_path_spec in order to match linker_envvar) ok
for what dashL_envvar_spec is currently doing?

Cheers,
Peter




reply via email to

[Prev in Thread] Current Thread [Next in Thread]