On Fri, Sep 18, 2009 at 11:17 PM, Peter Rosin <p...@lysator.liu.se> wrote: > Den 2009-09-18 14:01 skrev Christopher Hulbert: >> >> On Fri, Sep 18, 2009 at 6:53 AM, Peter Rosin <p...@lysator.liu.se> 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 >