On 9/4/2010 4:52 AM, Peter Rosin wrote:
>
> If you are using -lfoo, then you *must* use 'compile' as well as cl
> does not know about the -l option. So, I was thinking that 'compile'
> instead of just transforming -lfoo into foo.lib would walk the library
> search path (in the same order as cl would) and replace -lfoo with
> either of foo.lib or foo.dll.lib depending on which was found first
> and possibly also modified by any -static or -shared flags (also not
> supported by cl, so -static and -shared would have to be completely
> handled by 'compile' and would only affect -lfoo handling, at least
> in my current thinking).
Remember that -static and -shared, the gcc options, are not antonyms:
`-static'
On systems that support dynamic linking, this prevents linking
with the shared libraries.
`-shared'
Produce a shared object which can then be linked with other
objects to form an executable.
The former deals with what entities you will link to; the latter deals
with what type of output entity you will create.
For our current discussion, you would really only need to implement
-static handling; by default the "search" would prefer foo.dll.lib (but
would accept kernel32.lib). With -static, the "search" would accept
only "foo.lib".
As with cygming, the link phase for -static would never try to verify
that "foo.lib" was actually a static library and not an import lib; it
would have to be a name-based search only (for the reasons you describe
below).
-shared, obviously, would need to be translated into the appropriate
option to tell cl.exe to create a .dll (as opposed to an .exe).
> Note that -shared can't trigger 'compile' to always replace -lfoo with
> foo.dll.lib since a bunch of "system" libraries are shared but still
> named according as foo.lib (as Microsoft is obviously not following
> "my" naming convention). I think other "system" libraries are static
> and also named according to foo.lib, so it would do no good to "prefer"
> the import lib by naming it foo.lib and name the static lib something
> like foo.s.lib.
Right. That's the same conclusion we reached wrt .dll.a vs. .a
>> Agreed.
>
> And the testsuite runs have finished and results are the same. I still
> want to push this.
I have no objections anymore, but I can't approve it.
--
Chuck
