On Mon, Sep 21, 2009 at 2:47 PM, Peter Rosin <p...@lysator.liu.se> 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:. > >>> 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. 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. > > 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. > > Cheers, > Peter > >