Config sets optimisation compilation flags (-O/-g)!

bliako has asked for the wisdom of the Perl Monks concerning the following question:

When compiling C embeding Perl scripts one is better to use the compilation flags (CFLAGS/LDFLAGS) and compiler suggested by Config and ExtUtils::Embed (which derives them from former) like so:

perl -MConfig -e 'print $Config{cc}'
perl -MConfig -e 'print $Config{ccflags}'
perl -MExtUtils::Embed -e ccopts -e ldopts
[download]

In my system (Config v5.026002, Perl v5.26.2 + updated linux) I have just noticed that suggested CFLAGS include optimisation flags -g -O2 which void completely any optimisation flags I may want to use. For example I was trying to debug a script embeded in a C program and kept getting:

(gdb) print *ret
value has been optimized out
[download]

Until I realised what was going on and spent another hour trying to remove them using Gnu make's primitive string-substitution options*. I mean, I am not used to tell my computer:

./configure CFLAGS='-g' && make clean && make CFLAGS='-g'
[download]

and still to get optimised-out code in the debugger!

Should this behaviour be filed as a bug with Config and if yes, where does one file bugs for that module?

bw, bliako

*) To cut my losses I finally resorted to gsed rendering my dist completely un-portable. Perl should be better choice.

Update:I will mention that there is an m4 macro which returns Perl's compiled CFLAGS etc. This is in the case when one has a C project which embeds a Perl interpreter and one does not want to use a Perl Makefile.PL but want to use Gnu Autotools. So the macro is AX_PERL_EXT (https://www.gnu.org/software/autoconf-archive/ax_perl_ext.html). When one uses it in a configure.ac file like AX_PERL_EXT(0.0) various variables will be created like PERL_EXT_LDFLAGS which one can use in the various Makefile.am of the project. Based on that macro, other macros can be created to filter out unwanted optimisations inside the Perl oneline, thus avoiding the need to do string substs using Makefile ancient ways. It was a long learning curve so I thought it's worth "polluting" this little corner of the Monastery.

Comment on Config sets optimisation compilation flags (-O/-g)! Select or Download Code

Replies are listed 'Best First'.
Re: Config sets optimisation compilation flags (-O/-g)! by syphilis (Archbishop) on Jan 29, 2019 at 02:55 UTC
Note that %Config can easily be overwritten: `use strict; use warnings; use Config; print "1: $Config{optimize}\n"; my $preferred = tied %Config; $preferred->{optimize} = 'this is what I want'; print "2: $Config{optimize}\n"; __END__ On my Windows 7 box, that outputs: 1: -s -O2 2: this is what I want` [download] Not sure if that is helpful to you but it's a capability that, in the past, has been useful to me. Cheers, Rob	[reply] [d/l]
Re^2: Config sets optimisation compilation flags (-O/-g)! by bliako (Monsignor) on Jan 29, 2019 at 10:21 UTC
I guess your solution (and Fakeconfig from Anonymous) will eliminate the pain to clean the config string in an m4 macro (as I am using Gnu Autotools to generate the Makefile for the project). Of course I do not know what I want, I know what I do not want! I do not want "-O*", so I will filter that out inside the Perl one liner calling Config to tell me the CFLAGS. Thanks for the idea. I have updated my question so as mention an m4 macro which can be used by Autotools to get CFLAGS when compiling C programs having an embeded Perl.	[reply]
Re: Config sets optimisation compilation flags (-O/-g)! by bliako (Monsignor) on Jan 28, 2019 at 18:14 UTC
I have just noticed that CFLAGS suggested by Config also include `-D_FORTIFY_SOURCE=2` which causes the compiler to warn me that because of this it needs `-O`! So the question now is whether I need to use `-D_FORTIFY_SOURCE=2` in compiling my perl-embed C programs or I can safely ignore it, at least when I need to debug. `-D_REENTRANT -D_GNU_SOURCE -O2 -g -pipe -Wall -Werror=format-security +-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param +=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/r +edhat-hardened-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables - +fwrapv -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE +-D_FILE_OFFSET_BITS=64` [download]	[reply] [d/l] [select]
Re: Config sets optimisation compilation flags (-O/-g)! by Anonymous Monk on Jan 28, 2019 at 19:00 UTC
I dont se how you could consider this a bug. Anyway if you want symbols compile/sh configure a debugging version . Otherwise Fakeconfig	[reply]
Re^2: Config sets optimisation compilation flags (-O/-g)! by bliako (Monsignor) on Jan 28, 2019 at 19:29 UTC
OK, I have updated a bit the question via a comment underneath. Basically Config suggests `-Wp,-D_FORTIFY_SOURCE=2` for CFLAGS. Correct me if I am wrong here but it's not its responsibility to tell me what security my C code (embeding Perl) should have. Especially when it breaks debugging. So I was wrong to think that Perl suggests an optimisation flag, instead it suggests a source-fortification (wow) flag which requires the optimisation flag which breaks debug. Isn't it the norm that CFLAGS/LDFLAGS suggestions (via `pkg-config` for example) should never suggest any optimisation for linking to an existing library? That's the user's choice. No? That's why I considered it a bug (and still do). But hey, I am a bit strict sometimes :). Didn't know Fakeconfig, thanks. But this is entirely a C project and I am using Autotools for it. thanks	[reply] [d/l] [select]
Re^3: Config sets optimisation compilation flags (-O/-g)! by BrowserUk (Patriarch) on Jan 28, 2019 at 19:53 UTC
Config simply supplies the same options as was used to build the build of perl you are using; full stop. If you want to override those options you must do so manually; and you must also consider the implications of your code having been built with different options to the build of perl with which it will be interacting at the binary level. Eg. If you want to be able to debug your C code extensions, and turn off optimisations so that the binary code generated matches the source code, then when you run that code under the debugger, your extension's code will match up to its sources; but if you trace the code into the perl binary, its code will not match up to its sources, because it will have been optimised. Whilst it will be possible to debug the extension that way, it would almost certainly be better to build a debug version (ie.no optimisations) of the perl binary, and use that to build and debug your extensions. In that case, your extension will inherit those debug build options by default and you won't need to modify them manually. Once you extension is fully debugged, you can go back to the optimised build of perl, and your extension will be optimised also. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity. In the absence of evidence, opinion is indistinguishable from prejudice. Suck that fhit	[reply]
Re^4: Config sets optimisation compilation flags (-O/-g)! by bliako (Monsignor) on Jan 28, 2019 at 20:23 UTC
Re^3: Config sets optimisation compilation flags (-O/-g)! by dave_the_m (Monsignor) on Jan 28, 2019 at 19:45 UTC
Config basically tells you what flags the perl executable was built with, or more to the point, what flags XS code needs to be compiled with in order to work seamlessly with the perl interpreter. The flags are determined by the arguments to Configure plus whatever probes and/or decisions Configure makes. If you don't like the flags, build a perl with different flags. If you want to debug, build a debugging perl with ./Configure -DDEBUGGING Dave.	[reply]
Re^4: Config sets optimisation compilation flags (-O/-g)! by bliako (Monsignor) on Jan 28, 2019 at 20:14 UTC


Clear questions and runnable code get the best and fastest answer
	PerlMonks