On Thu, 10 May 2012, Stephan Kulow wrote:

Am 09.05.2012 23:19, schrieb Cristian Rodríguez:

...

when -ansi is used and (defined(_GNU_SOURCE) || (_XOPEN_SOURCE >= 700 || _POSIX_C_SOURCE >= 200809L)) is false, there is no stpcpy prototype and hence no optimization.

Thoughts ?

My usual question would apply: Can you measure the difference? If not, I wouldn't want to waste my energy discussing this.

-ansi is a _very_ popular flag - e.g. all of KDE (3 and 4) uses it.

Using this flag (or what it aliases to - -std=c++98/c90 as opposed to the defaults which are gnu++98/gnu90) makes sense to avoid GCC features creep into a codebase and thus make sure the source will also build using compilers that are not GCC (or implement all of its extensions). Using the flag to produce binaries for a GNU/Linux system makes less sense though. I'm not sure what we should do here, but if we do something we need to handle -std=c90, -std=c99, etc. the same way (thus, recommend the gnu variants). Richard. -- Richard Guenther SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer

El 10/05/12 06:45, Richard Guenther escribió:

On Thu, 10 May 2012, Stephan Kulow wrote:

...

Am 09.05.2012 23:19, schrieb Cristian Rodríguez:

...

when -ansi is used and (defined(_GNU_SOURCE) || (_XOPEN_SOURCE>= 700 || _POSIX_C_SOURCE>= 200809L)) is false, there is no stpcpy prototype and hence no optimization.

Thoughts ?

My usual question would apply: Can you measure the difference? If not, I wouldn't want to waste my energy discussing this.

-ansi is a _very_ popular flag - e.g. all of KDE (3 and 4) uses it.

Using this flag (or what it aliases to - -std=c++98/c90 as opposed to the defaults which are gnu++98/gnu90) makes sense to avoid GCC features creep into a codebase and thus make sure the source will also build using compilers that are not GCC (or implement all of its extensions). Using the flag to produce binaries for a GNU/Linux system makes less sense though.

I'm not sure what we should do here, but if we do something we need to handle -std=c90, -std=c99, etc. the same way (thus, recommend the gnu variants).

Richard.

While ugly, I believe we could use an enviroment variable, SUSE_CC_PREFER_GNU where all this flags are equivalent to -std=gnu99 Packages can then unset that variable in the rare case it causes a problem. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Le jeudi 10 mai 2012, à 05:55 -0400, Dominique Leuenberger a écrit :

before you send all kind of SRs (as you already started): Maybe we can finalize the discussion here and get consensus that this is wishful and helpful?

What do we gain (not hypothetical, but real), what do we risk?

IMHO: diverting from what an upstream provides / proposes in such cases should be well understood and not 'just done'.

And also: why not just do it upstream first and wait for the next upstream tarball? Is this really urgent? Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 10.05.2012 13:32, schrieb Stephan Kulow:

Like Richard said: it makes sense to use it for upstream developers and it's a valid distribution optimization (if it really matters) to remove it.

Then a "--disable-ansi" configure option should be pushed upstream IMVHO. -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Le jeudi 10 mai 2012, à 13:32 +0200, Stephan Kulow a écrit :

Am 10.05.2012 12:02, schrieb Vincent Untz:

...

Le jeudi 10 mai 2012, à 05:55 -0400, Dominique Leuenberger a écrit :

...

before you send all kind of SRs (as you already started): Maybe we can finalize the discussion here and get consensus that this is wishful and helpful?

What do we gain (not hypothetical, but real), what do we risk?

IMHO: diverting from what an upstream provides / proposes in such cases should be well understood and not 'just done'.

And also: why not just do it upstream first and wait for the next upstream tarball? Is this really urgent?

Like Richard said: it makes sense to use it for upstream developers and it's a valid distribution optimization (if it really matters) to remove it.

Sure, but it makes no sense for a distribution to carry a patch forever for this. It just makes our life more difficult in the long term. In general, I'm pretty much against non-upstream patches changing the build system unless there's a really good reason for them. Optimization is not a good enough reason for me: if the optimization matters, it should be of interest to other distros too and so should be upstreamable in some way anyway. Cheers, Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

El 10/05/12 11:53, Vincent Untz escribió:

In general, I'm pretty much against non-upstream patches changing the build system unless there's a really good reason for them. Optimization is not a good enough reason for me: if the optimization matters.

The example optimization I mentioned first in the thread , also catches some extra buffer overflows.. is better security a good enough reason for you ? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 10 May 2012 17:09, Vincent Untz wrote:

Le jeudi 10 mai 2012, à 11:56 -0400, Cristian Rodríguez a écrit :

