libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: linking a shared library with -pthread omits -pthread on the link l


From: Max Bowsher
Subject: Re: linking a shared library with -pthread omits -pthread on the link line.
Date: Sat, 14 Dec 2002 09:21:09 -0000

Bob Friesenhahn <address@hidden> wrote:

> On Fri, 13 Dec 2002, Albert Chin wrote:
>>>
>>> Attached is a patch for libtool, which solves this issue for the
>>> options
>>> -pthread, -pthreads, -threads, -mt, -mthreads and -Kthread.
>>
>> Too much duplicate code. Just use one case statement for it all.
>>
>> BTW, should libtool just pass through options it doesn't recognize?
>
> Libtool does pass through options it doesn't recognize.
> Unfortunately, while unrecognized options are always passed to the
> compiler in the compile step, options do not reliably get passed in
> the link step when the compiler is also used to perform the link.
>
> CVS libtool already passes through any GCC -mfoo options to the
> link step when the compiler is invoked to do the linking.

This seems like a good time to mention a bug I've been experiencing.

I'm trying to use CC="gcc -mno-cygwin" CXX="gcc -mno-cygwin", obviously
expecting that the -mno-cygwin is appended to *every* invocation of gcc.
Now, this works for CXX (The variable CC in the tagged config CXX gets the
value from the environment. In addition, LTCC gets the value of CC from the
environment in every tag. *But* CC in the untagged C config drops
the -mno-cygwin.

I kludged it by doing this to libtool.m4:
@@ -2295,6 +2296,9 @@

 _LT_AC_SYS_COMPILER

+# Allow CC to be a program name with arguments.
+_LT_AC_TAGVAR(compiler, $1)="$CC"
+
 #
 # Check for any special shared library compilation flags.
 #

But that was more by random guess than a through understanding of the
implications of my change.


Thanks,
Max.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]