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

[Christopher Hulbert]

On Fri, Sep 18, 2009 at 11:17 PM, Peter Rosin <address@hidden> wrote:
> 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...

I'm not sure either, but I haven't seen anything that has caused an
issue. Plus, "deplibs" sure sounds like its ONLY dependent libraries
:)!

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

I am not sure what you mean by the identity mounts, could you explain
a little more? 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.

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

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