* Alexandre Oliva wrote on Thursday, September 08, 2005 22:13 CEST:
> On Aug 23, 2005, Albert Chin <[EMAIL PROTECTED]>
wrote:
>
> >> [2] ltdl.c from HEAD:
> >> 812 if (strncmp(p, "-l", 2) == 0)
> >> 813 {
> >> 814 size_t name_len = 3+ /* "lib" */ LT_STRLEN (p
> >> + 2);
> >> 815 name = MALLOC (char, 1+ name_len);
> >> 816 if (name)
> >> 817 sprintf (name, "lib%s", p+2);
> >> 818 }
>
> >> From inspection, this appears wrong. It doesn't honor
> > $need_lib_prefix.
>
> I don't think it should. need_lib_prefix refers to whether dlopen et
> al support loading libraries that don't start with lib. It's
> unrelated with what the linker (ld, not ld.so) does with `-lname' to
> find the library to link with, which is what ltdl.c is trying to do
> here. Prepending lib unconditionally here is the right thing to do,
> unless the linker actually does something different. I don't know of
> any linker that searches for say foo.a when given -lfoo.
Well, I know of one. Sort of. My MSVC patches emulate the -lfoo option
by substituting -lfoo with foo.lib before calling cl. It also creates
libraries named foo.lib and foo.dll (w/o lib prefix).
The reason is that all libs provided with MSVC are named like that,
and doing it differently turned out to be significantly harder than
to simply use foo.lib. I originally created libraries with lib prefix,
in order to be more compatible with MinGW, but it turned out to be a
mess when trying to use system provided libs.
Example, when you specify -lwsock32 with MinGW/gcc you get to
libwsock32.a and with my MSVC patches you get to WSOCK32.LIB.
Cheers,
Peter
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