...

El 10/05/12 11:53, Vincent Untz escribió:

...

In general, I'm pretty much against non-upstream patches changing the build system unless there's a really good reason for them. Optimization is not a good enough reason for me: if the optimization matters.

The example optimization I mentioned first in the thread , also catches some extra buffer overflows.. is better security a good enough reason for you ?

Sounds like something we'd want to share with the world to me. So good reason, but reason to push upstream too :-)

Given Richard Guenther explanation I can't see a good way of upstreaming this. I mean, it's actually already upstreamed! The upstream patch is the -ansi/-std option that projects could use when developing, but that apparently nobody should be adding to the makefiles they release. Additionally gcc is a project with 19 patches already. So while I always try to avoid patches in my packages in this case I don't think a one line patch more or less is going to make any difference. In any case this is for gcc maintainers to decide. So I went forward and created the patch in home:RedDwarf:branches:devel:gcc. Any advice before creating a submit request? Should we run the testsuite with "SUSE_ALWAYS_GNU" defined or not? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, 18 Mar 2013, Cristian Rodr?guez wrote:

El 18/03/13 12:38, Richard Biener escribi?:

...

Yes, the existing rpmlint check. Note that -grecord-gcc-switches is the default starting with GCC 4.8.

Is there any way to make it record the preprocessor defines that were used in the command line?

They are only recorded with -frecord-gcc-switches, not -grecord-gcc-switches. With -grecord-gcc-switches you get <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit) <c> DW_AT_producer : (indirect string, offset: 0x1e): GNU C 4.9.0 20130318 (experimental) -mtune=generic -march=x86-64 -g -frecord-gcc-switches while with -frecord-gcc-switches

readelf -x 4 t.o

Hex dump of section '.GCC.command.line': 0x00000000 2d697072 65666978 202f686f 6d652f61 -iprefix /home/a 0x00000010 6275696c 642f7267 75656e74 6865722f build/rguenther/ 0x00000020 7472756e 6b2d672f 6763632f 2e2e2f6c trunk-g/gcc/../l 0x00000030 69623634 2f676363 2f783836 5f36342d ib64/gcc/x86_64- 0x00000040 756e6b6e 6f776e2d 6c696e75 782d676e unknown-linux-gn 0x00000050 752f342e 382e302f 002d6973 79737465 u/4.8.0/.-isyste 0x00000060 6d202e2f 696e636c 75646500 2d697379 m ./include.-isy 0x00000070 7374656d 202e2f69 6e636c75 64652d66 stem ./include-f 0x00000080 69786564 002d4420 5f464f4f 3d330074 ixed.-D _FOO=3.t 0x00000090 2e63002d 6d74756e 653d6765 6e657269 .c.-mtune=generi 0x000000a0 63002d6d 61726368 3d783836 2d363400 c.-march=x86-64. 0x000000b0 2d67002d 66726563 6f72642d 6763632d -g.-frecord-gcc- 0x000000c0 73776974 63686573 00 switches. I suppose -frecord-gcc-switches output might be easier to replace the existing .comment.SUSE.OPTs section handling in OBS post-processing. Richard. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, 18 Mar 2013, Cristian Rodr?guez wrote:

On 03/18/2013 09:47 AM, Richard Biener wrote:

...

I suggest you arrange for -grecord-gcc-switches to be enabled in RPM_OPT_FLAGS and implement a rpmlint check to search for -std=non-gnu-XXX or -ansi. We can then also drop the suse-record-gcc-opts.diff switch (there is also -frecord-gcc-switches).

That will certainly be helpful, unfortunately it does not fix anything.

Well, if you want to "fix" things then fix them explicitely. By for example appending -std=gnu99 to RPM_OPT_FLAGS. Ok I know that will not work, but consider adding a switch like -fgnu that just switches the dialect flavor (which might even be upstreamable). Richard. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

El 19/03/13 19:10, Cristian Morales Vega escribió:

Can you explain to me why in https://build.opensuse.org/package/rdiff?linkrev=base&package=libebml&project=multimedia%3Alibs&rev=29 you added "-D_GNU_SOURCE" to the CFLAGS? I would have thought it was enough removing the use of "-ansi -fno-gnu-keywords".

In this particular example it does not matter either, the code is compiled with g++ where _GNU_SOURCE is always unconditionally defined anyway. cat test.cpp #define _GNU_SOURCE int main(void) { return 0; } g++ test.cpp g++ test.cpp test.cpp:1:0: warning: "_GNU_SOURCE" redefined [enabled by default] #define _GNU_SOURCE ^ <command-line>:0:0: note: this is the location of the previous definition -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org