[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [patch #8081] AX_PTHREAD.m4 not setting PTHREAD_LIBS to -pthread for
Daniel Richard G.
Re: [patch #8081] AX_PTHREAD.m4 not setting PTHREAD_LIBS to -pthread for gcc 4.7.2
Wed, 19 Jun 2013 14:49:42 -0400
On Wed, 2013 Jun 19 11:00-0700, Al Pacifico wrote:
> Forgive me if I am incorrect, but when I experimented with this,
> PTHREAD_LIBS seemed not to get set to anything at all by the macro
> compiling my code.
That can be a valid result. If -pthread is needed in both the
compilation and linking steps, then the result should be
because you are supposed to use PTHREAD_CFLAGS in both steps anyway.
Hence the comment
# NOTE: You are assumed to not only compile your program with these flags,
# but also link it with them as well. e.g. you should link with
# $PTHREAD_CC $CFLAGS $PTHREAD_CFLAGS $LDFLAGS ... $PTHREAD_LIBS $LIBS
> The macro documentation says it "sets the PTHREAD_LIBS output variable
> to the threads library and linker flags, and the PTHREAD_CFLAGS output
> variable to any special C compiler flags that are needed."
Compiler flags and linker flags are not mutually-exclusive sets, not
least because linking is typically done via the compiler frontend (cc)
and not by invoking the linker (ld) directly. Any flags that you can use
in the compile step (e.g. -O2, -DFOO, -I/tmp/include) will generally be
accepted in the linking step, even if it's not applicable then. (The
reverse may not be true, e.g. -lfoo.)
Given that, it's a lot less error-prone to use PTHREAD_CFLAGS (and other
CFLAGS variables) when linking, rather than duplicating the applicable
flags into PTHREAD_LIBS/LDFLAGS/etc. variables and not using any CFLAGS
Daniel Richard G. || address@hidden
My ASCII-art .sig got a bad case of Times New Roman.