PTHREAD_CFLAGS provided by AX_PTHREAD where best to be attached?

[Dudziak Krzysztof]

Hi,
For makefiles which build piece of software in two separate steps: compilation then linking,
will it be better to attach PTHREAD_CFLAGS to higher-level_CPPFLAGS than to higher-level_CFLAGS variable?
Autotools along with libtool are used here, user-level variables (CFLAGS, CPPFLAGS) are not manipulated through whole build chain.
I can manipulate variables only at Makefile.am -level.

I learned gcc expects -pthread option which translates among others to some preprocessor define,
therefore I wonder if it won't be better to attach PTHREAD_CFLAGS to higher-level_CPPFLAGS rather than
to higher-level_CFLAGS.

Regarding PTHREAD_CFLAGS the AC_PTHREAD manual talks about CFLAGS, not about CPPFLAGS.
I guess attaching to ..._CFLAGS would be fine if building is made in one single step.

Thanks
________________________________
This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.

[Basin Ilya]

Interesting. I'm using AX_PTHREAD and I never thought of that.
Searching web shows that apr-util, though not using autoconf, prints this during configure:

adding "-pthread" to CFLAGS
adding "-D_REENTRANT" to CPPFLAGS

So maybe AX_PTHREAD is doing wrong. Would it harm, if -pthread was added to both variables? Doesn't seem so.

Post by Dudziak Krzysztof
Hi,
For makefiles which build piece of software in two separate steps: compilation then linking,
will it be better to attach PTHREAD_CFLAGS to higher-level_CPPFLAGS than to higher-level_CFLAGS variable?
Autotools along with libtool are used here, user-level variables (CFLAGS, CPPFLAGS) are not manipulated through whole build chain.
I can manipulate variables only at Makefile.am -level.
I learned gcc expects -pthread option which translates among others to some preprocessor define,
therefore I wonder if it won't be better to attach PTHREAD_CFLAGS to higher-level_CPPFLAGS rather than
to higher-level_CFLAGS.
Regarding PTHREAD_CFLAGS the AC_PTHREAD manual talks about CFLAGS, not about CPPFLAGS.
I guess attaching to ..._CFLAGS would be fine if building is made in one single step.
Thanks
________________________________
This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.

[Bob Friesenhahn]

Post by Dudziak Krzysztof
Hi,
For makefiles which build piece of software in two separate steps: compilation then linking,
will it be better to attach PTHREAD_CFLAGS to higher-level_CPPFLAGS than to higher-level_CFLAGS variable?
Autotools along with libtool are used here, user-level variables (CFLAGS, CPPFLAGS) are not manipulated through whole build chain.
I can manipulate variables only at Makefile.am -level.

CPPFLAGS is for the pre-processor while CFLAGS is applied (as well as
CPPFLAGS) while compiling. This means that putting the options in
CFLAGS does work, although it would be better to deduce which options
are for the pre-processor or the compiler and put them in the correct
places.

Post by Dudziak Krzysztof
I learned gcc expects -pthread option which translates among others to some preprocessor define,
therefore I wonder if it won't be better to attach PTHREAD_CFLAGS to higher-level_CPPFLAGS rather than
to higher-level_CFLAGS.

It should not work to put -pthread in CPPFLAGS since it is a
compiler-driver option and not a pre-processor (e.g. /usr/bin/cpp)
option.

Only, -I, -D, and -U type options (see the manual page for 'cpp')
should be put in CPPFLAGS.

Bob

[Dudziak Krzysztof]

Actually question asked initially here does not seem to exist as preprocessing then compilation is one single step. Both ...CFLAGS and ...CPPFLAGS should go to that building stage.
Eventually the order matters, i.e. their's placement in gcc command line string.

Question asked initially might exist if to replace ax_pthread-generated variables with gcc's -pthread option as question's objective.
gcc's manual describes it as gcc process driver's option. Latter one translates it and passes it to preprocessor, compiler and linker flags.
But how to use -pthread in Makefile.am if makefile carries out building in two steps, compilation then linking (with libtool in between
which possibly is irrelevant here)?
I believe automake-generated makefile by default work that way.

krzysiek

-----Original Message-----
From: Bob Friesenhahn [mailto:***@simple.dallas.tx.us]
Sent: Thursday, 12. July 2018 20:28
To: Dudziak Krzysztof <***@gemalto.com>
Cc: ***@gnu.org
Subject: Re: PTHREAD_CFLAGS provided by AX_PTHREAD where best to be attached?

Hi,
compilation then linking, will it be better to attach PTHREAD_CFLAGS to higher-level_CPPFLAGS than to higher-level_CFLAGS variable?
Autotools along with libtool are used here, user-level variables (CFLAGS, CPPFLAGS) are not manipulated through whole build chain.
I can manipulate variables only at Makefile.am -level.

