Re: suspicious linker warning from i686-pc-mingw32-ld

[Dave Korn <dave dot korn dot cygwin at googlemail dot com>]

Rainer Emrich wrote:

> compiling pthreads-w32 gives the following:
> 
> i686-pc-mingw32-gcc -c -o pthread.o -D__CLEANUP_C -O3 -finline-functions
> - -DPTW32_BUILD_INLINED -I. -DHAVE_CONFIG_H -Wall  pthread.c
> i686-pc-mingw32-windres --include-dir=. -D__CLEANUP_C -o version.o version.rc
> i686-pc-mingw32-gcc -D__CLEANUP_C -O3 -finline-functions -DPTW32_BUILD_INLINED
> - -shared -o pthreadGC2.dll pthread.o version.o -lwsock32
> /opt/devel/gnu/cross-gcc/gcc-4.5.0/mingw/i686-pc-mingw32/mingw/bin/i686-pc-mingw32-ld:
> <unknown-file>:0: syntax error
> Warning: .drectve `-export:pthread_rwlock_init.clone.3 ' unrecognized
> /opt/devel/gnu/cross-gcc/gcc-4.5.0/mingw/i686-pc-mingw32/mingw/bin/i686-pc-mingw32-ld:
> <unknown-file>:0: syntax error
> Warning: .drectve `-export:pthread_cond_init.clone.4 ' unrecognized
> /opt/devel/gnu/cross-gcc/gcc-4.5.0/mingw/i686-pc-mingw32/mingw/bin/i686-pc-mingw32-ld:
> <unknown-file>:0: syntax error
> Warning: .drectve `-export:pthread_spin_init.clone.5 ' unrecognized
> /opt/devel/gnu/cross-gcc/gcc-4.5.0/mingw/i686-pc-mingw32/mingw/bin/i686-pc-mingw32-ld:
> <unknown-file>:0: syntax error
> Warning: .drectve `-export:pthread_key_create.clone.2 ' unrecognized
> /opt/devel/gnu/cross-gcc/gcc-4.5.0/mingw/i686-pc-mingw32/mingw/bin/i686-pc-mingw32-ld:
> <unknown-file>:0: syntax error
> Warning: .drectve `-export:pthread_kill.clone.0' unrecognized
> i686-pc-mingw32-dlltool -z pthread.def pthread.o version.o
> i686-pc-mingw32-dlltool -k --dllname pthreadGC2.dll --output-lib libpthreadGC2.a
> - --def pthread.def
> 
> That's with binutils-cvs from 6th of July.
> 
> Any thoughts?

  Argh, I was promised this wasn't going to happen(*).

  Those are cloned functions.  The compiler uses a period as an internal
separator in the function name.  The reason you get a syntax error is because
the .drectve section contains .DEF file commands, and a symbol with a period
in it confuses the DEF file parser, which expects the period to indicate that
the export-forwarding syntax is in use.

  We'll have to take this up back over on the GCC lists.  It might be
necessary to define NO_DOT_IN_LABEL on windows platforms, or perhaps more
likely it's only a bug that is causing these functions to get export
directives and that's what we should address.

    cheers,
      DaveK
-- 
(*) - http://gcc.gnu.org/ml/gcc-patches/2009-06/msg02237.html