Re^2: Config sets optimisation compilation flags (-O/-g)!

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

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

Replies are listed 'Best First'.
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 (Abbot) on Jan 28, 2019 at 20:23 UTC
OK that's clarified then. Thanks.	[reply]
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 (Abbot) on Jan 28, 2019 at 20:14 UTC
Config basically tells you what flags the perl executable was built with... OK got that. So, FORTIFY_SOURCE was used when building my perl. I am used to `pkg-config` which tells you how to compile and link as opposed to Config which tells you how perl was built. Fine.	[reply] [d/l]