CPPFLAGS is for the pre-processor while CFLAGS is applied (as well as
CPPFLAGS) while compiling. This means that putting the options in CFLAGS does work, although it would be better to deduce which options are for the pre-processor or the compiler and put them in the correct places.

I learned gcc expects -pthread option which translates among others to
some preprocessor define, therefore I wonder if it won't be better to
attach PTHREAD_CFLAGS to higher-level_CPPFLAGS rather than to higher-level_CFLAGS.

It should not work to put -pthread in CPPFLAGS since it is a compiler-driver option and not a pre-processor (e.g. /usr/bin/cpp) option.

Only, -I, -D, and -U type options (see the manual page for 'cpp') should be put in CPPFLAGS.

Bob
--
Bob Friesenhahn
***@simple.dallas.tx.us, https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.simplesystems.org%2Fusers%2Fbfriesen%2F&amp;data=02%7C01%7CKrzysztof.Dudziak%40gemalto.com%7C2cfd69413ad6444ed36708d5e8254424%7C37d0a9db7c464096bfe31add5b495d6d%7C1%7C1%7C636670169138687886&amp;sdata=kqlLph71vuW%2BBZ0PKC5ew2Xb%2FFRRIIzTrCyMuvFU2Sk%3D&amp;reserved=0
GraphicsMagick Maintainer, https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.GraphicsMagick.org%2F&amp;data=02%7C01%7CKrzysztof.Dudziak%40gemalto.com%7C2cfd69413ad6444ed36708d5e8254424%7C37d0a9db7c464096bfe31add5b495d6d%7C1%7C1%7C636670169138687886&amp;sdata=Fii3vstOw5Se1obwRwfN41COxKBnqZrNbpZ2aGl1e2o%3D&amp;reserved=0
________________________________
This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.

[Bob Friesenhahn]

Post by Dudziak Krzysztof
Actually question asked initially here does not seem to exist as preprocessing then compilation is one single step. Both ...CFLAGS and ...CPPFLAGS should go to that building stage.
Eventually the order matters, i.e. their's placement in gcc command line string.
Question asked initially might exist if to replace ax_pthread-generated variables with gcc's -pthread option as question's objective.
gcc's manual describes it as gcc process driver's option. Latter one translates it and passes it to preprocessor, compiler and linker flags.
But how to use -pthread in Makefile.am if makefile carries out building in two steps, compilation then linking (with libtool in between
which possibly is irrelevant here)?
I believe automake-generated makefile by default work that way.

Libtool attempts to use the C compiler when linking, if at all
possible. In this case the C compiler is also supplied with CFLAGS
content. If the C compiler is not used for linking, then libtool
needs to assure that options passed to the linker are compatible with
it, and avoid passing options which might cause it to fail.

Libtool does remember if the -pthread option (or equivalent) was
supplied due to storing this information in the ".la" files it writes.

It is not good to only refer to GCC since there are many other
compilers. For some compilers (e.g. on IBM AIX), a different compiler
program needs to be selected in order to support pthreads.

Bob

Post by Dudziak Krzysztof
krzysiek
-----Original Message-----
Sent: Thursday, 12. July 2018 20:28
Subject: Re: PTHREAD_CFLAGS provided by AX_PTHREAD where best to be attached?

Hi,
compilation then linking, will it be better to attach PTHREAD_CFLAGS to higher-level_CPPFLAGS than to higher-level_CFLAGS variable?
Autotools along with libtool are used here, user-level variables (CFLAGS, CPPFLAGS) are not manipulated through whole build chain.
I can manipulate variables only at Makefile.am -level.

CPPFLAGS is for the pre-processor while CFLAGS is applied (as well as
CPPFLAGS) while compiling. This means that putting the options in CFLAGS does work, although it would be better to deduce which options are for the pre-processor or the compiler and put them in the correct places.

I learned gcc expects -pthread option which translates among others to
some preprocessor define, therefore I wonder if it won't be better to
attach PTHREAD_CFLAGS to higher-level_CPPFLAGS rather than to higher-level_CFLAGS.

It should not work to put -pthread in CPPFLAGS since it is a compiler-driver option and not a pre-processor (e.g. /usr/bin/cpp) option.
Only, -I, -D, and -U type options (see the manual page for 'cpp') should be put in CPPFLAGS.
Bob
--
Bob Friesenhahn
GraphicsMagick Maintainer, https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.GraphicsMagick.org%2F&amp;data=02%7C01%7CKrzysztof.Dudziak%40gemalto.com%7C2cfd69413ad6444ed36708d5e8254424%7C37d0a9db7c464096bfe31add5b495d6d%7C1%7C1%7C636670169138687886&amp;sdata=Fii3vstOw5Se1obwRwfN41COxKBnqZrNbpZ2aGl1e2o%3D&amp;reserved=0
________________________________
This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.