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

[Albert Chin]

On Sat, Dec 14, 2002 at 01:48:39PM -0800, Ossama Othman wrote:
> On Sat, Dec 14, 2002 at 02:50:09PM -0600, Albert Chin wrote:
> > Because it's different! Actually, it works for everything *except* the
> > C tag. The reason is because we do this:
> >   set dummy $CC
> >   compiler=$2
> > 
> > Obviously, if CC="gcc -mno-cygwin", then $2=gcc. The correct solution
> > is:
> >   set dummy "$CC"
> >   compiler=$2
> 
> I'm not against the patch, but shouldn't we educate folks to put
> things like "-mno-cygwin" into the appropriate "FLAGS" variable
> (e.g. CFLAGS) rather than abuse a variable that is meant to only hold
> the compiler name.

I agree. However, this doesn't work in all cases. For example, while
playing around with modifications for hppa64*, I ran into a case where
a program was built with:
  $CC $pic_flag -DPIC [program]
I think it had to do with -dlpreopen (double checking, run
pdemo-make.test in HEAD and you'll see the problem:
  $ cd tests
  $ sh pdemo-make.conf
  ...
  rm -f .libs/helldl.nm .libs/helldl.nmS .libs/helldl.nmT
  creating .libs/helldlS.c
  extracting global C symbols from `./.libs/libhello.a'
  (cd .libs && cc -c "helldlS.c")
  rm -f .libs/helldlS.c .libs/helldl.nm .libs/helldl.nmS
  .libs/helldl.nmT
  cc -mr -Qn -xstrconst -xO2 -xtarget=generic -xarch=v8 -o .libs/helldl
  .libs/helldlS.o longer_file_name_dlmain.o  ./.libs/libhello.so -lm
  -R/opt/build/libtool-1.5/tests/_inst/lib
  creating helldl

Because libtool knows nothing about $CFLAGS, it's not possible for it
to know about the appropriate switch (+DD64 in this case) to build
64-bit object files. Even though the answer was in $CFLAGS, libtool
doesn't get passed $CFLAGS. My solution was CC="cc +DD64".

So, do we teach libtool to inherit $CFLAGS?

-- 
albert chin (address@hidden)