On Tue, Jul 20, 2010 at 11:16:35PM +0200, Pierre Schmitz wrote:

On Tue, 20 Jul 2010 23:00:06 +0200, Thomas Bächler <thomas@archlinux.org> wrote:

...

Am 20.07.2010 22:52, schrieb Firmicus:

...

Yesterday I had bug report on a segfaulting binary for x86_64 that ships with texlive-bin in testing: http://bugs.archlinux.org/task/20199 I have reported the bug upstream: https://sourceforge.net/tracker/?func=detail&aid=3031498&group_id=145640&atid=762580

and as suspected it turned out to be a bug with gcc 4.5: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45008

Now this means I have no means to include a working binary of dvisvgm for x86_64 in texlive-bin until that bug is resolved, since I cannot rely on gcc 4.4.x and no patch is available...

What is the procedure you guys follow is such situations?

Run in circles, scream and shout at people. Then after some time start crying. I have really no idea.

A more practical approach would be to compile the package with gcc 4.4 (there are mirrors containing old packages) and accept that this is an ugly but temporary workaround. You should also open a bug report on our bug tracker and link to the upstream one. Last but not least don't forget to blame Allan. ;-)

A cleaner approach would be to build a gcc44 package, add "export CC=gcc44" in the PKGBUILD and the same for CXX and maybe CPP if used. This approach guarantees that someone using ABS to build packages will not get screwed and gives people supposedly reproducible results. I personally export a lot of variables in makepkg and set their values in "makepkg.conf". I even use a convenience variable "$GVER" which is set now to "45" in my system. It's also a good idea to add the dirname of the correct "libstdc++.so" to "$LIBS". Linking against different "libstdc++" versions is not fun. Using the correct "$GVER" can take care of all that. I'm not sure this will work with the way Arch packages gcc though.