Moved from https://bugs.gentoo.org/show_bug.cgi?id=163113 I have a complaint/suggestion about this CFLAGS tweaking that I'm wondering about. Let me know if this was the wrong place to bring this up. I have a server running as a build host for i686 workstations. The server's processor specs are much better than some of the workstations. It's a Core2/Xeon with SSE3 and others. Some of the workstations are Athlon XPs, which only support SSE. Since when it was built it detected some more advanced instructions, it gave me "Illegal Instruction" complaints when run with audacious on the Athlons which didn't have it. GDB pointed back to libmad, and indeed, if I compile libmad locally it seems to work fine, but if I had more than a handful of these it would really be a pain, and it makes me wonder what else does that that I haven't found yet. Mplayer has the cpudetection flag which is handy for this type of scenario. Can we just make the use of the more advanced cpu features USE flag dependent instead of build machine dependent? It seems like that's what the sse, mmx, sse2, 3dnow, etc. flags were for in the first place. That way the user can still define the greatest common denominator. I will see if I can submit an ebuild patch shortly.
Created attachment 134352 [details, diff] A patch to the stable ebuild to disable simultaneous builds.
I did some more testing on this and couldn't see anything obviously wrong in the configure scripts so I tried to do a diff on the output of the compiles on the build server vs. a local host. Some lines weren't lining up in the same places so I thought I'd make my job easier by setting MAKEOPTS="-j1". No difference in the output, so I decided to try running that build on the local machine. Voila! So, here's my patch to disable simultaneous builds.
Hu ? I dont understand anything there: does your build log mentions some extra cpu flags used at compile time that would not work on your old box ? Have you been able to check if this is libmad asm being run where it should not ? (like with gdb you can track where the SIGILL comes from) And more importantly, how does building with -j1 relates to a illegal instruction at runtime ???
(In reply to comment #3) > Hu ? I dont understand anything there: does your build log mentions some extra > cpu flags used at compile time that would not work on your old box ? Have you > been able to check if this is libmad asm being run where it should not ? (like > with gdb you can track where the SIGILL comes from) > > And more importantly, how does building with -j1 relates to a illegal > instruction at runtime ??? I don't know, but at the time it appeared to fix the problem. In any case, I can't reproduce it now, so I think this can be closed. Thanks.
(In reply to comment #4) > I don't know, but at the time it appeared to fix the problem. > > In any case, I can't reproduce it now, so I think this can be closed. Thanks. good ;)
