FS#14766 - [blender] fails to build

Attached to Project: Arch Linux
Opened by Sven-Hendrik Haase (Svenstaro) - Tuesday, 19 May 2009, 17:48 GMT
Last edited by Allan McRae (Allan) - Monday, 20 July 2009, 06:58 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Tobias Kieslich (tobias)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

Details

Description:

When manually compiling Blender from ABS, the compile will fail like this:

In file included from solver_main.cpp:1094:
paraloopend.h: In member function ‘void LbmFsgrSolver::mainLoop(int)’:
paraloopend.h:25: warning: comparison between signed and unsigned integer expressions
paraloopend.h:26: warning: comparison between signed and unsigned integer expressions
paraloopend.h:27: warning: comparison between signed and unsigned integer expressions
In file included from solver_main.cpp:1134:
paraloopend.h: In member function ‘void LbmFsgrSolver::preinitGrids()’:
paraloopend.h:25: warning: comparison between signed and unsigned integer expressions
paraloopend.h:26: warning: comparison between signed and unsigned integer expressions
paraloopend.h:27: warning: comparison between signed and unsigned integer expressions
In file included from solver_main.cpp:1197:
paraloopend.h: In member function ‘void LbmFsgrSolver::standingFluidPreinit()’:
paraloopend.h:25: warning: comparison between signed and unsigned integer expressions
paraloopend.h:26: warning: comparison between signed and unsigned integer expressions
paraloopend.h:27: warning: comparison between signed and unsigned integer expressions
solver_main.cpp: In member function ‘void LbmFsgrSolver::mainLoop(int)’:
solver_main.cpp:1707: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[3]: *** [/tmp/yaourt-tmp-svenstaro/abs-blender/src/blender-2.48a/obj/linux-glibc2.9-i386/intern/elbeem/debug/solver_main.o] Error 1
make[2]: *** [debug] Error 1
make[1]: *** [all] Error 1
make: *** [all] Error 1
==> ERROR: Build Failed.
Aborting...
Error: Makepkg was unable to build blender package.

I'm using GCC 4.4.0 and my system is fully updated.

I have confirmed this issue for i686 and x86_64 on completely separate machines.

Additional info:
It only started happening recently, as I was able to happily compile Blender before. Did something in the source package change even though it's a stable release?

Steps to reproduce:
1) Update ABS
2) makepkg on Blender's PKGBUILD
3) Watch it explode!
This task depends upon

Closed by  Allan McRae (Allan)
Monday, 20 July 2009, 06:58 GMT
Reason for closing:  Fixed
Additional comments about closing:  blender 2.49a-1
Comment by Jan de Groot (JGC) - Tuesday, 19 May 2009, 18:54 GMT
What are the CFLAGS that it tries to compile that file with? Does it contain -O3?
Comment by Sven-Hendrik Haase (Svenstaro) - Tuesday, 19 May 2009, 18:57 GMT
-march=native -O2 -pipe is all I have.
Native in this case resolves to pentium4 with HT.
Comment by Jan de Groot (JGC) - Tuesday, 19 May 2009, 19:06 GMT
Some packages decide their own CFLAGS, no matter what is in your makepkg.conf. Could you post the full line where it tries to compile the file?
Comment by Sven-Hendrik Haase (Svenstaro) - Tuesday, 19 May 2009, 19:12 GMT
g++ -c -DUSE_SUMO_SOLID -fopenmp -pipe -fPIC -funsigned-char -fno-strict-aliasing -g -Wall -W -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wredundant-decls -Wreorder -Wctor-dtor-privacy -Wnon-virtual-dtor -Woverloaded-virtual -Wsign-promo -Wsynth -DMOZ_NOT_NET -DPARALLEL -DNOGUI -DELBEEM_BLENDER -I. -I../extern -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include -I/usr/include/libpng solver_main.cpp -o /tmp/yaourt-tmp-svenstaro/abs-blender/src/blender-2.48a/obj/linux-glibc2.9-i386/intern/elbeem/debug/solver_main.o

Afterwards, the very error posted above follows.
Comment by Matz Radloff (timesqueezer) - Tuesday, 19 May 2009, 19:17 GMT
I had exactly the same error on my two arch x86_64 systems.

I've build blender direct, with "make"... from the two official mirrors and i tried to build the older version 2.48, too.

But everytime there was the same error.

Maybe it's the new GCC ?

