[arch-multilib] Bug with lib32-zlib PKGBUILD
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. Ng Oon-Ee
On 08/28/2010 08:50 AM, 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.
zlib from core has the same workaround but i'm not sure why is there. Pierre any idea why is that? -- Ionuț
Ng Oon-Ee <ngoonee@gmail.com> 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). -- Rémy.
On Sat, 2010-08-28 at 09:38 +0200, Rémy Oudompheng wrote:
Ng Oon-Ee <ngoonee@gmail.com> 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 =)
Ng Oon-Ee <ngoonee@gmail.com> 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.
On Sat, 28 Aug 2010 14:47:35 +0200, Rémy Oudompheng <remyoudompheng@gmail.com> wrote:
Ng Oon-Ee <ngoonee@gmail.com> 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
On Sat, 2010-08-28 at 14:54 +0200, Pierre Schmitz wrote:
On Sat, 28 Aug 2010 14:47:35 +0200, Rémy Oudompheng <remyoudompheng@gmail.com> wrote:
Ng Oon-Ee <ngoonee@gmail.com> 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"
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?
Ng Oon-Ee <ngoonee@gmail.com> 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.
On Sat, 2010-08-28 at 18:09 +0200, Rémy Oudompheng wrote:
Ng Oon-Ee <ngoonee@gmail.com> 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.
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?
Ng Oon-Ee <ngoonee@gmail.com> 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.
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.
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.
participants (5)
-
Ionuț Bîru
-
Ng Oon-Ee
-
Pierre Schmitz
-
Rémy Oudompheng
-
Thomas Bächler