Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

Configuration cflags compilation of debian

Programming languages, Coding, Executables, Package Creation, and Scripting.
Post Reply
Message
Author
fever_wits
Posts: 6
Joined: 2016-07-23 08:05

Configuration cflags compilation of debian

#1 Post by fever_wits »

Hello,
for my project, I want to optimize some applications and kernel for my processor. In gentoo used CFLAGS. How to do in Debian?
I want to use these parameters:

CHOST="x86_64-pc-linux-gnu"
MAKEOPTS="-j7"
CFLAGS="-march=core2 -O3 -pipe"
CXXFLAGS="${CFLAGS}"

I use a debian 8 and 9.

I apologize for my bad english.

P.S. Please if the post is not for this section, excuse me and say where to move.

day
Posts: 56
Joined: 2015-03-03 00:00

Re: Configuration cflags compilation of debian

#2 Post by day »

dpkg-buildflags

fever_wits
Posts: 6
Joined: 2016-07-23 08:05

Re: Configuration cflags compilation of debian

#3 Post by fever_wits »

Thanks for the reply, but I can not understand the syntax of dpkg-buildflags. I would be very grateful if you detailed information.

User avatar
GarryRicketson
Posts: 5644
Joined: 2015-01-20 22:16
Location: Durango, Mexico

Re: Configuration cflags compilation of debian

#4 Post by GarryRicketson »

Thanks for the reply, but I can not understand the syntax of dpkg-buildflags.
Is there some reason you are not able to at least try to do a search ?

dpkg-buildflags

First hit , of many: https://wiki.debian.org/Hardening

There are many other results, with lots of details.
Second hit: https://wiki.debian.org/HardeningWalkthrough

I apologize for my bad english.
I understand that language might make it a little more difficult,
but that is no excuse for not even trying to do a search , to answer
a question. But actually your English is not bad.

User avatar
stevepusser
Posts: 12930
Joined: 2009-10-06 05:53
Has thanked: 41 times
Been thanked: 71 times

Re: Configuration cflags compilation of debian

#5 Post by stevepusser »

I've read several times that the -O3 flag with the gcc-4.9 compiler in Jessie results in unstable, crash-prone binaries (see the Pale Moon Linux forums, for example) I'm also curious if you can measure any really significant speed increase with the optimizations.

Anyway, I'd advise rebuilding existing packages into proper deb files. Many of those already have customized CFLAGS in the debian/rules files that you can edit, otherwise, you can export those into the package build environment by adding a line like

Code: Select all

export CFLAGS:=-O3
to the rules file to amend the default flags provided by the package build system.

I only backport the Liquorix kernel to a Jessie base--there I edit the zen patch to change it from -O3 to -O2 to avoid the crash problems. The stock Liquorix kernel from their repo has -O3 and should be fine in Stretch. As far as I know, you set the target CPU in the kernel configuration, which you can change by manually edit the configuration file in the /debian folder for the Liquorix kernel for whatever arch you're building for.

It's possible to add a bit of code to the debian/rules file to automatically parallel build on all available CPU cores, but you can also just manually do the same by adding it to the package build command on your machine,

Code: Select all

debuild -uc -us -j7
for example.
MX Linux packager and developer

fever_wits
Posts: 6
Joined: 2016-07-23 08:05

Re: Configuration cflags compilation of debian

#6 Post by fever_wits »

Thanks for the help.

tomazzi
Posts: 730
Joined: 2013-08-02 21:33

Re: Configuration cflags compilation of debian

#7 Post by tomazzi »

fever_wits wrote:Thanks for the help.
IMO it means: "I have completely no idea what the hell you're talking about..."

..because in fact, this is fully readable only for programmers/developers/package maintainers:
stevepusser wrote:I've read several times that the -O3 flag with the gcc-4.9 compiler in Jessie results in unstable, crash-prone binaries (see the Pale Moon Linux forums, for example)
It would take a long time to explain what's the difference between -O3 option for the compiler and the __attribute__(( optimize("O3") )) for some particular function, so just let it go...

Regards.
Odi profanum vulgus

fever_wits
Posts: 6
Joined: 2016-07-23 08:05

Re: Configuration cflags compilation of debian

#8 Post by fever_wits »

I do not want to argue whether I have an idea or I have no idea what I was doing. I received a response. It is somewhat helpful. And I think that is fitting to thank.

tomazzi
Posts: 730
Joined: 2013-08-02 21:33

Re: Configuration cflags compilation of debian

#9 Post by tomazzi »

fever_wits wrote:I do not want to argue whether I have an idea or I have no idea what I was doing. I received a response. It is somewhat helpful. And I think that is fitting to thank.
But of course...

The thing is, that You're fooling yourself, which is unfortunately not so rare case... probably some other people will write such posts in the future -> and therefore it is reasonable to have a reference for quoting...

1. the "O3" option simply can't speed-up the kernel - it can only make it less stable: most of the time the kernel is performing the expensive I/O operations and/or context switching or IRQ handling, what simply can't be optimized-out - this is a plain stupidity to use "O3" for the kernel, since there are far more efficient methods to speed it up, like limiting the IRQ frequency or choosing correct mount options for the file systems.

2. The "O3" option won't speed-up any code which is not written with the "O3" in mind - it'll break such code badly. This is about memory access synchronization/"barriers" - and I strongly suggest that You should read about this before You will even start to think about optimizations on the "O3" level.

3. The "O3" won't make Your project faster (in the overwhelming number of cases) - but most likely it will make Your project less stable -> all the tests which You've made in debug build are irrelevant in the O2/O3 builds - especially in multi-threaded applications - because on this level the compiler is generating a code which it "believes" is "what the programmer could mean", but which is usually totally broken...

Is this clear now? or am I wasting the time?

Regards.
Odi profanum vulgus

Post Reply