Info: My Systems are both up to date.
Comment by Thomas Dziedzic (tomd123) - Tuesday, 19 May 2009, 20:30 GMT
I have had gcc segfault on me before like this.
The way I fixed it, was "pacman -R gcc; pacman -S gcc" (reinstall gcc).
It turned out after about an hour of investigating, that the gcc package was borked :D
Comment by Thomas Dziedzic (tomd123) - Tuesday, 19 May 2009, 20:33 GMT
oh, the specific series of sequences I followed were "pacman -R gcc; pacman -Scc; pacman -S gcc"
the Scc is to clear the pkg cache (don't want to use the borked package again :D)
Comment by Greg (dolby) - Tuesday, 19 May 2009, 20:51 GMT
What do you mean borked? And why didnt you mae a bug report if you found something wrong with it?
Comment by Thomas Dziedzic (tomd123) - Wednesday, 20 May 2009, 01:18 GMT
What do you mean borked?
corrupt

And why didnt you mae a bug report if you found something wrong with it?
I did, after I found out that the package was corrupt, I did "pacman -R gcc; pacman -Scc; pacman -S gcc" and this fixed the problem.
I did file a bug report, and I requested closure because the reinstall worked.
Comment by Thomas Dziedzic (tomd123) - Wednesday, 20 May 2009, 01:19 GMT
Another thing...
create a c file and include "main(){}" and see if that compiles. If it doesn't, you're most likely experiencing what I experienced.
Comment by Sven-Hendrik Haase (Svenstaro) - Thursday, 21 May 2009, 01:44 GMT
I just recompiled my kernel to confirm that this is not the case. There must be something else still that is special to Blender. Can you build the most recent Blender package just fine?
Comment by Alessandro Doro (adoroo) - Thursday, 21 May 2009, 17:45 GMT
Build process goes on here (i686, current).

g++ -c -DUSE_SUMO_SOLID -fopenmp -pipe -fPIC -funsigned-char -fno-strict-aliasing -DNDEBUG -O2 -Wall -W -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wredundant-decls -Wreorder -Wctor-dtor-privacy -Wnon-virtual-dtor -Woverloaded-virtual -Wsign-promo -Wsynth -DMOZ_NOT_NET -DPARALLEL -DNOGUI -DELBEEM_BLENDER -I. -I../extern -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include -I/usr/include/libpng solver_main.cpp -o /media/TEST/home/prove/blenderABS/src/blender-2.48a/obj/linux-glibc2.9-i386/intern/elbeem/solver_main.o
In file included from solver_main.cpp:1094:
paraloopend.h: In member function ‘void LbmFsgrSolver::mainLoop(int)’:
paraloopend.h:25: warning: comparison between signed and unsigned integer expressions
paraloopend.h:26: warning: comparison between signed and unsigned integer expressions
paraloopend.h:27: warning: comparison between signed and unsigned integer expressions
In file included from solver_main.cpp:1134:
paraloopend.h: In member function ‘void LbmFsgrSolver::preinitGrids()’:
paraloopend.h:25: warning: comparison between signed and unsigned integer expressions
paraloopend.h:26: warning: comparison between signed and unsigned integer expressions
paraloopend.h:27: warning: comparison between signed and unsigned integer expressions
In file included from solver_main.cpp:1197:
paraloopend.h: In member function ‘void LbmFsgrSolver::standingFluidPreinit()’:
paraloopend.h:25: warning: comparison between signed and unsigned integer expressions
paraloopend.h:26: warning: comparison between signed and unsigned integer expressions
paraloopend.h:27: warning: comparison between signed and unsigned integer expressions
g++ -c -DUSE_SUMO_SOLID -fopenmp -pipe -fPIC -funsigned-char -fno-strict-aliasing -DNDEBUG -O2 -Wall -W -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wredundant-decls -Wreorder -Wctor-dtor-privacy -Wnon-virtual-dtor -Woverloaded-virtual -Wsign-promo -Wsynth -DMOZ_NOT_NET -DPARALLEL -DNOGUI -DELBEEM_BLENDER -I. -I../extern -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include -I/usr/include/libpng solver_util.cpp -o /media/TEST/home/prove/blenderABS/src/blender-2.48a/obj/linux-glibc2.9-i386/intern/elbeem/solver_util.o
[...]
ar: creating /media/TEST/home/prove/blenderABS/src/blender-2.48a/obj/linux-glibc2.9-i386/intern/elbeem/libelbeem.a
Comment by Alessandro Doro (adoroo) - Thursday, 21 May 2009, 17:56 GMT
Sorry, I didn't notice that the error was in the debug directory.
After two minutes gcc crashes here also:
solver_main.cpp: In member function ‘void LbmFsgrSolver::mainLoop(int)’:
solver_main.cpp:1707: internal compiler error: Segmentation fault
Comment by vic (grimpeur) - Sunday, 31 May 2009, 09:31 GMT
same issue with 2.49 (compiling with gcc-4.4.0-2, PKGBUILD with changed blender version: 2.48a -> 2.49):

g++ -c -DUSE_SUMO_SOLID -DUSE_BULLET -DWITH_BULLET -fopenmp -pipe -fPIC -funsigned-char -fno-strict-aliasing -g -Wall -W -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wredundant-decls -Wreorder -Wctor-dtor-privacy -Wnon-virtual-dtor -Woverloaded-virtual -Wsign-promo -Wsynth -DMOZ_NOT_NET -DPARALLEL -DNOGUI -DELBEEM_BLENDER -I. -I../extern -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include -I/usr/include/libpng solver_main.cpp -o /var/abs/local/blender/src/blender-2.49/obj/linux-glibc2.10.1-x86_64/intern/elbeem/debug/solver_main.o

<...skipped...>

solver_main.cpp: In member function ‘void LbmFsgrSolver::mainLoop(int)’:
solver_main.cpp:1707: internal compiler error: Segmentation fault

it seems, that problem arises cause of parallel calculations: -DPARALLEL (or -fopenmp)... unfortunately, I've no knowledge (and experience of compilation) to describe it more specifically
Comment by Alessandro Doro (adoroo) - Sunday, 31 May 2009, 11:06 GMT
You're right. With export "WITH_BF_OPENMP=false" the compilation goes on.
Comment by Sven-Hendrik Haase (Svenstaro) - Sunday, 07 June 2009, 00:09 GMT
Can this be resolved now? Blender 2.49 is out already and the package still hasn't been updated or fixed. If Tobias is unwilling or unable to continue maintaining this package, it should be taken over my another developer or TU.
Comment by F.Di Milia (PyCoder) - Monday, 08 June 2009, 05:45 GMT
I think the same that Sven says about maintaining.

2.48(a) is still buggy in extra.
2.49 is out and no update in extra.

It's time for a new maintainer?
Comment by Alessandro Doro (adoroo) - Monday, 08 June 2009, 16:34 GMT
I would wait for 2.49a. Bug hunting is very active at the moment.
Comment by Sven-Hendrik Haase (Svenstaro) - Monday, 08 June 2009, 21:58 GMT
Well, Alessandro, that is not how a rolling distribution is supposed to work. We want to always handle the newest released, non-dev version of all software and we are willing and able to submit bug reports to upstream. In this case though, it simply isn't an upstream bug but an old package.
Comment by F.Di Milia (PyCoder) - Monday, 22 June 2009, 11:54 GMT
Blender 2.49a is out now!
Comment by Matz Radloff (timesqueezer) - Tuesday, 23 June 2009, 14:29 GMT
nevertheless it fails to build :( what happened there!?
Comment by Matz Radloff (timesqueezer) - Tuesday, 30 June 2009, 19:25 GMT
i tested, if i can build blender from source without using the arch package and it builds :)
The arch package is broken..
Comment by atom karinca (atomkarinca) - Tuesday, 30 June 2009, 22:40 GMT
Building from ABS still gives the same error (solver_main.cpp:1707: internal compiler error: Segmentation fault). Also it's been a while since 2.49a came out, shouldn't the package have been updated by now?
Comment by Sven-Hendrik Haase (Svenstaro) - Tuesday, 30 June 2009, 23:07 GMT
I notified the package author. He told me that Blender was next on his list after fixing up Vim. We can only hope and bug the hell out of him.
Comment by atom karinca (atomkarinca) - Wednesday, 01 July 2009, 04:04 GMT
Thanks.
Comment by F.Di Milia (PyCoder) - Wednesday, 01 July 2009, 11:58 GMT
atom karnica aur/blender-bin works.
Comment by Alessandro Doro (adoroo) - Friday, 03 July 2009, 00:02 GMT
I'm not registered to AUR; I posted a working PKGBUILD in  FS#14893 . Please, read the comments in that task.
Comment by Alessandro Doro (adoroo) - Wednesday, 08 July 2009, 20:19 GMT
FYI I have found a workaround for the solver_mail.cpp compilation problem in the debug directory:
export NAN_DEBUG=-O
Comment by Sven-Hendrik Haase (Svenstaro) - Sunday, 19 July 2009, 03:45 GMT
The packager still doesn't answer, what to do? I wrote the open dev mailing list but was ignored.

Loading...