On Sat, 2010-08-28 at 09:38 +0200, Rémy Oudompheng wrote:

Ng Oon-Ee wrote:

...

Hi all,

Please reference this forum thread - https://bbs.archlinux.org/viewtopic.php?pid=816770 And this submitted bug report - http://bugs.archlinux.org/task/20647

Basically, the PKGBUILD for lib32-zlib has CFLAGS=${CFLAGS/-O2/-O3}, which is meant to remove optimization flags. What it does though is remove the -O2 flag and add an -O3 flag, causing the segfaults I ran across.

Does it work when you build OpenSong from source ? lib32-gzip seems to pass all tests, it might be some sort of binary incompatibility ? It has no problems running in Valgrind.

By the way, could we have in [multilib] the attached valgrind-x86 package or some modification of it ? The default valgrind only support x86_64, I'm not sure whether it's enough to just ship the missing files like I do (a split valgrind package would probably be best).

Not really possible to build from source, it uses RealBasic and I have no idea how to use it, plus its 30-day trial and all that. I'm just thinking there's a reason zlib is supposed to be compiled without optimizations (as shown in the current PKGBUILD), just that the line shown doesn't work as intended =)

On Sat, 28 Aug 2010 14:47:35 +0200, Rémy Oudompheng wrote:

Ng Oon-Ee wrote:

...

I'm just thinking there's a reason zlib is supposed to be compiled without optimizations (as shown in the current PKGBUILD), just that the line shown doesn't work as intended =)

I'd rather think that zlib, had a real benefit from being compiled with -O3, and since it is widely used, maybe preformance was important. The thing is, I don't think people have reported problems with zlib in regular packages, so the most natural thing to do is ship a compatible zlib with OpenSong, unless we prove there is a bug in gcc or zlib.

First of all compiling zlib with the -O3 flag was intended and afaik I did this because it is the upstream default. Debian builds zlib with "-Wall -g -D_REENTRANT -O3" -- Pierre Schmitz, https://users.archlinux.de/~pierre

Ng Oon-Ee wrote:

I've been using OpenSong previously with the old lib32-zlib, which if the PKGBUILD has always been this way also uses -O3. In fact I'm pretty certain if I downloaded our 32-bit zlib package and used it instead, it would work (since that's what the old lib32-zlib package did).

What's the difference then, using gcc-multilib vs actual 32-bit gcc?

32-bit gcc uses -march=x86_64 instead of -march=i686.

Ng Oon-Ee wrote:

On Sat, 2010-08-28 at 18:09 +0200, Rémy Oudompheng wrote:

...

32-bit gcc uses -march=x86_64 instead of -march=i686.

Ah. That's true. Just tried it, compiling with -march=i686 and -O3 works.

So here's the combinations that work for me:- a) -march=x86_64 and no optimization b) -march=i686 and -O3

If both of these can be attributed to the oddities of the OpenSong compiled binary then I'll just leave it at that. Will just have to remember to manually patch lib32=zlib when/if it updates (don't think that's very often honestly).

I wonder about the validity of compiling lib32 packages with -march=i686, should it be done that way? Is it, in other distros?

I would say using -march=(some real 32-bit architecture) for the multilib repo would be better for compatibility with binary packages. Having CFLAGS="-march=x86_64 -m32" doesn't look OK.

On Sun, 2010-08-29 at 02:22 +0200, Thomas Bächler wrote:

Am 28.08.2010 18:38, schrieb Rémy Oudompheng:

...

...

I wonder about the validity of compiling lib32 packages with -march=i686, should it be done that way? Is it, in other distros?

I would say using -march=(some real 32-bit architecture) for the multilib repo would be better for compatibility with binary packages. Having CFLAGS="-march=x86_64 -m32" doesn't look OK.

In lib32 packages, we only want binaries compatible with x86_64 CPUs, so -march=x86-64 is the way to go. This allows the compiler to use more instruction sets and optimizations - for example, all x86_64 CPUs have SSE, while i686 doesn't have it.

If -march=x86-64 breaks zlib, this is likely to be a bug in zlib or the compiler. We could change the -march to something older on a per-package basis as a workaround, but finding the real bug would be better.

Thank you Thomas. I can bring this upstream to whoever does zlib. Before I do, does anyone know of any other app which uses lib32-zlib specifically? Would be good to verify that at least one other app than mine hits the segfault.