Here lies an ebuild that installs the core opencascade libraries needed for development and some CAD applications. The patch modifies the code to allow it to compile on AMD64 with >=gcc 3.4 and >=tcl/TK 8.4 For now, I am using sci-mathematics/opencascadelib but would like to see a new catagory for cad as things get rolling. This initial offering allows opencascade to compile, but I don't have an appilication to test it with yet, I submit this now to start the process and elicit feedback on the ebuild itself. (like java depends should be virtual) JFS
Created attachment 76830 [details] opencascadelib-5.2.ebuild
Created attachment 76831 [details, diff] opencascadelib.5.2.AMDGCCTCL.patch Patch made from diff file posted in opencascade forum by Frederic Deghetto. It allows compilation on amd64 gentoo with gcc 3.4.4 and tcl/tk8.4(I tested with gcc 3.4.5)
*** Bug 54998 has been marked as a duplicate of this bug. ***
A couple of notes: 1/ Kill the loads of left-over useless comments. 2/ Hardcoded SRC_URI - http://dev.gentoo.org/~ciaranm/docs/mw-faq/hardcoded.txt, also, you should use mirror://sourceforge/ 3/ You should use virtual/jdk instead of ||( >=dev-java/blackdown-jre-1.4.2 >=dev-java/blackdown-jdk-1.4.2) (also, you cannot compile against JRE) 4/ That src_compile() looks spooky - bash env.ksh ?! 5/ Is it really needed to use einstall? - http://dev.gentoo.org/~ciaranm/docs/mw-faq/einstall.txt
Jeff, Jakub Has the ebuild been modified since the beginning of January? I am very interested to test it. I have at my disposal an x86-based and an amd64-based machine. x86: gcc 4.1.1, glibc 2.4.0 amd64: gcc 3.4.5 glibc 2.3.6 Please do not hesitate to send the ebuild to me. Thanks in advance Daniel
Created attachment 88730 [details] Updated Ebuild Ebuild updated as per feedback.
Hello, Here are my first comments on the ebuild, I named the file opencascade-5.2.ebuild: I tried to create a digest: ebuild opencascade-5.2.ebuild digest but it complains that the source code cannot be found: Downloading http://mesh.dl.sourceforge.net/sourceforge/opencascadelib/opencascade-5.2.tar.gz No digest file available and download failed. !!! Couldn't download opencascade-5.2.tar.gz. Aborting. Then I looked on the website and found the following: http://www.opencascade.org/getocc/whatsnew/ There is a version 5.2.4 and a version 6.1 So here, which version are we dealing with? The plain 5.2 or already the 5.2.4 Then, if we consider the requirements: http://www.opencascade.org/getocc/require/ It can be noted that FLTK, Java, QT and TCLTK are required for specific purposes (testing tools). Can't it be reflected in the ebuild? As I said 6.1 has been released. Any plan for an ebuild? Can't 5.2.x and 6.1 be slotted?
Ebuilds can't be arbitraily renamed. I retested the ebuild and it is still compiling. :-) steps taken : add "sci-mathematics/opencascadelib ~amd64" into my portage/package.keywords create a opencascadelib directory in the sci-mathematics sub directory of my portageoverlay directory (see portage docs about overlays) ie /home/jeff/portageoverlay/sci-matematics/opencascadelib put the ebuild in it as named opencascadelib-5.2.ebuild mkdir "files" and place patch in the files directory, also as named. in the opencascadelib directory: touch ChangeLog ebuild opencascadelib-5.2.ebuild digest emerge opencascadelib Slotting is a good idea This is originally stated as a minimal library, a second ebuild opencascade-extras is planned. When I know what has to be added.
Built here using ~x86. I added ~x86 to KEYWORDS in the ebuild, and used > ebuild opencascadelib-5.2.ebuild digest > ebuild opencascadelib-5.2.ebuild unpack > ebuild opencascadelib-5.2.ebuild compile > ebuild opencascadelib-5.2.ebuild install > ebuild opencascadelib-5.2.ebuild qmerge > ebuild opencascadelib-5.2.ebuild clean It took a while to build, but all seems fine. AMD Athlon XP, kernel 2.6.16, gcc 3.3.6, tcl/tk 8.4.9, sun-jdk 1.4.2.10-r2 Keep up the good work Jeff - I look forward to an ebuild for Salome ;-) Arthur
Hello, Sorry for my late answer. I did not find the time to test your ebuild previously. I have just done it on a x86 machine. The compilation went flawlessly (it took 3 hours though...), however, the program DRAWEXE does not start. It complains that it does not find files under /var/OpenCASCADE5.2/ros (ans indeed, there are no such directory on my machine). So, what is supposed to be done now? Daniel
Arthur, Jeff I took a look on the opencascade forum and saw that there is now on the FreeBSD ftp site the extracted sourcecode for 6.1 (ftp://ftp.freebsd.org/pub/FreeBSD/ports/local-distfiles/thierry/). I tried to use the original OpenCASCADE_Linux.tgz for 6.1 but it complained about a missing library or something... Annoying. Now I am planning to play around with the source code a bit and see if it can be built on Gentoo... I keep you posted. Any help, check, test will be welcome... ;) Daniel
Hi Daniel, I've just replied to your message in the forums: http://forums.gentoo.org/viewtopic-p-3540973.html#3540973 If you download the Salome package, it contains the source for OCC 6.1 in a useable form. I downloaded the Debian package, as a good place to start. Unpack salome3_2_1_DS.tar.gz and look in ./InstallWizard_3_2_1_DS/Products/SOURCES/CAS-6.1 I built with ./configure --with-gl-include=/usr/include --with-gl-library=/usr/lib --with-xmu-include=/usr/include/X11 --with-xmu-library=/usr/lib --with-tcl=/usr/lib --with-tk=/usr/lib --disable-debug --enable-production --prefix=/opt/OpenCASCADE6.1.0 make su make install It should be quite easy to modify Jeffs ebuild to use this package. I've also built med_fichier from the sources included in the same place, same procedure. I don't know about hosting, separating the salome package into parts, etc. It says its LGPL, so I can't see this being a problem, but I've no experience doing this sort of thing. Any comments Jeff? Daniel, do you know anything about the BSD port, like how they've split the package?
Hello, I am trying to write an ebuild for 6.1.0 on an x86 box with gcc 4.1.1 I get the following error when I try to build the package: i686-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../inc -I../../../drv/FSD -I../../../src/FSD -I../../../drv/MMgt -I../../../src/MMgt -I../../../drv/OSD -I../../../src/OSD -I../../../drv/Plugin -I../../../src/Plugin -I../../../drv/Quantity -I../../../src/Quantity -I../../../drv/Resource -I../../../src/Resource -I../../../drv/SortTools -I../../../src/SortTools -I../../../drv/Standard -I../../../src/Standard -I../../../drv/StdFail -I../../../src/StdFail -I../../../drv/Storage -I../../../src/Storage -I../../../drv/TColStd -I../../../src/TColStd -I../../../drv/TCollection -I../../../src/TCollection -I../../../drv/TShort -I../../../src/TShort -I../../../drv/Units -I../../../src/Units -I../../../drv/UnitsAPI -I../../../src/UnitsAPI -I../../../drv/IncludeLibrary -I../../../src/IncludeLibrary -I../../../drv/Dico -I../../../src/Dico -I../../../drv/NCollection -I../../../src/NCollection -I../../../drv/Message -I../../../src/Message -DNDEBUG -DNo_Exception -O2 -MT Dico_IteratorOfDictionaryOfInteger_0.lo -MD -MP -MF .deps/Dico_IteratorOfDictionaryOfInteger_0.Tpo -c ../../../drv/Dico/Dico_IteratorOfDictionaryOfInteger_0.cxx -fPIC -DPIC -o .libs/Dico_IteratorOfDictionaryOfInteger_0.o ../../../drv/Dico/Dico_DictionaryOfInteger_0.cxx: In function 'Handle_Standard_Type& Dico_DictionaryOfInteger_Type_()': ../../../drv/Dico/Dico_DictionaryOfInteger_0.cxx:52: error: 'Standard_Transient_Type_' was not declared in this scope make[3]: *** [Dico_DictionaryOfInteger_0.lo] Error 1 make[3]: *** Waiting for unfinished jobs.... ../../../drv/Dico/Dico_DictionaryOfTransient_0.cxx: In function 'Handle_Standard_Type& Dico_DictionaryOfTransient_Type_()': ../../../drv/Dico/Dico_DictionaryOfTransient_0.cxx:55: error: 'Standard_Transient_Type_' was not declared in this scope make[3]: *** [Dico_DictionaryOfTransient_0.lo] Error 1 make[3]: Leaving directory `/var/tmp/portage/opencascade-6.1/work/opencascade-6.1/ros/adm/make/TKernel' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/opencascade-6.1/work/opencascade-6.1/ros/adm/make' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/opencascade-6.1/work/opencascade-6.1/ros' make: *** [all] Error 2 I think it is related to gcc 4.1.x Any hint? Daniel
Hello, With gcc-4.0.3 I got another compilation issue with OpenCascade 6.1: i686-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -I/usr/include/stlport -I../../../inc -I../../../drv/DBC -I../../../src/DBC -I../../../drv/PCollection -I../../../src/PCollection -I../../../drv/PColStd -I../../../src/PColStd -I../../../drv/PMMgt -I../../../src/PMMgt -I../../../drv/PShort -I../../../src/PShort -I../../../drv/PStandard -I../../../src/PStandard -I../../../drv/PTColStd -I../../../src/PTColStd -I../../../drv/ObjMgt -I../../../src/ObjMgt -I/usr/include/stlport -DNDEBUG -DNo_Exception -O2 -MT DBC_VArrayNodeOfVArrayOfCharacter_0.lo -MD -MP -MF .deps/DBC_VArrayNodeOfVArrayOfCharacter_0.Tpo -c ../../../drv/DBC/DBC_VArrayNodeOfVArrayOfCharacter_0.cxx -fPIC -DPIC -o .libs/DBC_VArrayNodeOfVArrayOfCharacter_0.o i686-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -I/usr/include/stlport -I../../../inc -I../../../drv/DBC -I../../../src/DBC -I../../../drv/PCollection -I../../../src/PCollection -I../../../drv/PColStd -I../../../src/PColStd -I../../../drv/PMMgt -I../../../src/PMMgt -I../../../drv/PShort -I../../../src/PShort -I../../../drv/PStandard -I../../../src/PStandard -I../../../drv/PTColStd -I../../../src/PTColStd -I../../../drv/ObjMgt -I../../../src/ObjMgt -I/usr/include/stlport -DNDEBUG -DNo_Exception -O2 -MT DBC_VArrayNodeOfVArrayOfInteger_0.lo -MD -MP -MF .deps/DBC_VArrayNodeOfVArrayOfInteger_0.Tpo -c ../../../drv/DBC/DBC_VArrayNodeOfVArrayOfInteger_0.cxx -fPIC -DPIC -o .libs/DBC_VArrayNodeOfVArrayOfInteger_0.o ../../../inc/DBC_BaseArray.hxx:107: error: 'DBC_DBVArray' does not name a type ../../../inc/DBC_BaseArray.hxx:108: error: expected ',' or '...' before 'p' ../../../inc/DBC_BaseArray.hxx:108: error: ISO C++ forbids declaration of 'DBC_DBVArray' with no type ../../../inc/DBC_BaseArray.hxx:126: error: 'DBC_DBVArray' does not name a type ../../../inc/DBC_BaseArray.hxx: In member function 'void DBC_BaseArray::_CSFDB_SetDBC_BaseArraymyData(int)': ../../../inc/DBC_BaseArray.hxx:108: error: 'myData' was not declared in this scope ../../../inc/DBC_BaseArray.hxx:108: error: 'p' was not declared in this scope make[3]: *** [DBC_VArrayNodeOfVArrayOfCharacter_0.lo] Error 1 make[3]: *** Waiting for unfinished jobs.... ../../../inc/DBC_BaseArray.hxx:107: error: 'DBC_DBVArray' does not name a type ../../../inc/DBC_BaseArray.hxx:108: error: expected ',' or '...' before 'p' ../../../inc/DBC_BaseArray.hxx:108: error: ISO C++ forbids declaration of 'DBC_DBVArray' with no type ../../../inc/DBC_BaseArray.hxx:126: error: 'DBC_DBVArray' does not name a type ../../../inc/DBC_BaseArray.hxx: In member function 'void DBC_BaseArray::_CSFDB_SetDBC_BaseArraymyData(int)': ../../../inc/DBC_BaseArray.hxx:108: error: 'myData' was not declared in this scope ../../../inc/DBC_BaseArray.hxx:108: error: 'p' was not declared in this scope make[3]: *** [DBC_VArrayNodeOfVArrayOfExtCharacter_0.lo] Error 1 ../../../inc/DBC_BaseArray.hxx:107: error: 'DBC_DBVArray' does not name a type ../../../inc/DBC_BaseArray.hxx:108: error: expected ',' or '...' before 'p' ../../../inc/DBC_BaseArray.hxx:108: error: ISO C++ forbids declaration of 'DBC_DBVArray' with no type ../../../inc/DBC_BaseArray.hxx:126: error: 'DBC_DBVArray' does not name a type ../../../inc/DBC_BaseArray.hxx: In member function 'void DBC_BaseArray::_CSFDB_SetDBC_BaseArraymyData(int)': ../../../inc/DBC_BaseArray.hxx:108: error: 'myData' was not declared in this scope ../../../inc/DBC_BaseArray.hxx:108: error: 'p' was not declared in this scope make[3]: *** [DBC_VArrayNodeOfVArrayOfInteger_0.lo] Error 1 make[3]: Leaving directory `/var/tmp/portage/opencascade-6.1/work/opencascade-6.1/ros/adm/make/PTKernel' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/opencascade-6.1/work/opencascade-6.1/ros/adm/make' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/opencascade-6.1/work/opencascade-6.1/ros' make: *** [all] Error 2 Any help is warmly welcome... Daniel
Hi Daniel, Okay, lets have a look at the first error: ../../../inc/DBC_BaseArray.hxx:107: error: 'DBC_DBVArray' does not name a type From the file <install base>/CAS-6.1/inc/DBC_BaseArray.hxx, lines 104-108: Standard_EXPORT virtual void ShallowDump(Standard_OStream& S) const; Standard_Integer _CSFDB_GetDBC_BaseArraymySize() const { return mySize; } void _CSFDB_SetDBC_BaseArraymySize(const Standard_Integer p) { mySize = p; } DBC_DBVArray _CSFDB_GetDBC_BaseArraymyData() const { return myData; } void _CSFDB_SetDBC_BaseArraymyData(const DBC_DBVArray p) { myData = p; } DBC_DBVArray looks like it should be defined as a type somewhere, but hasn't been. There is a header in the same directory called DBC_DBVArray.hxx, with some #ifdefs. Before we get lost in code, I'd guess that an include failed somewhere. Were there any compiler warnings earlier in the build? I've found some Salome makefiles where the path was correct, but the -I was missing from the front.
Hello Arthur, Thanks for your answer. You probably put your hands on the problem. Has there beeen any warning somewhere?... Yeah, good question... This problem presented itself after 3 hours of compilation and thousands of commands on the terminal... If only I knew how to filter things up (to get only the warnings for instance) or at least to get all these commands stored somewhere in a file where I could look in case of problems... Daniel
Hello, I got some information from the OpenCascade forum: http://www.opencascade.org/org/forum/thread_10190/ I will try this tonight. Daniel
Hello, The CXXFLAGS are not correctly setup (the CFLAGS are although). To make things right, one has to do: aclocal autoheader automake --add-missing libtoolize --force --copy autoconf And when 'configure' is called, the ros/Makefile contains the right options (it seems so at least). CXXFLAGS are similar to CFLAGS. In this spirit, I modified my ebuild. Now it looks as follows: src_compile() { cd ${S}/ros chmod u+x configure bash env.ksh aclocal || die "aclocal failed" autoheader || die "autoheader failed" automake --add-missing libtoolize --force --copy || die "libtoolize failed" autoconf || die "autoconf failed" ... However, I call from the ebuild 'configure' with many options: ./configure --prefix=/usr --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --with-java --with-qt3 --without-fltk --with-gl-include=/usr/include --with-gl-library=/usr/lib --with-xmu-include=/usr/include/X11 --with-xmu-library=/usr/lib --disable-debug --enable-production --prefix=/opt/OpenCASCADE6.1 --with-tcl=/usr/lib/ --with-tk=/usr/lib/ --with-stlport-library=/usr/lib/ --with-stlport-libname=stlport_gcc --with-stlport-include=/usr/include/stlport --build=i686-pc-linux-gnu And when I look at the Makefile, I find: CFLAGS = -march=prescott -mfpmath=sse -Os -pipe -DCSFDB -DNO_CXX_EXCEPTION -DLIN -DLININTEL -DNDEBUG -DNo_Exception -O2 CXXFLAGS = -I/usr/include/stlport -DNDEBUG -DNo_Exception -O2 Any idea? Daniel
I don't think it's the cause of the problem, but there are two --prefix flags in configure. What happens if you don't define --with-stlport-*? I've tried to find out about STLPort, but haven't got very far. Is it still necessary for gcc >=3? Also, do you need to specify the locations of TCL, TK, etc? If I've decided to put them in /usr/local, for example, the build will fail.
Hello, I did not see that I had defined --prefix twice. Thanks! About stlport, the problem is that, during linking, it looks for a stlport.a (or something like that) when it is called stlport_gcc.a on a gentoo system. Once this defined, I had to define as well where the headers were. Is stlport really necessary? I don't know... About tcltk, I basically did like it is done in any other ebuild. I start with the principle that tcltk has been installed through an ebuild. In any cases, there is a problem with configure. It screws up somehow the CXXFLAGS.
Sorry, I got a bit sidetracked by STLPort. I've had a quick look at my OCC Makefile. I used: ./configure --with-gl-include=/usr/include --with-gl-library=/usr/lib --with-xmu-include=/usr/include/X11 --with-xmu-library=/usr/lib --with-tcl=/usr/lib --with-tk=/usr/lib --disable-debug --enable-production --prefix=/opt/occ My C[XX]FLAGS are: [pppam:CAS-6.1]$ grep CFLAGS Makefile CFLAGS = -DCSFDB -DNO_CXX_EXCEPTION -DLIN -DLININTEL -DNDEBUG -DNo_Exception -O2 [pppam:CAS-6.1]$ grep CXXFLAGS Makefile CXXFLAGS = -DCSFDB -DNO_CXX_EXCEPTION -DLIN -DLININTEL -D_GNU_SOURCE=1 -DNDEBUG -DNo_Exception -O2 I didn't set any STLPort flags (I hadn't even noticed them ;-) and don't have it emerged. From my Makefile: [pppam:CAS-6.1]$ grep STL Makefile STLPort_INCLUDES = STLPort_LIB = I've found some of the Salome configure scripts get confused when I define package locations rather than letting configure find them (the -I settings come out wrong). Maybe not defining STLPort would also work? It's not a final solution, but it might get you a bit further? What are your system C[XX}FLAGS (from /etc/make.conf)?
Hello Arthur, I removed the --with-stlport-include and --with-stlport-library options and now the CXXFLAGS are not screwed up anymore... Very strange CFLAGS = -march=prescott -mfpmath=sse -Os -pipe -DCSFDB -DNO_CXX_EXCEPTION -DLIN -DLININTEL -DNDEBUG -DNo_Exception -O2 CPPFLAGS = CXXFLAGS = -march=prescott -mfpmath=sse -Os -pipe -DCSFDB -DNO_CXX_EXCEPTION -DLIN -DLININTEL -D_GNU_SOURCE=1 -DNDEBUG -DNo_Exception -O2 FFLAGS = -g -O2 My /etc/make.conf flags are CFLAGS="-march=prescott -mfpmath=sse -Os -pipe" CXXFLAGS="${CFLAGS}" Now it builds. Let's see how far it gets... ;) Daniel
Well, After MANY hours I get the following error message... Very frustrating...: make[2]: Leaving directory `/var/tmp/portage/opencascade-6.1/work/opencascade-6.1/ros/adm/make' make[2]: Entering directory `/var/tmp/portage/opencascade-6.1/work/opencascade-6.1/ros' make[2]: Nothing to be done for `all-am'. make[2]: Leaving directory `/var/tmp/portage/opencascade-6.1/work/opencascade-6.1/ros' make[1]: Leaving directory `/var/tmp/portage/opencascade-6.1/work/opencascade-6.1/ros' >>> Source compiled. >>> Test phase [not enabled]: sci-libs/opencascade-6.1 >>> Install opencascade-6.1 into /var/tmp/portage/opencascade-6.1/image/ category sci-libs make: *** No rule to make target `install'. Stop. !!! ERROR: sci-libs/opencascade-6.1 failed. Call stack: ebuild.sh, line 1539: Called dyn_install ebuild.sh, line 1013: Called src_install opencascade-6.1.ebuild, line 107: Called die !!! emake install failed !!! If you need support, post the topmost build error, and the call stack if relevant. !!! This ebuild is from an overlay: '/usr/local/portage' How in earth there is no install procedure!!!! This is insane: ./configure make make install That's the trilogy and apparently, one piece is missing... :( I join my ebuild, if anyone wants to take a look and see how to correct it. Daniel
Created attachment 96980 [details] First attempt for OpenCascade 6.1 Here is the first attempt of an ebuild for opencascade-6.1 Somehow the 'install' part does not work. Compilation runs fine though (with gcc-4.0.3)
One more comment: einstall fails the same way (instead of emake install) Daniel
Hello, I fixed the issue. It was not so complicated, as a matter of fact: The last lines of the ebuild have to be replaced by: src_install() { cd ${S}/ros emake DESTDIR="${D}" install || die "emake install failed" # dodir /etc/env.d # echo "CASROOT=\"/opt/OpenCASCADE6.1/ros\"" > ${D}/etc/env.d/50opencascade61 } Then files are installed the way they are supposed to. Now I need to clean up this ebuild and setup the local variables correctly. I will do it by the beginning of next week. Then, the ebuild will be ready for tests.
Created attachment 97364 [details] Second attempt for an ebuild This new ebuild should produce OpenCascade libraries and install them as well as the documentations. It is still running here so I cannot confirm it at a 100% but I think it should work. What remains to be done now is to fix all the environment variables. In princip it is not hard, It is just a matter of time... I start to wonder if the content of the ros/src directory does not need to be installed somewhere. My suspicions come from the nature of ros/env.ksh The way I deal with the recognitions of Tcl/TK, TIX and co is not idealistic. There should be a better way to setup the versions in env.ksh Any comment, help is welcome... Daniel PS: There is a problem with the doseds. I think I know what it is and I will try to solve it soon...
I confirm. It compiles and installs properly. Edges still need to be smoothened but in principle everything is here... Daniel
Created attachment 97539 [details] Alpha version of the ebuild. Please test it! Hello, Here is the 'alpha' version of the ebuild. It has to be tested extensively... A few changes compared to the previous one: - Documentation installed - Compatible with gcc-4.1.x - Tried to put some order in the environment variables Everything compiles fine (gcc 3.4.6 as well as 4.1.1 on an x86 box). However, there are still some issues with the environment variables, apparently. The programmation style of this ebuild is not very elegant but it can be improved, I am sure. I think the time has come to test it and iron out the last details. So, test it and report here the issues encountered. Daniel
Arthur, Shall we start a Salome forum and discuss what you achieved so far? I would like to test what you did with the OpenCascade ebuild I have. Besides, I can maybe give you a helping hand with the ebuilds. What do you think? > I've found some of the Salome configure scripts get confused when I define > package locations rather than letting configure find them (the -I settings come
Hello, I need some help. After having slightly modified the /etc/env.d/50opencascade-6.1 which is slightly wrong (I correct it in my next ebuild), DRAWEXE says the following: DRAWEXE couldn't read file "/usr//src/DrawResources/DrawDefault": no such file or directory % % exit Indeed I did not include this file (originally in ros/src) in the ebuild but here comes my problem: ros/src is _huge_ ! (175Mb). It contains all kind of files (.tcl, .c, .cxx etc etc...). So, which ones I am supposed to keep and which ones can I keep out of the resulting ebuild. Now I plan to put all these files in /usr/share/opencascade-6.1 but is it wise? Is it really the good place? Waiting for a feedback here from people who have actuallt been using this library and who have an insight on how things should be structured. BTW, is there a RedHat / SuSE RPM for opencascade? Is it possible to have the list of files they contain and where they are stored? That would be fairly useful. Daniel
Created attachment 97968 [details] second 'alpha' - I removed the tcl/tk flags (Tcl/tk IS needed anyway) according to the feedback I got from Etienne - I started to clean up a bit the environment variables which were broken.
Created attachment 97999 [details] Third 'alpha' In principle, this should correct the bug with the gcc_version test. I discovered yesterday evening on my gcc-4.1.1 based box that the test on the compiler version was not carried on and that the extra CXXFLAG was not setup. This is probably the origin of the problem mentionned by Etienne. To solve that I basically added a: inherit eutils toolchain-funcs hopefully that will be enough
Created attachment 98736 [details] We are getting closer to the holy grail... This one corrects the bug related to the test around the version of gcc and the addition of specific compilation flags for gcc4 Most of the source code is now put into /usr/share/opencascade-6.1. This seems to be plain stupid but necessary... :( This has to be discussed and improved (probably many things do NOT really need to be there). DRAWEXE seems to work (halleluia!) Now please, test the beast and report here... ;) Daniel
Created attachment 98737 [details] A patch for gcc4 To make OpenCascade compile on gcc4, one can add some compilation flags or apply this patch. At the moment, I do not really know which one is the most relevant.
Created attachment 98827 [details] Beta 1 We should be pretty close to the final one with this ebuild. - Before installing files under /usr/share/opencascade-6.1, the source is cleaned from any residual object file, Makefile etc etc... This makes the package 500Mb lighter... ;) - It should build and install properly on AMD64. This remains to be tested thoroughly. One thing is for sure at the moment, I had to remove the dependency on tix, tix-8.4.0 does not compile on my amd64 box... So please, test this ebuild and report here! Daniel
Created attachment 100232 [details] New ebuild (beta 2) See the Changelog for the changes. In short: install now under /usr/opencascade-6.1, added missing stuff. The library is now recognized by Salome (the kernel). It was not before... :P Daniel
Created attachment 100233 [details] The Changelog
Created attachment 100290 [details] Beta 3 Corrected a minor issue with the 50opencascade-6.1 file
Created attachment 100618 [details] Beta 4 Switched from the additional flags to the patch provided by Erwan Adam to get Opencascade 6.1 built on gcc 4.1.1. The problem was triggered when building salome Kernel
Created attachment 100619 [details] Changelog A new Changelog
I have just build netgen with it and it seems to do what it is supposed to do... ;) So, I think the ebuild is fairly steady now... ;) Of course, everything can be improved and considering my relative lack of experience regarding the writing of an ebuild, I suppose things can be improved... 3 comments: - The ebuild uses Tix and tix does not build on amd64. That's IMHO the ony issue regarding OpenCascade on amd64. Once tix is fixed, opencascade can be build on amd64 boxes (I think). I filled up a bug report but it remained unanswered. - I am in the process of writing ebuilds for netgen-4.4 and Salome 3.2.2. They both need OpenCascade but in the case of netgen, this is optional, therefor I request also an 'opencascade' flag. - I slotted it (slot="6") and it is installed under /usr/opencascade-6.1. This choice is based on the nature and the structure of OpenCascade. Regarding the slotting, I did that in prevision of a possible ebuild for opencascade-5.2 and 7.x (if ever). I am not sure though that it is rock steady in term of slotting... Any proposal / amelioration is welcome... ;)
Hello Daniel, Thank you for pointing me to this ebuild. I will try it out the coming week. Have you done ebuilds for netgen-4.4 and Salome 3.2.2? Michael
Michael, As you found yourself, my ebuild for netgen is almost finished and is usable at the moment. Salome is an other issue... This is a huge package and I have difficulties with it... I also lack time and competences regarding the subtilities of portage. However, if you feel up to it, we can try to achieve this goal together. As I discovered myself, to write simple ebuilds is not so complicated. You just have to sit behind the PC and give it a try... :) Daniel
Corrected minor issues in the OpenCascade-6.1-r1 ebuild (LDPATH) Modified the Changelog Started with an OpenCascade-6.2 ebuild (The patch seems to be uncomplete though)
Created attachment 114511 [details] Beta 5 (OpenCascade-6.1-r1) Corrected minor issues
Created attachment 114512 [details] ebuild for OpenCASCADE 6.2 ebuild for OpenCASCADE 6.2 (the associated patch needs some work though)
Created attachment 114513 [details] ebuild for OpenCASCADE 6.2 ebuild for OpenCASCADE 6.2 (the associated patch needs some work though)
Created attachment 114515 [details, diff] Patch for OpenCASCADE 6.2 with gcc-4.1 The patch seems to be uncomplete though. I will check this later
Created attachment 114517 [details] New Changelog New changelog
Created attachment 118661 [details] opencascade 6.2 ebuild fails on amd64 arch. David: you requested some feedback on the ebuilds you posted. Here is mine (see log attached). I'm using gentoo/amd64 . BTW I've tried to compile opencascade by hand and failed to do it since a few days. Feel free to mail me for some precisions, etc. Florent.
Created attachment 118663 [details, diff] ebuild patch: virtual/x11 fails => replaced by x11-base/xorg-x11. This patch is literally what I made to allow the ebuild to process (which failed nevertheless, see last attachment). It's just a guess; I've never written an ebuild myself. Florent.
Salut Florent, I know about the problem with 6.2 (disregarding the trivial x11 stuff) 6.1 works flawlessly though (I tested the ebuild on my x86 and amd64 boxes) It seems like 6.2 would require a patch that I do not have at the moment... :( Did you finally get 6.2 to work? (I have gcc 4.1.2) Daniel
Created attachment 120461 [details] New ebuild for 6.1. It takes into account a few new things and Florent's comments This ebuild needs to be tested carefully. I have also been working on 6.2 that I am testing right now on my x86 box.
Created attachment 120462 [details, diff] New patch for 6.1 This patch is planed replace the old one for 6.1 (#98737). It needs to be tested though...
Created attachment 120463 [details] New ebuild for 6.2. I am building it now on my x86 box. It takes hours... So far, no problem...
Created attachment 120464 [details, diff] New patch for 6.2 with gcc-4.1 This new patch includes what Florent sent me.
Created attachment 120466 [details] A slightly more advanced ebuild for 6.2. This ebuild is a bit more 'advanced'... It needs to be carefully tested on x86 and amd64. I tried to include some of the comments / advices from Florent
Created attachment 120468 [details] New Changelog
(In reply to comment #58) < Extracted from the updated occ-6.2 ebuild. < local myconf="--prefix=/usr/${P}/ros/lin --with-tcl=/usr/lib/ --with-tk=/usr/lib/" < if use X; then < myconf="${myconf} --with-x" < if use opengl; then < myconf="${myconf} --with-gl-include=/usr/include --with-gl-library=/usr/lib" Do you really need to precise those includes? (I didn't.) Also, the current install-path is /usr/opencascade . Wouldn't it fit better in /opt/opencascade ? My /opt contains big softs, featuring less integration, such as Mathematica, googleearth, or java jre's (blackdown as well as sun). My point is that the directory layer of occ doesn't respect fhs, that's why it wouldn't fit in /usr .
I am testing now the new ebuilds and I am planning to remove the unnecessary paths specifications, as far as possible. Regarding the place where opencascade has to be build, I made a choice. I could have made an other one (as /opt/opencascade). Personally, I don't really care. I will let the gentoo guys decide on where they want to have it.
Created attachment 120519 [details] Corrected 6.1-r2 I corrected a few mistakes on the previous ebuild. I reintegrated the specification of OpenGL and XMU libraries, to avoid warnings. This is probably not really necessary though... This ebuild builds on x86 and seems to work correctly. It needs to be tested on amd64 now
Created attachment 120524 [details] Corrected 6.2-r1
6.1-r2 builds and seems to work on: x86, gcc-4.1.2 amd64, gcc-3.4.6 6.2-r1 builds and seems to work on: x86, gcc-4.1.2 amd64? I check tonight.
(In reply to comment #64) > 6.1-r2 builds and seems to work on: > x86, gcc-4.1.2 > amd64, gcc-3.4.6 x86, gcc-3.4.6 > 6.2-r1 builds and seems to work on: > x86, gcc-4.1.2 amd64, gcc-3.4.6 x86, gcc-3.4.6
(In reply to comment #65) > (In reply to comment #64) opencascade-6.2-r1 doesn't work for amd64 with gcc-4.1.2 . I've lost my logfile! Sorry.
I got somehow confused. 6.2-r1 does not build on x86 with gcc-4.1.2 6.2-r1 does not seem to built either on amd64 with gcc-4.1.2 One of the first mistake I made and noticed is that I used append-flags instead of append-ldflags Then I wonder if the patch I provided is really efficient... It will be a lot of try and retry (5 hours of compilation every time... :( )
The final list at the moment: (In reply to comment #65) > (In reply to comment #64) > > 6.1-r2 builds and seems to work on: > > x86, gcc-4.1.2 > > amd64, gcc-3.4.6 > x86, gcc-3.4.6 > > > 6.2-r1 builds and seems to work on: > amd64, gcc-3.4.6 > x86, gcc-3.4.6 >
The source code doesn'compile with gcc4.1.1.. i686-pc-linux-gnu-g++ -O2 -march=athlon -pipe -DCSFDB -DOCC_CONVERT_SIGNALS -DLIN -DLININTEL -D_GNU_SOURCE=1 -DNDEBUG -DNo_Exception -O2 -o .libs/DRAWEXE DRAWEXE.o ../TKDraw/.libs/libTKDraw.so /var/tmp/portage/sci-misc/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/TKMesh/.libs/libTKMesh.so /var/tmp/portage/sci-misc/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/TKHLR/.libs/libTKHLR.so -L/usr/lib ../TKMesh/.libs/libTKMesh.so ../TKGeomAlgo/.libs/libTKGeomAlgo.so ../TKTopAlgo/.libs/libTKTopAlgo.so ../TKHLR/.libs/libTKHLR.so /var/tmp/portage/sci-misc/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/TKTopAlgo/.libs/libTKTopAlgo.so /var/tmp/portage/sci-misc/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/TKGeomAlgo/.libs/libTKGeomAlgo.so /var/tmp/portage/sci-misc/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/TKBRep/.libs/libTKBRep.so ../TKGeomBase/.libs/libTKGeomBase.so ../TKG2d/.libs/libTKG2d.so ../TKBRep/.libs/libTKBRep.so /var/tmp/portage/sci-misc/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/TKGeomBase/.libs/libTKGeomBase.so /var/tmp/portage/sci-misc/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/TKG3d/.libs/libTKG3d.so ../TKMath/.libs/libTKMath.so ../TKG3d/.libs/libTKG3d.so /var/tmp/portage/sci-misc/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/TKG2d/.libs/libTKG2d.so /var/tmp/portage/sci-misc/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/TKMath/.libs/libTKMath.so /var/tmp/portage/sci-misc/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/TKernel/.libs/libTKernel.so ../TKernel/.libs/libTKernel.so -lpthread -ltcl8.4 -ltk8.4 -ldl -lieee -lm -Wl,--rpath -Wl,/usr/opencascade-6.2/ros/lin/lib /var/tmp/portage/sci-misc/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/TKernel/.libs/libTKernel.so: undefined reference to `pow(Handle_Units_Dimensions const&, int)' collect2: ld returned 1 exit status make[3]: *** [DRAWEXE] Error 1 make[3]: Leaving directory `/var/tmp/portage/sci-misc/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/DRAWEXE' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/sci-misc/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/sci-misc/opencascade-6.2-r1/work/opencascade-6.2/ros' make: *** [all] Error 2 !!! ERROR: sci-misc/opencascade-6.2-r1 failed. Call stack: ebuild.sh, line 1614: Called dyn_compile ebuild.sh, line 971: Called qa_call 'src_compile' environment, line 3964: Called src_compile opencascade-6.2-r1.ebuild, line 126: Called die !!! emake failed !!! If you need support, post the topmost build error, and the call stack if relevant. !!! A complete build log is located at '/var/tmp/portage/sci-misc/opencascade-6.2-r1/temp/build.log'. !!! This ebuild is from an overlay: '/usr/local/portage' Fertig.
I tried the 6.2-r1 ebuild on an x86 machine. The error i got was i686-pc-linux-gnu-g++ -O2 -march=pentium-m -pipe -fomit-frame-pointer -DCSFDB -DOCC_CONVERT_SIGNALS -DLIN -DLININTEL -D_GNU_SOURCE=1 -DNDEBUG -DNo_Exception -O2 -o .libs/DRAWEXE DRAWEXE.o ../TKDraw/.libs/libTKDraw.so /mnt/nfs_portagetmp/portage/sci-libs/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/TKMesh/.libs/libTKMesh.so /mnt/nfs_portagetmp/portage/sci-libs/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/TKHLR/.libs/libTKHLR.so -L/usr/lib ../TKMesh/.libs/libTKMesh.so ../TKGeomAlgo/.libs/libTKGeomAlgo.so ../TKTopAlgo/.libs/libTKTopAlgo.so ../TKHLR/.libs/libTKHLR.so /mnt/nfs_portagetmp/portage/sci-libs/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/TKTopAlgo/.libs/libTKTopAlgo.so /mnt/nfs_portagetmp/portage/sci-libs/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/TKGeomAlgo/.libs/libTKGeomAlgo.so /mnt/nfs_portagetmp/portage/sci-libs/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/TKBRep/.libs/libTKBRep.so ../TKGeomBase/.libs/libTKGeomBase.so ../TKG2d/.libs/libTKG2d.so ../TKBRep/.libs/libTKBRep.so /mnt/nfs_portagetmp/portage/sci-libs/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/TKGeomBase/.libs/libTKGeomBase.so /mnt/nfs_portagetmp/portage/sci-libs/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/TKG3d/.libs/libTKG3d.so ../TKMath/.libs/libTKMath.so ../TKG3d/.libs/libTKG3d.so /mnt/nfs_portagetmp/portage/sci-libs/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/TKG2d/.libs/libTKG2d.so /mnt/nfs_portagetmp/portage/sci-libs/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/TKMath/.libs/libTKMath.so /mnt/nfs_portagetmp/portage/sci-libs/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/TKernel/.libs/libTKernel.so ../TKernel/.libs/libTKernel.so -ltcl8.4 -ltk8.4 -ldl -lieee -lm -Wl,--rpath -Wl,/usr/opencascade-6.2/ros/lin/lib /mnt/nfs_portagetmp/portage/sci-libs/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/TKernel/.libs/libTKernel.so: undefined reference to `pthread_create' /mnt/nfs_portagetmp/portage/sci-libs/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/TKernel/.libs/libTKernel.so: undefined reference to `pthread_detach' /mnt/nfs_portagetmp/portage/sci-libs/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/TKernel/.libs/libTKernel.so: undefined reference to `pow(Handle_Units_Dimensions const&, int)' /mnt/nfs_portagetmp/portage/sci-libs/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/TKernel/.libs/libTKernel.so: undefined reference to `pthread_mutex_trylock' /mnt/nfs_portagetmp/portage/sci-libs/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/TKernel/.libs/libTKernel.so: undefined reference to `pthread_join' collect2: ld returned 1 exit status make[3]: *** [DRAWEXE] Error 1 make[3]: Leaving directory `/mnt/nfs_portagetmp/portage/sci-libs/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/DRAWEXE' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/mnt/nfs_portagetmp/portage/sci-libs/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/mnt/nfs_portagetmp/portage/sci-libs/opencascade-6.2-r1/work/opencascade-6.2/ros' make: *** [all] Error 2 !!! ERROR: sci-libs/opencascade-6.2-r1 failed. Call stack: ebuild.sh, line 1615: Called dyn_compile ebuild.sh, line 972: Called qa_call 'src_compile' ebuild.sh, line 44: Called src_compile opencascade-6.2-r1.ebuild, line 125: Called die My emerge --info is: $ emerge --info ' Portage 2.1.2.7 (default-linux/x86/2006.1, gcc-4.1.2, glibc-2.5-r2, 2.6.19-suspend2-r1 i686) ================================================================= System uname: 2.6.19-suspend2-r1 i686 Intel(R) Pentium(R) M processor 1.73GHz Gentoo Base System release 1.12.9 Timestamp of tree: Sun, 27 May 2007 14:00:01 +0000 dev-java/java-config: 1.3.7, 2.0.33 dev-lang/python: 2.4.4-r4 dev-python/pycrypto: 2.0.1-r5 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.16 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium-m -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/NX/etc /usr/NX/home /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config /usr/spool/PBS" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/php/apache2-php4/ext-active/ /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php4/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php4/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-O2 -march=pentium-m -pipe -fomit-frame-pointer" DISTDIR="/mnt/nfs_portage/distfiles" FEATURES="distlocks metadata-transfer parallel-fetch sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="en_GB" LINGUAS="en_GB" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/mnt/nfs_portagetmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/layman/xeffects /usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X a52 aac acpi addbookmarks adsl akode alias alsa amarok amr amrr arts asf atm audiofile autoreplace bash-completion berkdb bitmap-fonts bluetooth browserplugin bzip2 cddb cdparanoia cdrom chm chroot clamav cli commercial connectionstatus contactnotes cracklib crypt css cups dbus dhcp divx divx4linux djvu doc dri dvd dvdr dvdread dvi emerald examples exif fbsplash firefox fortran freetype gcj gd gdbm gif gimp glitz glx gmtsuppl gmttria gphoto2 gpm h323 hal highlight history iconv idn ieee1394 ilbc imagemagick ipod irc isdnlog jabber java jingle jpeg jpeg2k kde kdeenablefinal kdgraphics kipi latex lcms ldap libg++ live mad midi mmx mmxext mng mozbranding mp3 mplayer mudflap musicbrainz nas ncurses net network nls nodrm nowlistening nptl nptlonly nsplugin nxclient ofx ogg oggvorbis opengl openmp oss pam pcntl pcre pdf perl png posix ppds pppd python qt3 qt3support rdesktop readline real reflection samba sametime scanner screen session slp sms speech speex spl sqlite3 sse sse2 ssl statistics svg tcl tcltk tcpd tetex texteffect theora tiff truetype truetype-fonts type1-fonts unicode unzip upnp usb v4l v4l2 vcd vnc vorbis webpresence wifi win32codecs winpopup wmf x86 xchatdccserver xcomposite xine xorg xosd xv xvid yahoo yaz zeroconf zip zlib" ALSA_CARDS="intel8x0 intel8x0m" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en_GB" USERLAND="GNU" VIDEO_CARDS="i810 fbdev i740 vesa" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Created attachment 121948 [details, diff] lpthread argument to g++ needed for gcc-4.1 (In reply to comment #70) > I tried the 6.2-r1 ebuild on an x86 machine. The error i got was > [...] > /mnt/nfs_portagetmp/portage/sci-libs/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/TKernel/.libs/libTKernel.so: > undefined reference to `pthread_create' > /mnt/nfs_portagetmp/portage/sci-libs/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/TKernel/.libs/libTKernel.so: > undefined reference to `pthread_detach' > /mnt/nfs_portagetmp/portage/sci-libs/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/TKernel/.libs/libTKernel.so: > undefined reference to `pow(Handle_Units_Dimensions const&, int)' > /mnt/nfs_portagetmp/portage/sci-libs/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/TKernel/.libs/libTKernel.so: > undefined reference to `pthread_mutex_trylock' > /mnt/nfs_portagetmp/portage/sci-libs/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/TKernel/.libs/libTKernel.so: > undefined reference to `pthread_join' > collect2: ld returned 1 exit status > make[3]: *** [DRAWEXE] Error 1 > make[3]: Leaving directory The g++ spell needs an "-lpthread" argument in the makefile. I managed to compile under amd64, but the makefiles are generated by autotools, so one needs to modify those if one wants to patch the ebuild. If anyone does, the joined patches do the right modification, but not on the good file (the autoconf-generated makefile is always younger than the original, and "patch" is age-sensitive). They could save time to you anyway, if you're really willing to make it work.
Created attachment 121950 [details, diff] lpthread argument to g++ needed for gcc-4.1 (the second patch - see previous post.)
(In reply to comment #72) > Created an attachment (id=121950) [edit] > lpthread argument to g++ needed for gcc-4.1 Note that the ebuild holds a line is src_compile saying: append-flags -lpthread I just don't know what's going on over there in append-flags but this doesn't seem to work.
Ok, i added -lpthread to the Makefile. And this time i tried to compile on my amd64 system (Intel core2duo). This is what i get x86_64-pc-linux-gnu-g++ -march=nocona -O2 -pipe -DCSFDB -DOCC_CONVERT_SIGNALS -DLIN -DLININTEL -D_GNU_SOURCE=1 -DNDEBUG -DNo_Exception -O2 -o .libs/DRAWEXE DRAWEXE.o ../TKDraw/.libs/libTKDraw.so /var/tmp/portage/sci-libs/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/TKMesh/.libs/libTKMesh.so /var/tmp/portage/sci-libs/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/TKHLR/.libs/libTKHLR.so -L/usr/lib64 ../TKMesh/.libs/libTKMesh.so ../TKGeomAlgo/.libs/libTKGeomAlgo.so ../TKTopAlgo/.libs/libTKTopAlgo.so ../TKHLR/.libs/libTKHLR.so /var/tmp/portage/sci-libs/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/TKTopAlgo/.libs/libTKTopAlgo.so /var/tmp/portage/sci-libs/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/TKGeomAlgo/.libs/libTKGeomAlgo.so /var/tmp/portage/sci-libs/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/TKBRep/.libs/libTKBRep.so ../TKGeomBase/.libs/libTKGeomBase.so ../TKG2d/.libs/libTKG2d.so ../TKBRep/.libs/libTKBRep.so /var/tmp/portage/sci-libs/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/TKGeomBase/.libs/libTKGeomBase.so /var/tmp/portage/sci-libs/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/TKG3d/.libs/libTKG3d.so ../TKMath/.libs/libTKMath.so ../TKG3d/.libs/libTKG3d.so /var/tmp/portage/sci-libs/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/TKG2d/.libs/libTKG2d.so /var/tmp/portage/sci-libs/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/TKMath/.libs/libTKMath.so /var/tmp/portage/sci-libs/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/TKernel/.libs/libTKernel.so ../TKernel/.libs/libTKernel.so -lpthread -ltcl8.4 -ltk8.4 -ldl -lieee -lm -Wl,--rpath -Wl,/usr/opencascade-6.2/ros/lin/lib64 /var/tmp/portage/sci-libs/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/TKernel/.libs/libTKernel.so: undefined reference to `pow(Handle_Units_Dimensions const&, int)' collect2: ld returned 1 exit status make[3]: *** [DRAWEXE] Error 1 make[3]: Leaving directory `/var/tmp/portage/sci-libs/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make/DRAWEXE' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/sci-libs/opencascade-6.2-r1/work/opencascade-6.2/ros/adm/make' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/sci-libs/opencascade-6.2-r1/work/opencascade-6.2/ros' make: *** [all] Error 2 !!! ERROR: sci-libs/opencascade-6.2-r1 failed. Call stack: ebuild.sh, line 1615: Called dyn_compile ebuild.sh, line 972: Called qa_call 'src_compile' ebuild.sh, line 44: Called src_compile opencascade-6.2-r1.ebuild, line 126: Called die !!! emake failed !!! If you need support, post the topmost build error, and the call stack if relevant. !!! A complete build log is located at '/var/tmp/portage/sci-libs/opencascade-6.2-r1/temp/build.log'. !!! This ebuild is from an overlay: '/usr/local/portage' emerge --info says: Portage 2.1.2.7 (default-linux/amd64/2007.0, gcc-4.1.2, glibc-2.5-r3, 2.6.21-gentoo-r2 x86_64) ================================================================= System uname: 2.6.21-gentoo-r2 x86_64 Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz Gentoo Base System release 1.12.9 Timestamp of tree: Mon, 11 Jun 2007 17:30:01 +0000 dev-java/java-config: 1.3.7, 2.0.32 dev-lang/python: 2.4.4-r4 dev-python/pycrypto: 2.0.1-r5 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.16 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS=" -march=nocona -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS=" -march=nocona -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer parallel-fetch sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="en_GB" LINGUAS="en_GB" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/layman/xeffects /usr/local/layman/berkano /usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X a52 aac acl acpi addbookmarks adsl akode alias alsa amd64 amr amrr apache2 arts asf atm audiofile autoreplace bash-completion beagle berkdb bitmap-fonts bluetooth bzip2 cddb cdparanoia cdr cdrom chm chroot cjk clamav cli connectionstatus contactnotes cracklib crypt css cups dbus dga dhcp divx divx4linux djvu dri dv dvd dvdnav dvdr dvdread dvi emerald encode exif fame fbsplash firefox fortran freetype gcj gd gdbm gif gimp glitz glx gmedia gnutls gphoto2 gpm h323 hal highlight history iconv idn ieee1394 ilbc imagemagick ipod irc isdnlog jabber java jingle jpeg jpeg2k kde kdeenablefinal kdepim kdgraphics kipi latex ldap libg++ libsamplerate lirc live mad midi mikmod mmx mmx2 mmxext mng mozbranding moznopango mp3 mplayer msn mudflap musicbrainz nas ncurses net netpbm network nls nodrm nowlistening nptl nptlonly nsplugin nvidia nxclient ofx ogg opengl openmp openssh oss pam pcntl pcre pda pdf perl php png posix ppds pppd python qt3 quicktime rdesktop readline realmedia reflection samba sametime scanner screen sensord session slp smp sms spamassassin speech speex spl sse sse2 ssl statistics subtitles svg tcl tcltk tcpd teamarena tetex texteffect theora tiff tk truetype truetype-fonts type1 type1-fonts unicode unzip upnp usb v4l v4l2 vcd vnc vorbis webpresence wifi winpopup wmf wmp xattr xchatdccserver xcomposite xine xinerama xorg xosd xv xvid yahoo yaz zeroconf zip zlib" ALSA_CARDS="emu10k1 via82xx hda-intel intel8x0" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en_GB" LIRC_DEVICES="irdeo_remote" USERLAND="GNU" VIDEO_CARDS="apm dummy nv v4l vesa vga vmware nvidia" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Hello *, got exactly the same error as above :-( Any solution? thankx
Hello, Sorry for the delay in my answers. I think that you can solve the problem more elegantly (that's something I had mentionned in one of my comment earlier): Try with 'append-ldflags', not 'append-flags' Daniel > > lpthread argument to g++ needed for gcc-4.1 > > Note that the ebuild holds a line is src_compile saying: > > append-flags -lpthread > > I just don't know what's going on over there in append-flags but this doesn't > seem to work. >
Created attachment 131942 [details] opencascade-6.1-r3.ebuild The modification in this ebuild are the following: - Added 'append-ldflags lpthread' - Removed the patch to work with gcc-4.1.x - Added the 'append-flags -ffriend-injection -fpermissive' instead. This is _not_ a new solution. It has been tested previously (and it needs to be tested any further). This ebuild builds on x86 with gcc 3.4.x and 4.1.x I think it builds as well on amd64 with gcc 3.4.x Daniel
Created attachment 131945 [details] opencascade-6.2-r2.ebuild opencascade-6.2-r2.ebuild (Please note, this is 6.2!) The modification in this ebuild are the following: - Added 'append-ldflags lpthread' - Removed the patch to work with gcc-4.1.x - Added the 'append-flags -ffriend-injection -fpermissive' instead. This is _not_ a new solution. It has been tested previously (and it needs to be tested any further). This ebuild builds on x86 with gcc 3.4.x and 4.1.x I think it builds as well on amd64 with gcc 3.4.x Daniel
Created attachment 131951 [details] New Changelog New Changelog to reflect the creation of 6.2-r2 and 6.1-r3 The resulting libraries need to be heavily tested though. Daniel
I've been using OpenCascade under gentoo for 2 months. Both flags and patches are working fine. However, if you don't use the patches you have to carefully add two additional flags if you are under 64bits. Also, if you choose the flags, then you have to add them also when building applications using the library and including the affected .hxx files. I would recommend to switch to the patches way. I'm currently using this option succesfully with 64 bits. I also would like to ask if there is a way apart from downloading the file and making it a local. I mean an overlay or whatever. Thank you!
Thank you for that ebuild! But how you get the sources is not very nice. What is against that way, which is provided in the FreeBSD Makefile: http://www.freebsd.org/cgi/cvsweb.cgi/ports/cad/opencascade/Makefile?rev=1.5 ? When everybody can download the sources from http://files.opencascade.com/OCC_6.2_release/OpenCASCADE_Linux.tgz it is more probably that they will stay there, instead on the FreeBSD ftp Servers. And then you can extract the tarball as it is described in the FreeBSD Makefile. Nevertheless, have you done a great job. But please make it available through an overlay, for example sunrise or science.
(In reply to comment #81) > Thank you for that ebuild! But how you get the sources is not very nice. What > is against that way, which is provided in the FreeBSD Makefile: > http://www.freebsd.org/cgi/cvsweb.cgi/ports/cad/opencascade/Makefile?rev=1.5 ? > When everybody can download the sources from > http://files.opencascade.com/OCC_6.2_release/OpenCASCADE_Linux.tgz it is more > probably that they will stay there, instead on the FreeBSD ftp Servers. And > then you can extract the tarball as it is described in the FreeBSD Makefile. > Nevertheless, have you done a great job. But please make it available through > an overlay, for example sunrise or science. > Yes, as nobody answered me, I decided to take the next step, make some modifications (adding some USE flags for java wrapping, the DRAW test harness and WOK which would save time for people not needing them). I've also changed some things that could lead to problems in non-standard directory structures. The other thing is that I switched back to the patch version, it is far better. I've been talking to the guys in Sunrise overlay and after testing it under amd64 and x86 I'll post them both in here and the overlay. I didn't know you could download them from there. I'll make the changes and test it.
I don't know if the ebuild was working for you, but I'm making huge changes to have it working. Is it working for you? Well, anyway I'm already working on the changes, is just that each trial takes 4 hours. There are problems with: - Placement of files - Environment variables - File permissions (you can't even see what's inside) - distclean is not working, and you don't need to do it. After merging, everything is gone. - 64-32 bits problems with directories - It is a nice improvement to set some more USE flags: WOK and DRAW are big parts and it saves time and space if you don't plan to use it. I'm almost done, and I'll post it here and then move it to the overlays.
Hello, > I've been using OpenCascade under gentoo for 2 months. Both flags and patches > are working fine. However, if you don't use the patches you have to carefully > add two additional flags if you are under 64bits. Also, if you choose the > flags, then you have to add them also when building applications using the > library and including the affected .hxx files. Yes, I know that. The problem is not with OpenCascade, the problem is with Salome-GUI (Bug 155974). There is a nasty combination with VTK5, OpenCascade, GCC3 vs. GCC4 and Salome 3.2. To use the flags was removing some of the complains of Salome. > I would recommend to switch to the patches way. I'm currently using this option > succesfully with 64 bits. Flags or patches. The problem is how the applications are built afterwards. Which GCC do you use? 3 or 4? > I also would like to ask if there is a way apart from downloading the file and > making it a local. I mean an overlay or whatever. Thank you! I never really investigate the issue. I saw that you did. Thanks! Please mention my name in the Changelog. I have been working like a beast to get that far... ;) Daniel
> Yes, as nobody answered me, I decided to take the next step, make some > modifications (adding some USE flags for java wrapping, the DRAW test harness > and WOK which would save time for people not needing them). I've also changed > some things that could lead to problems in non-standard directory structures. > The other thing is that I switched back to the patch version, it is far better. > > I've been talking to the guys in Sunrise overlay and after testing it under > amd64 and x86 I'll post them both in here and the overlay. > > I didn't know you could download them from there. I'll make the changes and > test it. If you put the modified ebuild here, I will test it as well. I have access to x86 and amd64 with gcc3 and gcc4. Daniel
Hello, > I don't know if the ebuild was working for you, but I'm making huge changes to > have it working. Is it working for you? The ebuild were working for me. Of course... > Well, anyway I'm already working on the changes, is just that each trial takes > 4 hours. I know, a real pain... > There are problems with: > > - Placement of files What do you mean with that? The problem is not where the files are stored, the problem is to get the applications (Salome for instance) find them. There is this CASROOT variable which the root for the whole package. Applications (like salome) expect to find this variable and use it... > - Environment variables Yes indeed. If you move things around, then you get into troubles with that. Did you notice the file put in /etc/env.d? > - File permissions (you can't even see what's inside) ????? Never seen any problem with that. > - distclean is not working, and you don't need to do it. After merging, > everything is gone. Exactly... > - 64-32 bits problems with directories One again, everything was stored in /usr/opencascade. That was the CASROOT. So, by moving things around you, I suppose you get the kind of problem you mentionned. > - It is a nice improvement to set some more USE flags: WOK and DRAW are big > parts and it saves time and space if you don't plan to use it. I was seen them, as good test bed (not having any application using OpenCascade to confirm the 'liability' of the library). But that's fine. You're right. > I'm almost done, and I'll post it here and then move it to the overlays. I am curious indeed. And don't forget to mention my name to the guys... ;) Daniel
Your idea comes from a good point. However, gentoo's ebuild system would hardly be happy with launching the graphical interface and uncompressing everything following instructions (with the risk of failing). At least while the FreeBSD extracted sources are there, we should use them... If not, we should find an alternative or ask an experienced gentoo portage maintainer. (In reply to comment #81) > Thank you for that ebuild! But how you get the sources is not very nice. What > is against that way, which is provided in the FreeBSD Makefile: > http://www.freebsd.org/cgi/cvsweb.cgi/ports/cad/opencascade/Makefile?rev=1.5 ? > When everybody can download the sources from > http://files.opencascade.com/OCC_6.2_release/OpenCASCADE_Linux.tgz it is more > probably that they will stay there, instead on the FreeBSD ftp Servers. And > then you can extract the tarball as it is described in the FreeBSD Makefile. > Nevertheless, have you done a great job. But please make it available through > an overlay, for example sunrise or science. >
Hello Daniel, Thanks for your response. It is very good that you answer so I can ask you what I was thinking... In fact, I've remade the ebuild from scratch, of course using some parts that you did (for example the nice sed filtering for the environment variables). So, do you think that the new ebuild should be a r3 or a newly posted ebuild? Now the "package" includes: -ebuild -gcc4 patch (applied only if gcc4.x is in use) -malloc problem patch (I've done this to solve a nasty message from gentoo saying it has poor programming standard) -environment variables template file (which I use to feed cleanly and easily the environment's variables) In my opinion we should create a new bug, but of course, we make a ChangeLog saying that we made the ebuild together (I've really used parts of your work and without it wouldn't be possible). A good reason for this is that they are a bit different approaches, with different files and so on. There are still things to do for the overlay, like the specific USE flags and the special license. I'll manage. Please, let me know. Best regards, .alvaro.castro.
Hi Alvaro (and Daniel), First, thanks for all the effort, OCC is a monster package! Daniel has done a massive amount of work on OCC to make a usable ebuild. I think Daniel would agree that most of the work isn't directly in the ebuild file itself, but in figuring out how the OCC installer does things and converting that into something a little more like a standard Unix build (all those magic sed lines), and making portage do that automatically. It sounds like you're using that knowledge. I'd like to see your ebuild here. If you open a new bug, development is split, which seems like a bit of wasted effort. It'd be really neat if you and Daniel could combine your efforts - I know Daniel has been asking for help for a long time (sorry, still no spare time here!). Firstly, could you post your malloc patch, that sounds useful and like something Daniel/you may be able to incorporate directly into the existing ebuild. Second, how different is your ebuild? I don't know the Gentoo procedure for managing two ebuilds for the same package. Certainly post it in some form here. Is it possible to write your changes as a set of modifications to the original ebuild, rather than a completely new file? As for overlays, I don't think you need to change the ebuild itself? Or do some overlays have their own USE flags or environment variables? Thanks again both for your effort, Arthur
Hello again, I'm glad that we are all interested in having this working! :-D I'll post the ebuild and the patches here. I deeply agree that Daniel's work is great and has been hard, and expect to find bugs everywhere in my own ebuild. I know is a hard work making this library work properly, as I spent days not knowing that there were people working on it somewhere (nobody helped in the occ forum). I managed to discover that it could be solved with the fpermissive and the fframe-injection flags after diving in gcc's manual... As I started it over again, and maybe is not clearly a revision, I would like to respect your work, that's the reason I was proposing a different ebuild, so you could keep the /usr structure and not applying patches. I copied some of the sed lines, comments and pasted the standard configure rebuild procedure, but decided to do somethings different and place things in /opt as usually are in Gentoo... Of course, I place it here under the r3 name. Help me with the ChangeLog, please! :-) The malloc patch just adds an include in a lost file, easy thing. Other thing I was thinking of is adding qt4 support and trying to compile also java and/or qt3 examples. (I'll send it tonight at home, after checking there are no terrible problems with the latest changes)- sorry for it. I hope we can make this a nicely working ebuild, because the library is very interesting but painful. When uplodaded, please check it and try it on your gcc3 /x86 computers, as I dind't enough. Tell me also any improvable thing or terrible mistake that I haven't realized.
I'm just doing the last test. But, I would like to know Daniel's opinion. Do you want me to put the ebuild here, open a new bug or see it first?
Hello Alvaro, So much activity all of a sudden on this bug report. This is great! ;) So here are a few comments of mine to the points raised by you and Arthur: > In fact, I've remade the ebuild from scratch, of course using some parts that > you did (for example the nice sed filtering for the environment variables). > > So, do you think that the new ebuild should be a r3 or a newly posted ebuild? r3 sounds good to me. It's an evolution / rebuild of what has been done so far. I think it should stay on this bug report, by doing so, we preserve 'our public'... ;) > Now the "package" includes: > -ebuild > -gcc4 patch (applied only if gcc4.x is in use) > -malloc problem patch (I've done this to solve a nasty message from gentoo > saying it has poor programming standard) > -environment variables template file (which I use to feed cleanly and easily > the environment's variables) That sounds good to me. I will try things out (especially with respect to Salome (or what can be done with Salome. Salome needs VTK4 which is not anymore in portage (replaced by VTK5)). > In my opinion we should create a new bug, but of course, we make a ChangeLog > saying that we made the ebuild together (I've really used parts of your work > and without it wouldn't be possible). I think we should keep the old bug. It's easier. > A good reason for this is that they are a bit different approaches, with > different files and so on. Well, one philosophy can replace an other. My goal was to have a running OpenCascade to start the work on Salome. I was very aware all the way that what I was proposing was a temporary solution. You seem to focus on something much more mature and 'gentoo orthodox'. That's the next step and that's a good step! ;) > There are still things to do for the overlay, like the specific USE flags and > the special license. I'll manage. Good! ;) Daniel
Hi Arthur, Nice to hear from you again. > First, thanks for all the effort, OCC is a monster package! You haven't seen Salome... ;) > Daniel has done a massive amount of work on OCC to make a usable ebuild. I > think Daniel would agree that most of the work isn't directly in the ebuild > file itself, but in figuring out how the OCC installer does things and > converting that into something a little more like a standard Unix build (all > those magic sed lines), and making portage do that automatically. It sounds > like you're using that knowledge. I agree with Arthur comment. As a matter of fact, I just scratched the surface (I simply put everything in /usr/opencascade). This was not optimum (far from that) but it was simple and fullfilled my need... > I'd like to see your ebuild here. If you open a new bug, development is split, > which seems like a bit of wasted effort. It'd be really neat if you and Daniel > could combine your efforts - I know Daniel has been asking for help for a long > time (sorry, still no spare time here!). No problem. I will help (I can test the beasts on my machines and with the ebuild I made for NetGen (requires OCC) and Salome). I agree with Arthur. Let's keep one central point for discussion and patches / ebuild. > Firstly, could you post your malloc patch, that sounds useful and like > something Daniel/you may be able to incorporate directly into the existing > ebuild. > > Second, how different is your ebuild? I don't know the Gentoo procedure for > managing two ebuilds for the same package. Certainly post it in some form here. My ebuilds have never been included in the official portage or any overlay. The important thing is to have something useful and solid, whatever the historic of the process... ;) > Is it possible to write your changes as a set of modifications to the original > ebuild, rather than a completely new file? A diff? > As for overlays, I don't think you need to change the ebuild itself? Or do some > overlays have their own USE flags or environment variables? The ebuild I proposed were working here. Alvaro mentionned some issues with them that surprised me. > Thanks again both for your effort, You're welcome! Daniel
Alvaro, > I'm glad that we are all interested in having this working! :-D > > I'll post the ebuild and the patches here. Thanks! ;) > I deeply agree that Daniel's work is great and has been hard, and expect to > find bugs everywhere in my own ebuild. I know is a hard work making this > library work properly, as I spent days not knowing that there were people > working on it somewhere (nobody helped in the occ forum). I managed to discover > that it could be solved with the fpermissive and the fframe-injection flags > after diving in gcc's manual... The information was on the salome forum, if I remember correctly. It took me a while to find out as well... > As I started it over again, and maybe is not clearly a revision, I would like > to respect your work, that's the reason I was proposing a different ebuild, so > you could keep the /usr structure and not applying patches. Patches or flags, /usr or /opt. These are the questions I have had in my mind for quite a while. What is the best way? What is the best place? Regarding /usr vs. /opt, I wrote somewhere in this thread, about a year ago, that this was the kind of decision I would leave to the gentoo maintainers. I have no particular feelings regarding one option vs. the other. I suppose the gentoo men have clearer idea on the question than I do... I was just willing to have something working, somewhere... ;) Patches vs. flags. This is coupled to the way the application ebuild would be built. There I have some experience: - I started with the patches, then I discovered the patches, then I commuted between the two solutions.... - The problem is with Salome. The Salome-GUI had some issues with the patches (if I remember correctly). Well, Salome is for gcc3 and VTK4, so, there are quite a lot of problems... :( > I copied some of the sed lines, comments and pasted the standard configure > rebuild procedure, but decided to do somethings different and place things in > /opt as usually are in Gentoo... Fine by me! > Of course, I place it here under the r3 name. Help me with the ChangeLog, > please! :-) Well, just modify the existing one and put it back here. That's what I did. That's the one that can be proposed to the overlay as well. > The malloc patch just adds an include in a lost file, easy thing. > > Other thing I was thinking of is adding qt4 support and trying to compile also > java and/or qt3 examples. I think I had 'forgotten' these things... Thanks for doing the job. > (I'll send it tonight at home, after checking there are no terrible problems > with the latest changes)- sorry for it. No problem. Thanks for the effort. > I hope we can make this a nicely working ebuild, because the library is very > interesting but painful. When uplodaded, please check it and try it on your > gcc3 /x86 computers, as I dind't enough. Tell me also any improvable thing or > terrible mistake that I haven't realized. I can test it on gcc3.4/x86, gcc4.1/x86 and gcc3.4/amd64. That covers almost the whole panel... ;) Daniel
Created attachment 134268 [details] Rebuilt from scratch taking code from R2
Created attachment 134269 [details] Environment variables template file
Created attachment 134270 [details, diff] Gcc4.x patch for Opencascade (thanks to Jason Kraftcheck)
Created attachment 134271 [details, diff] Malloc patch avoiding portage complaining about code quality Straightforward solution: adding stdlib.h include in the affected file.
Sorry for the delay... It was much more than planned, part because of a bug, part because I didn't have time even for sending the files! Please, test it and submit any question or improvement. There are things remaining: * Samples compilation * Wok environment variables * Bugs or terrible things I haven't realized after 20 or more rebuilds. Also, I have to say that you did right with make distclean, because if you make a plain copy you get the intermediate objects, which fills the hard drive. On the other hand, it would be more "orthodox" to put everything in the system's "lib" and "include" folders. I decided to leave it as you have done before because this way everything can be rebuilt from scratch by the enduser in case something wants to be tweaked. This is also better for keeping the cpp, but that's what a Gentoo developer should say. Thanks
Hi Alvaro, Thanks for the files! I'm still digesting the differences, but here's my first question. In the file "env.ksh.template" you have: if [ -z "PATH" ]; then PATH=VAR_CASROOT/Linux/bin; else PATH=VAR_CASROOT/Linux/bin:$PATH; fi export PATH if [ -z "LD_LIBRARY_PATH" ]; then LD_LIBRARY_PATH=VAR_CASROOT/Linux/lib; else LD_LIBRARY_PATH=VAR_CASROOT/Linux/lib:$LD_LIBRARY_PATH; fi which inserts the new path on the front of the $PATH variable. Is this the normal order, or should it go on the back instead? I like to keep /usr/bin at the front of my path. One minor buglet. In the ebuild you have if use opengl && use !X ; then ewarn "OpenGL imply X support! Add "opengl" USE flag." die fi I think you meant "Add "X" USE flag." ;-) Thanks for the hard work, I'll test in now. Arthur
Hi Daniel, I tried building 6.2-r2 (x86) and all looked well, but I've just noticed the environment variables aren't expanding properly. I now have the following: $ printenv | grep CSF CSF_XmlOcafResource=CASROOT/src/XmlOcafResource CSF_StandardDefaults=CASROOT/src/StdResource CSF_XSMessage=CASROOT/src/XSMessage CSF_StandardLiteDefaults=CASROOT/src/StdResource CSF_MDTVFontDirectory=CASROOT/src/FontMFT CSF_UnitsDefinition=CASROOT/src/UnitsAPI/Units.dat CSF_STEPDefaults=CASROOT/src/XSTEPResource CSF_IGESDefaults=CASROOT/src/XSTEPResource CSF_GraphicShr=CASROOT/$OS_NAME/lib/libTKOpenGl.so CSF_EXCEPTION_PROMPT=1 CSF_PluginDefaults=CASROOT/src/StdResource CSF_LANGUAGE=us CSF_UnitsLexicon=CASROOT/src/UnitsAPI/Lexi_Expr.dat CSF_XCAFDefaults=CASROOT/src/StdResource CSF_MDTVTexturesDirectory=CASROOT/src/Textures CSF_SHMessage=CASROOT/src/SHMessage i.e. CASROOT hasn't expanded. I'm not sure if this is a new problem, I've only just noticed it. I'm sure there is a trick for making variables substitute in env.d scripts, but I can't remember what it is. Arthur
The official answer appears to be 'no variable expansion in env.d scripts' - see the forums here: http://forums.gentoo.org/viewtopic-p-4418171.html#4418171 Looks like more seds in the ebuild...
(In reply to comment #100) > Hi Alvaro, > > Thanks for the files! I'm still digesting the differences, but here's my first > question. In the file "env.ksh.template" you have: > > if [ -z "PATH" ]; > then PATH=VAR_CASROOT/Linux/bin; > else PATH=VAR_CASROOT/Linux/bin:$PATH; > fi > export PATH > if [ -z "LD_LIBRARY_PATH" ]; > then LD_LIBRARY_PATH=VAR_CASROOT/Linux/lib; > else LD_LIBRARY_PATH=VAR_CASROOT/Linux/lib:$LD_LIBRARY_PATH; > fi > > which inserts the new path on the front of the $PATH variable. Is this the > normal order, or should it go on the back instead? I like to keep /usr/bin at > the front of my path. > > One minor buglet. In the ebuild you have > > if use opengl && use !X ; then > ewarn "OpenGL imply X support! Add "opengl" USE flag." > die > fi > > I think you meant "Add "X" USE flag." ;-) > > Thanks for the hard work, I'll test in now. > > Arthur > Yes, you are right. For a next release, we should place it at the end. It had a reason before, as it was linking against the libraries included in the package during compilation. It always links against first version, even if it fails. But now, we use Gentoo's versions, so it shouldn't be that way. The comment should be changed, sure. We should make a list of improvements, after your impressions using the ebuilds.
(In reply to comment #102) > The official answer appears to be 'no variable expansion in env.d scripts' - > see the forums here: > > http://forums.gentoo.org/viewtopic-p-4418171.html#4418171 > > Looks like more seds in the ebuild... > yes, it looks like the env.d files are not script, but processed by a script, so they only accept strings.
Hello Alvaro, I took a look and started to test your ebuild. Here are my very first comments (gcc 3.4.6, x86): - I like it, it's more structured than the one I had proposed. - By changing the slot number between -r2 and -r3, one has to be aware that opencascade-6.2-r2 has to be removed 'by hand' (emerge -C) - The qt3 test does not work so well, you specify =qt-3.3.8, I have qt-3.3.8-r4 on my machine... We should somehow specify qt>=3, qt<4 but I don't know how to do that. - fltk is gone? I don't remember why I put it, it might have been a requirement I found on the webpage, somewhere or in the configure options - I have checked in details how you manage the env.ksh file. I suppose you did create it carefully, however the 50opencascade file has a problem: itk, tk, itcl, tcl and tix belong to particular directories in /usr/lib (here I have /usr/lib/itk3.3, not /usr/lib/itk, for instance) - after the distclean I had done an 'econf'. You did not. I don't remember why I did it or even if it was really necessary. I suppose I needed to get some Makefiles right again. - I had an 'examples' flag (as many other gentoo packages), you don't. - It seems to build fine. I will need to rework my netgen ebuild (also on bugs.gentoo) to see if it works fine. Now I will try to build it on amd64 and gcc4 machines. I keep you in informed. Daniel
(In reply to comment #105) > Hello Alvaro, > > I took a look and started to test your ebuild. Here are my very first comments > (gcc 3.4.6, x86): > - I like it, it's more structured than the one I had proposed. > - By changing the slot number between -r2 and -r3, one has to be aware that > opencascade-6.2-r2 has to be removed 'by hand' (emerge -C) > - The qt3 test does not work so well, you specify =qt-3.3.8, I have qt-3.3.8-r4 > on my machine... We should somehow specify qt>=3, qt<4 but I don't know how to > do that. > - fltk is gone? I don't remember why I put it, it might have been a requirement > I found on the webpage, somewhere or in the configure options > - I have checked in details how you manage the env.ksh file. I suppose you did > create it carefully, however the 50opencascade file has a problem: itk, tk, > itcl, tcl and tix belong to particular directories in /usr/lib (here I have > /usr/lib/itk3.3, not /usr/lib/itk, for instance) > - after the distclean I had done an 'econf'. You did not. I don't remember why > I did it or even if it was really necessary. I suppose I needed to get some > Makefiles right again. > - I had an 'examples' flag (as many other gentoo packages), you don't. > > - It seems to build fine. I will need to rework my netgen ebuild (also on > bugs.gentoo) to see if it works fine. > > Now I will try to build it on amd64 and gcc4 machines. I keep you in informed. > > Daniel > Daniel, thanks for your reponse. I answer you point by point: - Yes, it's true, but is there any reason to choose the slot number 6, instead of 0? Normally packages should use 0. Otherwise it seems that there are 6 other slottable versions... Just asking, anyway. - Isn't that say "the latest of the 3.3.8"? Because Trolltech is not releasing any new version, these are just ebuild releases. Does it try to download withouth the rX? - There is no fltk support in examples or anywhere. I didn't know where it is used, so I didn't place it. I didn't write things I couldn't understand. So if you know, please add it! :-) - Sure, is a bug. The variables are local, so they must be created also in the installation part. For such purpose I used a variation of your sed lines. we only have o copy what is in the previous section when creating the 50opencascade file. - Yes, you needed the config.h for the HAVE_CONFIG flag of opencascade. I realized afterwards. Emake clean solves that issue, instead of distclean. - Yes, I chose to do it in such a way that samples don't come all together, but depending on the flags qt3 and java. So if you compile java, you get its samples, if you want qt3, you get its samples. Then you don't end up with samples that you cannot support. And samples are very few and their size small relative to the package so it is not a big deal to have them even if you don't want them, on the other hand. ok, then there are a few improvements to do... :-D thanks!
I think I solved the qt3 issue and the 50opencascade file issue. I upload it after (re)compiling the stuff.
I just realized that the slot was 1, so I changed it to 0. That means is not slottable.
Created attachment 135676 [details] OpenCascade 6.2 release 4 Bugfixes
Alvaro, Opencascade does not work anymore with netgen (http://bugs.gentoo.org/show_bug.cgi?id=155424) When I created the OpenCascade ebuild, I used netgen as a 'testbed' application. I created an ebuild for netgen and apparently the two were working together flawlessly. Now the Opencascade ebuild is a bit different and the netgen ebuild has also been slightly modified and the link between netgen and opencascade is broken.... :( Try the netgen ebuild and see for yourself, it complains a lot about opencascade. Daniel
Hello again, false alarm, my CASROOT was wrong... Sorry about that... Daniel
(In reply to comment #111) > Hello again, > > false alarm, my CASROOT was wrong... Sorry about that... > > Daniel However, I do have the following error message: $ ng ng: error while loading shared libraries: libTKIGES.so.0: cannot open shared object file: No such file or directory where locate gives me: $ locate libTKIGES.so.0 /opt/opencascade-6.2/ros/lin/lib/libTKIGES.so.0 /opt/opencascade-6.2/ros/lin/lib/libTKIGES.so.0.0.0 How can it be so? It did not happen previously. It seems that somehow the LDPATH is not the way it is supposed to be. Daiel
Alvaro, I found the source of the problem with the LDPATH. It's a bug in the 50opencascde file. In my version (that worked) it contained: LDPATH=/usr/opencascade-6.2/ros/Linux/lib/ In yours, it contains: LDPATH=/opt/opencascade-6.2/ros/Linux/ the lib/ at the end is missing... Can you correct that in the ebuild? Thanks in advance Daniel
Hi Daniel! LD_LIBRARY_PATH=VAR_CASROOT/Linux/lib; appears in the env.ksh.template file, and actually I have that path working properly as you say with the /lib part... The ebuild is not modifying that part, just the VAR_CASROOT string. Please, check that you have exactly the same files, and if so, please, post me the resulting 50opencascade. I have to figure out how to emulate your problem. (In reply to comment #113) > Alvaro, > > I found the source of the problem with the LDPATH. It's a bug in the > 50opencascde file. > In my version (that worked) it contained: > LDPATH=/usr/opencascade-6.2/ros/Linux/lib/ > In yours, it contains: > LDPATH=/opt/opencascade-6.2/ros/Linux/ > the lib/ at the end is missing... > > Can you correct that in the ebuild? > > Thanks in advance > > Daniel >
Hello Alvaro, I checked the file. I am using the latest version of the ebuild and patches. To be sure I uninstalled opencascade and rebuilt it and I get the following: $ less 50opencascade CASROOT=/opt/opencascade-6.2/ros PATH=/opt/opencascade-6.2/ros/Linux/bin/ LDPATH=/opt/opencascade-6.2/ros/Linux/ CSF_MDTVFontDirectory=/opt/opencascade-6.2/ros/src/FontMFT CSF_LANGUAGE=us MMGT_CLEAR=1 CSF_EXCEPTION_PROMPT=1 CSF_SHMessage=/opt/opencascade-6.2/ros/src/SHMessage CSF_MDTVTexturesDirectory=/opt/opencascade-6.2/ros/src/Textures CSF_XSMessage=/opt/opencascade-6.2/ros/src/XSMessage CSF_StandardDefaults=/opt/opencascade-6.2/ros/src/StdResource CSF_PluginDefaults=/opt/opencascade-6.2/ros/src/StdResource CSF_XCAFDefaults=/opt/opencascade-6.2/ros/src/StdResource CSF_StandardLiteDefaults=/opt/opencascade-6.2/ros/src/StdResource CSF_GraphicShr=/opt/opencascade-6.2/ros/Linux/lib/libTKOpenGl.so CSF_UnitsLexicon=/opt/opencascade-6.2/ros/src/UnitsAPI/Lexi_Expr.dat CSF_UnitsDefinition=/opt/opencascade-6.2/ros/src/UnitsAPI/Units.dat CSF_IGESDefaults=/opt/opencascade-6.2/ros/src/XSTEPResource CSF_STEPDefaults=/opt/opencascade-6.2/ros/src/XSTEPResource CSF_XmlOcafResource=/opt/opencascade-6.2/ros/src/XmlOcafResource TCLHOME=/usr/bin TCLLIBPATH=/usr/lib ITK_LIBRARY=/usr/lib/itk3.3 ITCL_LIBRARY=/usr/lib/itcl3.3 TIX_LIBRARY=/usr/lib/tix8.2 TK_LIBRARY=/usr/lib/tk8.4 TCL_LIBRARY=/usr/lib/tcl8.4 As you can see, the lib is missing. I suspect some problem with one the sed somewhere... Daniel > Hi Daniel! > > LD_LIBRARY_PATH=VAR_CASROOT/Linux/lib; > > appears in the env.ksh.template file, and actually I have that path working > properly as you say with the /lib part... The ebuild is not modifying that > part, just the VAR_CASROOT string. Please, check that you have exactly the same > files, and if so, please, post me the resulting 50opencascade. I have to figure > out how to emulate your problem. >
Alvaro, Another question. Why is a dependency on qt3 needed in the new ebuild? It was not there in the previous one and I do not have the feeling that opencascade needs qt3. Daniel
(In reply to comment #116) > Alvaro, > > Another question. Why is a dependency on qt3 needed in the new ebuild? It was > not there in the previous one and I do not have the feeling that opencascade > needs qt3. > > Daniel > The Qt3 is used for the examples, if you want to build qt3 applications. About the LD_PATH, I can't see a quick fix for it (I don't know the origin of the problem). Actually, the variable that should appear is LD_LIBRARY_PATH, as you can see from the template. I have it working with the LD_LIBRARY_PATH set to the lib path and no LD_PATH at all. However, I think I know the problem. I was using ${get_libdir} for taking care of both 32 and 64 bits version which store in lib and lib64 respectively. However, later on I make a symlink to lib from lib64 in 64 bits platforms. Then a static "/lib" directory should work in all cases.
Created attachment 137800 [details] path problem in 50opencascade
Hi ! I've a suggestion for the opencascade ebuild. As it take a long time to compile, I think it will be a good idea to suggest a minimum required free space on the disk with a warning. I tried to compile it with 3Go of free space and it didn't work, and I lost 29 hours of compilation ! But the installation worked with 3,5Go. It's just a suggestion and I know there is a similar thing for the openoffice ebuild. François
Created attachment 140966 [details] OpenCascade-6.2-r5. Included Francois' suggestion I slightly modified the ebuild to check that the system where OpenCascade is built has: - At least 256Mb RAM - A least 3.5Gb HD to build OpenCascade Daniel
Hi, I committed this package to the science overlay as is, just to simplify user's installation. Warning: I have not tested it. However, if you are interested in improving the package here are many comments to the current ebuild. I'll be OK in committing any improvements made here to the overlay repository, may be to the main tree later on. - The ebuild is in general pretty hard to read. I think it could benefit in a reduction of sed commands, line breakings, and possibly introduction of some local functions. It does some overly complex stuff. - what's the story with the source file? are we dependent on how freebsd package it? is there really no way to produce one with some proper java dependencies, or produce one ourselves? - bad LICENSE (spaces) - fix dependency on x11 modular: x11-base/xorg-x11 is not good anymore. - isn't tix only required for testing? If so, a test use flag could be useful. - use doenvd - DEPEND: some packages are already in the system set, so you don't need to put them. See in profiles/base/packages for a start - RDEPEND: default to DEPEND, please check - put all the eauto* stuff from src_compile into src_unpack and use eautoreconf if possible - use as much as you can the use_enable and use_with functions instead of the buggy "use !<flag>" ones - instead of using a tons of sed, why not using cat<<-EOF and produce the env file on the fly? - use bash instead of csh/ksh as much as possible. - use more die functions ... Thanks for your work!
I've checked out the automatic extraction of the source files from the shipped jar file: http://files.opencascade.com/OCC_6.2_release/OpenCASCADE_Linux.tgz Like the way it is done in the FreeBSD Port of OpenCascade (http://www.freebsd.org/cgi/cvsweb.cgi/ports/cad/opencascade/Makefile?rev=1.6): unpack OpenCASCADE_Linux.tgz rm ~/vpd.properties mkdir ${WORKDIR}/tmp java -cp ./Linux/setup.jar -console -DOS_NAME=Linux -Dtemp.dir=${WORKDIR}/tmp run But unfortunately, you need an X-Server running for startup this GUI. And it needs additional user input. So this is a NO-GO, for an automatic emerge installation. Even the mentioned Salome packages http://files.opencascade.com/Salome3.2.6/src3.2.6.tar.gz (~80MB) or http://files.opencascade.com/Salome3.2.6/InstallWizard_3.2.6_DebianSarge.tar.gz (~500MB) doesn't contain opencascade sources anymore (I haven't seen one). Maybe the RedHat or Mandrake package contain it, but I can't believe it. So I think at the moment, the FreeBSD package sources, are the only possibility. Nevertheless, Thanks to that ebuild!
(In reply to comment #122) > I've checked out the automatic extraction of the source files from the shipped > jar file: http://files.opencascade.com/OCC_6.2_release/OpenCASCADE_Linux.tgz > > Like the way it is done in the FreeBSD Port of OpenCascade > (http://www.freebsd.org/cgi/cvsweb.cgi/ports/cad/opencascade/Makefile?rev=1.6): > > unpack OpenCASCADE_Linux.tgz > rm ~/vpd.properties > mkdir ${WORKDIR}/tmp > java -cp ./Linux/setup.jar -console -DOS_NAME=Linux -Dtemp.dir=${WORKDIR}/tmp > run > > But unfortunately, you need an X-Server running for startup this GUI. And it > needs additional user input. So this is a NO-GO, for an automatic emerge > installation. > > Even the mentioned Salome packages > http://files.opencascade.com/Salome3.2.6/src3.2.6.tar.gz (~80MB) or > http://files.opencascade.com/Salome3.2.6/InstallWizard_3.2.6_DebianSarge.tar.gz > (~500MB) doesn't contain opencascade sources anymore (I haven't seen one). > Maybe the RedHat or Mandrake package contain it, but I can't believe it. > > So I think at the moment, the FreeBSD package sources, are the only > possibility. Nevertheless, Thanks to that ebuild! > Yes, I actually tried that other ways some time ago. I'm sorry I cannot continue working on this ebuild, since I don't have time for it at this moment. It could be great to make Sebastien suggestions, however...
Hopefully someone can help me on this. When I try to build opencascade, I get the following error: checking for _XEditResCheckMessages in -lXmu... no configure: error: the /usr/lib directory given by --with-xmu-library does not contains xmu library Even when I change the ./configure line to look in /usr/lib64 (using $(get_libdir), I get the same error: checking for _XEditResCheckMessages in -lXmu... no configure: error: the /usr/lib64 directory given by --with-xmu-library does not contains xmu library Note that I do, however, have the library, and it functions correctly: # grep _XEditResCheckMessages /usr/lib64/libXmu* Binary file /usr/lib64/libXmu.a matches Binary file /usr/lib64/libXmu.so matches Binary file /usr/lib64/libXmu.so.6 matches Binary file /usr/lib64/libXmu.so.6.2.0 matches # emerge --info * Overlay eclass overrides eclass from PORTDIR: * * '/usr/portage/local/layman/science/eclass/fortran.eclass' * * It is best to avoid overridding eclasses from PORTDIR because it will * trigger invalidation of cached ebuild metadata that is distributed with * the portage tree. If you must override eclasses from PORTDIR then you * are advised to run `emerge --regen` after each time that you run `emerge * --sync`. Set PORTAGE_ECLASS_WARNING_ENABLE="0" in /etc/make.conf if you * would like to disable this warning. Portage 2.1.4.1 (default-linux/amd64/2007.0, gcc-4.2.2, glibc-2.7-r1, 2.6.16.54-0.2.3-xen x86_64) ================================================================= System uname: 2.6.16.54-0.2.3-xen x86_64 Intel(R) Xeon(R) CPU X5365 @ 3.00GHz Timestamp of tree: Wed, 06 Feb 2008 01:47:01 +0000 app-shells/bash: 3.2_p33 dev-java/java-config: 1.3.7, 2.1.4 dev-lang/python: 2.5.1-r5 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.24 ACCEPT_KEYWORDS="amd64 ~amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O3 -fomit-frame-pointer -funroll-loops -march=nocona -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/4.0/env /usr/kde/4.0/share/config /usr/kde/4.0/shutdown /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O3 -fomit-frame-pointer -funroll-loops -march=nocona -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="POSIX" MAKEOPTS="-j9" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/science /usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X accessibility acl alsa amd64 apache2 archive bcmath berkdb bitmap-fonts bluetooth bzip2 cairo calendar cli cracklib crypt ctype cups curl curlwrappers dbase dbus designer-plugin dri encode flac fortran ftp gd gdbm gif gpm gps gtk gtk2 hash iconv imagemagick imap inifile iodbc ipv6 isdnlog java jpeg ldap md5sum mdnsresponder-compat mhash midi mmx mono mssql mudflap mysql ncurses network networkmanager nls nptl nptlonly odbc ogg opengl openmp pam pcntl pcre pdf perl php png posix postgres ppds pppd python qt qt3 qt3support qt4 readline recode reflection ruby samba sdl session simplexml soap sockets spell spl sqlite sse sse2 ssl tcl tcpd threads tiff tk tokenizer truetype truetype-fonts type1-fonts unicode usb vnc vorbis xcomposite xml xmlreader xmlrpc xmlwriter xorg xscreensaver xvid zip zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="apm ark chips cirrus cyrix dummy fbdev glint i128 i810 mach64 mga neomagic nv r128 radeon rendition s3 s3virge savage siliconmotion sis sisusb tdfx tga trident tseng v4l vesa vga via vmware voodoo" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Additional build problem when I disable X and opengl flags: x86_64-pc-linux-gnu-g++ -O3 -fomit-frame-pointer -funroll-loops -march=nocona -pipe -m64 -DCSFDB -DOCC_CONVERT_SIGNALS -DLIN -DLININTEL -D_GNU_SOURCE=1 /var/tmp/portage/sci-misc/opencascade-6.2/work/opencascade-6.2/ros -DNDEBUG -DNo_Exception -O2 -o .libs/DRAWEXE DRAWEXE.o ../TKDraw/.libs/libTKDraw.so /var/tmp/portage/sci-misc/opencascade-6.2/work/opencascade-6.2/ros/adm/make/TKMesh/.libs/libTKMesh.so /var/tmp/portage/sci-misc/opencascade-6.2/work/opencascade-6.2/ros/adm/make/TKHLR/.libs/libTKHLR.so -L/usr/lib64 ../TKMesh/.libs/libTKMesh.so ../TKGeomAlgo/.libs/libTKGeomAlgo.so ../TKTopAlgo/.libs/libTKTopAlgo.so ../TKHLR/.libs/libTKHLR.so /var/tmp/portage/sci-misc/opencascade-6.2/work/opencascade-6.2/ros/adm/make/TKTopAlgo/.libs/libTKTopAlgo.so /var/tmp/portage/sci-misc/opencascade-6.2/work/opencascade-6.2/ros/adm/make/TKGeomAlgo/.libs/libTKGeomAlgo.so /var/tmp/portage/sci-misc/opencascade-6.2/work/opencascade-6.2/ros/adm/make/TKBRep/.libs/libTKBRep.so ../TKGeomBase/.libs/libTKGeomBase.so ../TKG2d/.libs/libTKG2d.so ../TKBRep/.libs/libTKBRep.so /var/tmp/portage/sci-misc/opencascade-6.2/work/opencascade-6.2/ros/adm/make/TKGeomBase/.libs/libTKGeomBase.so /var/tmp/portage/sci-misc/opencascade-6.2/work/opencascade-6.2/ros/adm/make/TKG3d/.libs/libTKG3d.so ../TKMath/.libs/libTKMath.so ../TKG3d/.libs/libTKG3d.so /var/tmp/portage/sci-misc/opencascade-6.2/work/opencascade-6.2/ros/adm/make/TKG2d/.libs/libTKG2d.so /var/tmp/portage/sci-misc/opencascade-6.2/work/opencascade-6.2/ros/adm/make/TKMath/.libs/libTKMath.so /var/tmp/portage/sci-misc/opencascade-6.2/work/opencascade-6.2/ros/adm/make/TKernel/.libs/libTKernel.so ../TKernel/.libs/libTKernel.so -ltcl8.4 -ltk8.4 -ldl -lpthread -lieee -lm -Wl,--rpath -Wl,/opt/opencascade-6.2/ros/lin/lib64 /var/tmp/portage/sci-misc/opencascade-6.2/work/opencascade-6.2/ros: file not recognized: Is a directory collect2: ld returned 1 exit status make[3]: *** [DRAWEXE] Error 1 make[3]: Leaving directory `/var/tmp/portage/sci-misc/opencascade-6.2/work/opencascade-6.2/ros/adm/make/DRAWEXE' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/sci-misc/opencascade-6.2/work/opencascade-6.2/ros/adm/make' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/sci-misc/opencascade-6.2/work/opencascade-6.2/ros' make: *** [all] Error 2
both issues were fixed by setting my java vm correctly.
(In reply to comment #121) Sebastien, I am implementing your suggestions. I have a few questions though: > However, if you are interested in > improving the package here are many comments to the current ebuild. I'll be OK > in committing any improvements made here to the overlay repository, may be to > the main tree later on. > > - The ebuild is in general pretty hard to read. I think it could benefit in a > reduction of sed commands, line breakings, and possibly introduction of some > local functions. It does some overly complex stuff. Things look a little bit better now... ;) > - what's the story with the source file? are we dependent on how freebsd > package it? is there really no way to produce one with some proper java > dependencies, or produce one ourselves? I see two options: It's a long story. To make it short, the java command to be used to get the source needs X and human interaction. Short term solution: Download it from FreeBSD Long term solution: Have it in Gentoo distfiles... ;) > - bad LICENSE (spaces) What do you mean? I did not understand your comment. > - fix dependency on x11 modular: x11-base/xorg-x11 is not good anymore. What am I supposed to use now? I checked in the portage directory and it's fairly confusing nowadays. > - isn't tix only required for testing? If so, a test use flag could be useful. To be checked indeed... Thanks for the tip. > - use doenvd > - DEPEND: some packages are already in the system set, so you don't need to put > them. See in profiles/base/packages for a start > - RDEPEND: default to DEPEND, please check This is a tricky one, this one... > - put all the eauto* stuff from src_compile into src_unpack and use eautoreconf > if possible > - use as much as you can the use_enable and use_with functions instead of the > buggy "use !<flag>" ones > - instead of using a tons of sed, why not using cat<<-EOF and produce the env > file on the fly? Because it's complicated... The sed solution is not as awful as it looks... ;) > - use bash instead of csh/ksh as much as possible. > - use more die functions I'll test the new ebuilds in the days to come. I post it ASAP. Daniel
(In reply to comment #118) Alvaro, I am in the process of implementing Sebastien comments into the ebuild. I have a few questions though: > - There is no fltk support in examples or anywhere. I didn't know where it is > used, so I didn't place it. I didn't write things I couldn't understand. So if > you know, please add it! :-) I will check this one once more... ;) What about Tix, when is it really used? Is it a test stuff? > I used a variation of your sed lines. we > only have o copy what is in the previous section when creating the > 50opencascade file. I was used to modify env.ksh _and_ env.csh. and preserve them in 'ros'. You only work with and preserve env.ksh. Any reason? Why don't you consider env.csh as well? Not everybody use bash. Pushing the reasoning a little bit further, do we need to keep env.ksh in 'ros' considering that we have 50opencascade in /etc/env.d. I am not so sure, as a matter of fact... ;) So, what's your opinion? Daniel
Sebastien, One last question: OpenCascade is primarily a library. I had chosen to put it under sci-libs. In the overlay you chose sci-misc. Any particular reason? It sounds odd to me. Daniel
Hi Daniel, > Long term solution: Have it in Gentoo distfiles... ;) It will when it hits the main tree, we can't do this in the overlay (I'm not sure though). Also, we have to be careful about re-distributing a copy with the license. > > - bad LICENSE (spaces) > > What do you mean? I did not understand your comment. See http://devmanual.gentoo.org/general-concepts/licenses/index.html Spaces in file names are not welcome ;-) > > - fix dependency on x11 modular: x11-base/xorg-x11 is not good anymore. > > What am I supposed to use now? I checked in the portage directory and it's > fairly confusing nowadays. Use the X11 libraries opencascade needs, such as libX11, libXmu etc...Actually since tk is a mandatory dep and it pulls X libs, it seems that you don't need X use flag. We have docs to migrate: http://www.gentoo.org/proj/en/desktop/x/x11/porting-modular-x-howto.xml Looking at the freebsd port, it seems you just need libXmu. > > - DEPEND: some packages are already in the system set, so you don't need to put > > them. See in profiles/base/packages for a start > > - RDEPEND: default to DEPEND, please check > > This is a tricky one, this one... It's just that the DEPEND has things like autoconf, which are not needed at run time. So you might want to define something like: CDEPEND=<common dependencies> DEPEND="${CDEPEND} <extra compile time deps>" RDEPEND="${CDEPEND} <extra run time deps>" > > - instead of using a tons of sed, why not using cat<<-EOF and produce the env > > file on the fly? > > Because it's complicated... The sed solution is not as awful as it looks... ;) Actually do we need all these variables and version checking? Don't the autotools scripts do this? > considering that we have 50opencascade in /etc/env.d. I am not so sure, as a > matter of fact... ;) You don't need to install the env.ksh with the env.d system. > OpenCascade is primarily a library. I had chosen to put it under sci-libs. In > the overlay you chose sci-misc. Any particular reason? It sounds odd to me. I've never really liked the sci-libs category which tends to bloat rapidly. But sci-misc is even worse, you're right. Will change on next ebuild update. Thanks
(In reply to comment #131) Hi Sebastien, > > > - bad LICENSE (spaces) > > > > What do you mean? I did not understand your comment. > > See http://devmanual.gentoo.org/general-concepts/licenses/index.html > Spaces in file names are not welcome ;-) OK. I got it. > > > - fix dependency on x11 modular: x11-base/xorg-x11 is not good anymore. > > > > What am I supposed to use now? I checked in the portage directory and it's > > fairly confusing nowadays. > > Use the X11 libraries opencascade needs, such as libX11, libXmu etc...Actually > since tk is a mandatory dep and it pulls X libs, it seems that you don't need X > use flag. We have docs to migrate: > http://www.gentoo.org/proj/en/desktop/x/x11/porting-modular-x-howto.xml > Looking at the freebsd port, it seems you just need libXmu. I choose libXmu but I did not really check. I will do that later on. Now I have an idea about what should be done. > Actually do we need all these variables and version checking? Don't the > autotools scripts do this? I need the version of tcl, tk, tix etc.. to replace old version in a file by the ones actually installed. Part of this sed magic is as a matter of fact a full hack. Let's take tcl as an example. On my system I have dev-lang/tcl-8.4.18 USE="-debug -threads" 0 kB therefor the only info I need is the '8.4' figure. However, how do I get it? What I do at the moment is that I check this figure on a file installed by tcl. Is there some portage magic that could help me? > > considering that we have 50opencascade in /etc/env.d. I am not so sure, as a > > matter of fact... ;) > > You don't need to install the env.ksh with the env.d system. I know. The env.ksh is needed during the compilation of opencascade. After that I use 50opencascade in /etc/env.d > > OpenCascade is primarily a library. I had chosen to put it under sci-libs. In > > the overlay you chose sci-misc. Any particular reason? It sounds odd to me. > > I've never really liked the sci-libs category which tends to bloat rapidly. But > sci-misc is even worse, you're right. Will change on next ebuild update. Perfect! Thanks. Daniel
Created attachment 146117 [details] Copy of the Open Cascade license. To be put under /usr/portage/licenses Can be found under: http://www.opencascade.org/occ/license/ Daniel
Created attachment 146160 [details] OpenCascade: A reworked ebuild Hello, This ebuild is based on the one produced by Alvaro. I took into account Sébastien's comments (as much as I could) and corrected a few bugs here and there. Among other things, the ebuild has been simplified and support of amd64 is better. A few major comments though: - Alvaro defined 'wok' and 'draw-harness' flags. The idea being to skip the build of these two applications at will. The problem is that it does not seem to work... Even without the flags on, I get DRAWEXE and woksh. Alvaro, any comment? - I need to have access to the version of tcl, tk, tix etc... The way I did that at the beginning of the ebuild is ugly _and_ against gentoo rules... I know that! What I do not know, is how to make it better... There is surely some portage magic that can give me the version number of any package, I simply don't know it. Any help welcome.... - I have not checked properly which part of Xorg I need. Apparently itäs libXmu. This needs to be checked though. - I have not separated yet DEPENDS from RDEPENDS. mea culpa... Any help is welcome - I still wonder how much of the OpenCascade source code needs to be preserved in the installed version. Any advice from a specialist of Cascade would be welcome... - There is more doc to be downloaded from the opencascade website and installed. I'll take care of that later on. So, Sébastien. Could you please replace the old ebuild on the overlay with this one (and if you could switch group from sci-misc to sci-libs as well, that would be kul...). It's not the final version but we are getting closer. This ebuild works with x86 and amd64, gcc-3.4 in both cases. Daniel
Created attachment 150729 [details] Corrected opencascade ebuild
Hi Dewald, > Created an attachment (id=150729) [edit] > Corrected opencascade ebuild What did you correct? Did you notice that I had reworked extensively the ebuild? The correction you brought are based on an old ebuild.... Unfortunately, the new ebuild has not been brought to the overlay (yet) Could you please check the new one and see if you can bring in your changes? Thanks! Daniel
Hi Daniel The ebuild in the overlay wasn't digesting or emerging because of a few spaces that were missing, I see your latest ebuild doesn't have that problem. The mistake was "java? (ftp:" instead of "java? ( ftp:" I probably should've checked the latest version on bugzilla but I thought my updated overlay was up to date. (In reply to comment #136) > What did you correct? > Could you please check the new one and see if you can bring in your changes? Dewald
Hi! OK. I see. I think you should remove the ebuild you put here, to avoid confusion with the new one... Daniel > The ebuild in the overlay wasn't digesting or emerging because of a few spaces > that were missing, I see your latest ebuild doesn't have that problem. > The mistake was "java? (ftp:" instead of "java? ( ftp:" > I probably should've checked the latest version on bugzilla but I thought my > updated overlay was up to date.
Created attachment 152837 [details] OpenCascade: A reworked ebuild A few changes: - Now it works correctly with the Salome OpenCascade detection on amd64 (Salome requires the libraries to be under lib, not lib64, therefore the link) - Removal of the draw and wok flags. They had not effect whatsoever. - Corrected minor details here and there (better sed, for instance) Daniel
The latest ebuild has been commited to the overlay. It is not a perfect/final one but I thought the changes were big enough to justify the commit. BTW, it is now in sci-libs, not sci-misc anymore (It is a library, by definition) Daniel
(In reply to comment #140) > The latest ebuild has been commited to the overlay. > It is not a perfect/final one but I thought the changes were big enough to > justify the commit. > > BTW, it is now in sci-libs, not sci-misc anymore (It is a library, by > definition) > > Daniel > Hi Daniel A niggle with the latest ebuild, the sed problem or something is beyond me: * QA Notice: 'sed' called in global scope: sci-libs/opencascade-6.2-r1 * QA Notice: 'grep' called in global scope: sci-libs/opencascade-6.2-r1 * QA Notice: 'sed' called in global scope: sci-libs/opencascade-6.2-r1 * QA Notice: 'grep' called in global scope: sci-libs/opencascade-6.2-r1 * QA Notice: 'sed' called in global scope: sci-libs/opencascade-6.2-r1 * QA Notice: 'grep' called in global scope: sci-libs/opencascade-6.2-r1 * QA Notice: 'sed' called in global scope: sci-libs/opencascade-6.2-r1 * QA Notice: 'grep' called in global scope: sci-libs/opencascade-6.2-r1 * QA Notice: 'sed' called in global scope: sci-libs/opencascade-6.2-r1 | !!! Invalid or corrupt dependency specification: missing space by parenthesis: 'u)' ('ebuild', '/', 'sci-libs/opencascade-6.2-r1', 'merge') java? ( virtual/jdk ) opengl? ( virtual/opengl virtual/glu) X? ( x11-libs/libXmu app-text/dgs ) >=dev-lang/tcl-8.4 >=dev-lang/tk-8.4 >=d ev-tcltk/itcl-3.2 >=dev-tcltk/itk-3.2 x86? ( >=dev-tcltk/tix-8.1 ) amd64? ( >=dev-tcltk/tix-8.4.2 ) qt3? ( x11-libs/qt:3 ) stlport? ( de v-libs/STLport ) =sys-devel/automake-1.10* >=sys-devel/autoconf-2.61 sys-devel/libtool This package can not be installed. Please notify the 'sci-libs/opencascade-6.2-r1' package maintainer about this problem. .. . done! Dewald
(In reply to comment #141) Hi Dewald, thanks for your comment. > (In reply to comment #140) > > The latest ebuild has been commited to the overlay. > > It is not a perfect/final one but I thought the changes were big enough to > > justify the commit. > > > > BTW, it is now in sci-libs, not sci-misc anymore (It is a library, by > > definition) > > > > Daniel > > > > Hi Daniel > > A niggle with the latest ebuild, the sed problem or something is beyond me: > > * QA Notice: 'sed' called in global scope: sci-libs/opencascade-6.2-r1 > * QA Notice: 'grep' called in global scope: sci-libs/opencascade-6.2-r1 > * QA Notice: 'sed' called in global scope: sci-libs/opencascade-6.2-r1 > * QA Notice: 'grep' called in global scope: sci-libs/opencascade-6.2-r1 > * QA Notice: 'sed' called in global scope: sci-libs/opencascade-6.2-r1 > * QA Notice: 'grep' called in global scope: sci-libs/opencascade-6.2-r1 > * QA Notice: 'sed' called in global scope: sci-libs/opencascade-6.2-r1 > * QA Notice: 'grep' called in global scope: sci-libs/opencascade-6.2-r1 > * QA Notice: 'sed' called in global scope: sci-libs/opencascade-6.2-r1 This one is easy to understand, I don't know how to solve it though: I need to determine the version number of tk, tcl etc.. globally, that is to say the info needs to be available at different stages of the ebuild. It seems that the syntax I use is not 100% portage orthodox... Any help there is welcome. | > > !!! Invalid or corrupt dependency specification: > > missing space by parenthesis: 'u)' > > ('ebuild', '/', 'sci-libs/opencascade-6.2-r1', 'merge') > > java? ( virtual/jdk ) opengl? ( virtual/opengl virtual/glu) X? ( > x11-libs/libXmu app-text/dgs ) >=dev-lang/tcl-8.4 >=dev-lang/tk-8.4 >=d > ev-tcltk/itcl-3.2 >=dev-tcltk/itk-3.2 x86? ( > >=dev-tcltk/tix-8.1 ) amd64? ( >=dev-tcltk/tix-8.4.2 ) qt3? ( x11-libs/qt:3 ) > stlport? ( de v-libs/STLport ) > =sys-devel/automake-1.10* >=sys-devel/autoconf-2.61 sys-devel/libtool > > This package can not be installed. Please notify the > 'sci-libs/opencascade-6.2-r1' package maintainer about this problem. This one is buffling me. I don't have it at all! The part that seems very strange to me is the following: > stlport? ( de v-libs/STLport ) Is it really like this in the ebuild file you have? with all the space? Daniel
> This one is easy to understand, I don't know how to solve it though: > I need to determine the version number of tk, tcl etc.. globally, that is to > say the info needs to be available at different stages of the ebuild. It seems > that the syntax I use is not 100% portage orthodox... > Any help there is welcome. > | To get the version number off something in portage use: equery list dev-lang/tcl | grep tcl | (some re filter to match just the ver number, my sed and re knowledge is forgotten at the moment.) Hope that helps Dewald
> To get the version number off something in portage use: > equery list dev-lang/tcl | grep tcl | (some re filter to match just the ver > number, my sed and re knowledge is forgotten at the moment.) equery list dev-lang/tck | grep tck | sed 's/[a-z]//g' | sed 's/[-]//g' With the appropriate sed and reg ex matching. Dewald
(In reply to comment #144) > > To get the version number off something in portage use: > > equery list dev-lang/tcl | grep tcl | (some re filter to match just the ver > > number, my sed and re knowledge is forgotten at the moment.) > > equery list dev-lang/tck | grep tck | sed 's/[a-z]//g' | sed 's/[-]//g' > > With the appropriate sed and reg ex matching. > > Dewald > The proper way to do this, after some local info sourcing: best_version <package> This function will look up package name in the database of currently installed programs and echo the "best version" of the package that is currently installed. Example: VERINS="$(best_version dev-lang/tck)"
Created attachment 153571 [details] New ebuild with version checking for the tcltk stuff.
Created attachment 153775 [details] Corrected version with version detection for the tcl stuff
(In reply to comment #147) > Created an attachment (id=153775) [edit] > Corrected version with version detection for the tcl stuff Hi Dewald, Thank you very much for your suggestion. It's indeed a way to solve the problem that I was not aware of. The problem was not much how I picked up the version of Tcl etc. it was more where I had put it in the ebuild. You showed me the solution to the problem... ;) I saw the light! :) What I have done so far is just to transfer my old sed stuffs to the pkg_setup section. I noticed indeed that some of the figures provided by your solutions were not exactly the ones needed, so I thought, let's give a final chance to the old method. If it generates problem, I replace it by Dewalds' Once again, thank you very much for taking the time to test the ebuild and report your issues, for participating to the common effort of getting a usuable ebuild for Gentoo. Best regards Daniel
Created attachment 153795 [details] New ebuild. It's already in the science overlay
(In reply to comment #148) > (In reply to comment #147) > > Created an attachment (id=153775) [edit] > > Corrected version with version detection for the tcl stuff > > Hi Dewald, > > Thank you very much for your suggestion. It's indeed a way to solve the problem > that I was not aware of. > The problem was not much how I picked up the version of Tcl etc. it was more > where I had put it in the ebuild. You showed me the solution to the problem... > ;) I saw the light! :) > What I have done so far is just to transfer my old sed stuffs to the pkg_setup > section. I noticed indeed that some of the figures provided by your solutions > were not exactly the ones needed, so I thought, let's give a final chance to > the old method. If it generates problem, I replace it by Dewalds' > > Once again, thank you very much for taking the time to test the ebuild and > report your issues, for participating to the common effort of getting a usuable > ebuild for Gentoo. > > Best regards > > Daniel > My pleasure Daniel, the way that I did it is based on built in functions available in the ebuild environment, see man -S 5 ebuild for the detailed info on best_version function, the bash magic is with the compliments of a friend of mine. I wasn't exactly sure what info you required, but I'm sure you'll be able to work it out. ebuild(5) provides some very good info. A test of an ebuild is always just a sync and an emerge away! Dewald
Created attachment 154379 [details] opencascade-6.2-r2.ebuild Hi, thanks for the new ebuild, I didn't know about the science overlay until recently I've just made a couple of changes to the ebuild to get it to work (i'm not sure if it's because I'm using amd64) the gcc4 patch is now applied (i had to use ">" instead of "-gt") also when using "use_with" within econf if a use flag was disabled it was putting "without-gl-include" instead of ommitting it which seemed to confuse the configure script and throw up an error (it was looking for a directory called "no") also I've removed --with-gl, --with-xmu, --enable-jcas as they don't seem to be used within the configure script just the options for directory paths "--with-gl-include" etc seem to be used
(In reply to comment #151) > Created an attachment (id=154379) [edit] > opencascade-6.2-r2.ebuild > > Hi, thanks for the new ebuild, I didn't know about the science overlay until > recently > I've just made a couple of changes to the ebuild to get it to work > (i'm not sure if it's because I'm using amd64) Hi Richard, I have tested the ebuild on two x86 boxes (gcc-3.4.6 and gcc-4.1.2) and on my amd64 box (gcc-3.4.6). It seems to work without any major issue. > the gcc4 patch is now applied (i had to use ">" instead of "-gt") OK. > also when using "use_with" within econf > if a use flag was disabled it was putting "without-gl-include" instead of > ommitting it That's the way use_with and use_enable are supposed to work. I was used to use the method you recommend but the gentoo guys warmly recommended me to use the use_with stuffs. > which seemed to confuse the configure script and throw up an error (it was > looking for a directory called "no") This is very very weird. Can you send me the complete error message? That's not the way things are supposed to happen. > also I've removed --with-gl, --with-xmu, --enable-jcas as they don't seem to be > used within the configure script I will check this once again. I think I had checked carefully these things. It was a long time ago though, I'll check again. > just the options for directory paths "--with-gl-include" etc seem to be used Daniel
(In reply to comment #151) > Created an attachment (id=154379) [edit] Hi Richard, > if a use flag was disabled it was putting "without-gl-include" instead of > ommitting it > which seemed to confuse the configure script and throw up an error (it was > looking for a directory called "no") I saw that too. My mistake... ;) > also I've removed --with-gl, --with-xmu, --enable-jcas as they don't seem to be > used within the configure script I checked that again. You were right. My mistake too... ;) > just the options for directory paths "--with-gl-include" etc seem to be used I'll include your changes in the overlay. Thank you very much for having checked an corrected all of this. Best regards Daniel
Hello, there seems to be a problem, if the actual java vm is only an jre. I've had to change my java vm by hand to an java jdk. I think in the ebuild should something be stated like: inherit java-pkg-2 ... pkg_setup() { java-pkg-2_pkg_setup ... Then the right java-vm is choosen automatically while the build process.
good news - opencascade 6.3 is out and it has a makefile
Hello, I've tested the new opencascade-6.3 ebuild and I've got a sandbox violation during the installation process (sorry, that LC_ALL=de_DE.utf8): >>> Install opencascade-6.3 into /var/tmp/portage/sci-libs/opencascade-6.3/image/ category sci-libs make -j5 prefix=/var/tmp/portage/sci-libs/opencascade-6.3/image///opt/opencascade-6.3/ros/lin install Making install in adm/make make[1]: Entering directory `/var/tmp/portage/sci-libs/opencascade-6.3/work/OpenCASCADE6.3.0/ros/adm/make' Making install in TKernel make[2]: Entering directory `/var/tmp/portage/sci-libs/opencascade-6.3/work/OpenCASCADE6.3.0/ros/adm/make/TKernel' make[3]: Entering directory `/var/tmp/portage/sci-libs/opencascade-6.3/work/OpenCASCADE6.3.0/ros/adm/make/TKernel' test -z "/opt/opencascade-6.3/ros/lin/lib64" || /bin/mkdir -p "/opt/opencascade-6.3/ros/lin/lib64" make[3]: Für das Ziel »install-data-am« ist nichts zu tun. ACCESS DENIED mkdir: /opt/opencascade-6.3 /bin/mkdir: kann Verzeichnis „/opt/opencascade-6.3“ nicht anlegen: Keine Berechtigung make[3]: *** [install-libLTLIBRARIES] Fehler 1 make[3]: Leaving directory `/var/tmp/portage/sci-libs/opencascade-6.3/work/OpenCASCADE6.3.0/ros/adm/make/TKernel' make[2]: *** [install-am] Fehler 2 make[2]: Leaving directory `/var/tmp/portage/sci-libs/opencascade-6.3/work/OpenCASCADE6.3.0/ros/adm/make/TKernel' make[1]: *** [install-recursive] Fehler 1 make[1]: Leaving directory `/var/tmp/portage/sci-libs/opencascade-6.3/work/OpenCASCADE6.3.0/ros/adm/make' make: *** [install-recursive] Fehler 1 * * ERROR: sci-libs/opencascade-6.3 failed. * Call stack: * ebuild.sh, line 49: Called src_install * environment, line 3457: Called die * The specific snippet of code: * emake prefix="${D}/${INSTALL_DIR}" install || die "Installation failed"; * The die message: * Installation failed * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/tmp/portage/sci-libs/opencascade-6.3/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sci-libs/opencascade-6.3/temp/environment'. * --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/var/log/sandbox/sandbox-22571.log" mkdir: /opt/opencascade-6.3 -------------------------------------------------------------------------------- Can we hard mask this new ebuild in the science overlay till it becomes a little bit more stable?
Hi! > I've tested the new opencascade-6.3 ebuild and I've got a sandbox violation > during the installation process (sorry, that LC_ALL=de_DE.utf8): > > >>> Install opencascade-6.3 into /var/tmp/portage/sci-libs/opencascade-6.3/image/ category sci-libs > make -j5 > Can we hard mask this new ebuild in the science overlay till it becomes a > little bit more stable? I am aware of these issues. I am trying (without major success) to correct the ebuild to get it working right. There is clearly an issue with the installation path and the sandbox (even though I succeed to get it built and installed on my machine here). From here I cannot put the latest one on the repository. I join it as an attachment. I don't know what I am missing here. Daniel
Created attachment 178469 [details] A non working 6.3 As I wrote. No issue so far regarding the compilation phasis, there are issues regarding the installation path and the sandbox though... :(
(In reply to comment #158) If it offers any clue, I got beyond the ACCESS DENIED error of comment #156 by using SANDBOX_WRITE=/ /usr/bin/paludis -i opencascade The installation now fails during the dodoc part of the ebuild's install phase. Testing on a second machine.
(In reply to comment #159) > (In reply to comment #158) > > If it offers any clue, I got beyond the ACCESS DENIED error of comment #156 > by using > > SANDBOX_WRITE=/ /usr/bin/paludis -i opencascade > > The installation now fails during the dodoc part of the ebuild's install phase. > Testing on a second machine. > If one exchanges "emake $bla install" for einstall in the ebuild, emerge fails on the dodoc part, too. I am currently testing if the install works with USE=-doc.
The cause of the dodoc error: There is no "-r" Option for dodoc.
Created attachment 182311 [details] This patch is probably only required for glibc>=2.8 (please test)
Created attachment 182314 [details] Ebuild with einstall replaced dodoc -r by a for loop, which destroys the directory structure
The einstall ebuild installs the OpenCascade Headers to /opt/opencascade-6.3/ros/inc and to /usr/inc, something is going wrong ...
Created attachment 182672 [details, diff] DESTDIR fix in Makefiles for clean install Using this patch I was able to compile/install OCC 6.3.0 cleanly. I've not tried to use it yet, though, and also note I used customized ebuild - most changes should be unrelated to compilation/installation issues, except the one below. ebuild should be modified to use the following command for installation: emake DESTDIR="${D}" install || die "Install failed"
Using Bert's 6.3-r1 ebuild (comment 163) including the glibc-2.8 patch (comment 162) and the modification specified by Alexander (comment 165) , and the SANDBOX trick (comment 159), 6.3-r1 builds and installs completey on my amd64 system. Have yet to test by building salome modules against it.
The pre-built salome 4.1.4 from the salome website (Mandriva build) seems to run with opencascade built with the 6.3-r1 ebuild in the manner of comment 166. Salome 4.1.4 geometry module didn't run until the older 6.2 ebuild of opencascade was updated. This exercise has been performed successfully on two amd64 (Intel) systems. An Athlon system still has some problem to work out. Thanks.
Created attachment 183316 [details] New proposal This ebuild uses Alexander's patch and also symlinks ../ros/config.h to ../ros/inc/config.h to compile salome.
Hi! I got opencascade-6.3-r1 built and installed on my x86, gcc-3.4.6 based box, using the ebuild provided by Bert. The contain of /opt/opencascade-6.3/ros/lin feels a bit strange though, as it reproduces the structure of /opt/opencascade-6.3/ros in some way: config.h inc lib lin Linux src can also be found in /opt/opencascade-6.3/ros It feels like an unnecessary duplicate or some bug in the configuration. I don't know. I probably do not really understand the purpose of this extra directory... Daniel
Hello Daniel, could you put all the changes to the science overlay? Thanks, Oliver
The ebuild in the science overlay dies in src_compile() if USE="opengl -X" is set... Please don't do that. Either check in pkg-setup or even better, silently enable X if opengl is enabled. The
(In reply to comment #171) > The ebuild in the science overlay dies in src_compile() if USE="opengl -X" is > set... Please don't do that. Either check in pkg-setup or even better, silently > enable X if opengl is enabled. The > fixed
Created attachment 200796 [details] Ebuild for OpenCascade 6.3 Service Pack 6 This Version of OpenCascade is required for Salome 5.1.2. The only way to get the source code is to extract it from the Salome 5.1.2 Installer: # Download an InstallWizard*.tar.gz from http://www.salome-platform.org/download/dl512/ # (you have to register to download) # unpack the InstallWizard*tar.gz and you'll find the sources in # -/InstallWizard*/Products/SOURCES
Created attachment 200798 [details] Environment template for opencascade 6.3 Service Pack 6
(In reply to comment #173) > Created an attachment (id=200796) [edit] > Ebuild for OpenCascade 6.3 Service Pack 6 The opencascade-6.3-r6.ebuild requires the opencascade-6.3-fixed-DESTDIR.patch supplied by Alexander T: http://bugs.gentoo.org/attachment.cgi?id=182672
I want to second the request for a tix/tcl use flag since I can't install tix on my amd64 computer ( http://bugs.gentoo.org/show_bug.cgi?id=280766 ).
I'm getting the same install error ... what what do I do now? >>> Install opencascade-6.3 into /var/tmp/portage/sci-libs/opencascade-6.3/image/ category sci-libs make -j2 prefix=/var/tmp/portage/sci-libs/opencascade-6.3/image///opt/opencascade-6.3/ros/lin install Making install in adm/make make[1]: Entering directory `/var/tmp/portage/sci-libs/opencascade-6.3/work/OpenCASCADE6.3.0/ros/adm/make' Making install in TKernel make[2]: Entering directory `/var/tmp/portage/sci-libs/opencascade-6.3/work/OpenCASCADE6.3.0/ros/adm/make/TKernel' make[3]: Entering directory `/var/tmp/portage/sci-libs/opencascade-6.3/work/OpenCASCADE6.3.0/ros/adm/make/TKernel' test -z "/opt/opencascade-6.3/ros/lin/lib64" || /bin/mkdir -p "/opt/opencascade-6.3/ros/lin/lib64" make[3]: Nothing to be done for `install-data-am'. /bin/sh ../../../libtool --mode=install /usr/bin/install -c 'libTKernel.la' '/opt/opencascade-6.3/ros/lin/lib64/libTKernel.la' /usr/bin/install -c .libs/libTKernel.so.0.0.0 /opt/opencascade-6.3/ros/lin/lib64/libTKernel.so.0.0.0 [31;01mACCESS DENIED[0m open_wr: /opt/opencascade-6.3/ros/lin/lib64/libTKernel.so.0.0.0 /usr/bin/install: cannot create regular file `/opt/opencascade-6.3/ros/lin/lib64/libTKernel.so.0.0.0': Permission denied make[3]: *** [install-libLTLIBRARIES] Error 1 make[3]: Leaving directory `/var/tmp/portage/sci-libs/opencascade-6.3/work/OpenCASCADE6.3.0/ros/adm/make/TKernel' make[2]: *** [install-am] Error 2 make[2]: Leaving directory `/var/tmp/portage/sci-libs/opencascade-6.3/work/OpenCASCADE6.3.0/ros/adm/make/TKernel' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/sci-libs/opencascade-6.3/work/OpenCASCADE6.3.0/ros/adm/make' make: *** [install-recursive] Error 1 [31;01m*[0m [31;01m*[0m ERROR: sci-libs/opencascade-6.3 failed. [31;01m*[0m Call stack: [31;01m*[0m ebuild.sh, line 49: Called src_install [31;01m*[0m environment, line 3612: Called die [31;01m*[0m The specific snippet of code: [31;01m*[0m emake prefix="${D}/${INSTALL_DIR}" install || die "Installation failed"; [31;01m*[0m The die message: [31;01m*[0m Installation failed [31;01m*[0m [31;01m*[0m If you need support, post the topmost build error, and the call stack if relevant. [31;01m*[0m A complete build log is located at '/var/log/portage/sci-libs:opencascade-6.3:20090902-061546.log'. [31;01m*[0m The ebuild environment file is located at '/var/tmp/portage/sci-libs/opencascade-6.3/temp/environment'. [31;01m*[0m This ebuild is from a repository named 'science' [31;01m*[0m [31;01m--------------------------- ACCESS VIOLATION SUMMARY ---------------------------[0m [31;01mLOG FILE[0m "/var/log/sandbox/sandbox-29091.log" VERSION 1.0 FORMAT: F - Function called FORMAT: S - Access Status FORMAT: P - Path as passed to function FORMAT: A - Absolute Path (not canonical) FORMAT: R - Canonical Path FORMAT: C - Command Line F: open_wr S: deny P: /opt/opencascade-6.3/ros/lin/lib64/libTKernel.so.0.0.0 A: /opt/opencascade-6.3/ros/lin/lib64/libTKernel.so.0.0.0 R: /opt/opencascade-6.3/ros/lin/lib64/libTKernel.so.0.0.0 C: /usr/bin/install -c .libs/libTKernel.so.0.0.0 /opt/opencascade-6.3/ros/lin/lib64/libTKernel.so.0.0.0 [31;01m--------------------------------------------------------------------------------[0m emerge --info: default/linux/amd64/2008.0, gcc-4.2.0, glibc-2.8_p20080602-r1, 2.6.28-gentoo-r5 x86_64) ================================================================= System uname: Linux-2.6.28-gentoo-r5-x86_64-AMD_Athlon-tm-_64_Processor_3400+-with-gentoo-1.12.11.1 Timestamp of tree: Tue, 01 Sep 2009 20:00:01 +0000 ccache version 2.4 [enabled] app-shells/bash: 3.2_p39 dev-java/java-config: 1.3.7-r1, 2.1.7 dev-lang/python: 2.5.2-r8, 2.6.2-r1 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r7 dev-util/cmake: 2.6.2-r1 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.6-r2 sys-devel/autoconf: 2.13, 2.63-r1 sys-devel/automake: 1.4_p6, 1.5, 1.9.6-r2, 1.10.2 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -O2" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-march=k8 -O2" DISTDIR="/usr/portage/distfiles" FEATURES="ccache collision-protect confcache distlocks fixpackages parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch userpriv usersandbox" GENTOO_MIRRORS="http://distfiles.gentoo.org http://www.ibiblio.org/pub/Linux/distributions/gentoo" LDFLAGS="-Wl,-O1" LINGUAS="en" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/sunrise /usr/portage/local/layman/science /usr/local/portage /usr/local/initng-portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acl acpi alsa amd64 apm bash-completion berkdb bzip2 cli cracklib crypt cups dbus debug doc dri examples fbcon fortran gd gdbm ggi gpm gstreamer hal hdf5 iconv imlib ipv6 isdnlog jpeg jpeg2k lash lcms libsaplerate lua mbox mmx mpi mudflap multilib ncurses nls nptl nptlonly opengl openmp pam pcre pdf perl png pppd python qt4 readline reflection sci-visualization/paraview sdl session spell spl sse sse2 ssl svg sysfs tcpd threads tiff truetype unicode xattr xcb xft xinerama xorg zlib" ALSA_CARDS="via82xx" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INITNG_PLUGINS=" also bash_launcher chdir chroot conflict cpout critical ctrlaltdel daemon_clean debug_commands envparser find fmon fstat history idleprobe initctl interactive iparser last limit lockfile logfile netdev netprobe ngc4 ngcs nge pause provide reload renice rlparser simple_launcher stcmd stdout suid syncron syslog sysreq unneeded usplash" INPUT_DEVICES="keyboard mouse magellan" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en" USERLAND="GNU" VIDEO_CARDS="radeon vesa" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
app-text/dgs was removed from the main tree http://bugs.gentoo.org/show_bug.cgi?id=246960 So opencascade can't emerge with USE=X now.
app-text/dgs has been integrated in science overlay I've tested successfully opencascade-6.3-r1 on x86 and amd64 and pushed it in science overlay.
Created attachment 204492 [details] opencascade-6.3_p6-r1 ebuild, without fetch restriction This opencascade-6.3_p6-r1 ebuild removes the fetch restriction, from the last one.
Opencascade 6.3-r1 doesn't compile when the USE flag "JAVA" is enabled (on amd64)! it fails with checking for jni_md.h in /opt/sun-jdk-1.6.0.15/include/linux... checking jni.h usability... no checking jni.h presence... no checking for jni.h... no configure: "Specify --with-java-include=<DIR> to enalbe Java support" configure: error: working jni.h not found !!! Please attach the following file when seeking support: !!! /var/tmp/portage/sci-libs/opencascade-6.3-r1/work/OpenCASCADE6.3.0/ros/config.log * * ERROR: sci-libs/opencascade-6.3-r1 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 3633: Called econf '--prefix=/opt/opencascade-6.3/ros/lin' '--exec-prefix=/opt/opencascade-6.3/ros/lin' '--with-tcl=/usr/lib64' '--with-tk=/usr/lib64' '--with-dps-include=/usr/include' '--with-dps-library=/usr/lib64' '--with-xmu-include=/usr/include' '--with-xmu-library=/usr/lib64' '--with-gl-include=/usr/include' '--with-gl-library=/usr/lib64' '--with-java-include=/opt/sun-jdk-1.6.0.15/include/linux' '--with-x' '--disable-debug' '--enable-production' * ebuild.sh, line 534: Called die * The specific snippet of code: * die "econf failed" * The die message: * econf failed * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/tmp/portage/sci-libs/opencascade-6.3-r1/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sci-libs/opencascade-6.3-r1/temp/environment'. * This ebuild is from an overlay named 'science': '/usr/local/portage/layman/science/' *
(In reply to comment #181) > Opencascade 6.3-r1 doesn't compile when the USE flag "JAVA" is enabled (on > amd64)! it fails with > > checking for jni_md.h in /opt/sun-jdk-1.6.0.15/include/linux... checking jni.h > usability... no > checking jni.h presence... no > checking for jni.h... no > configure: "Specify --with-java-include=<DIR> to enalbe Java support" > configure: error: working jni.h not found > I have the same problem on a x86 machine. jni.h can be found here : /opt/sun-jdk-1.6.0.15/include Roelof > !!! Please attach the following file when seeking support: > !!! > /var/tmp/portage/sci-libs/opencascade-6.3-r1/work/OpenCASCADE6.3.0/ros/config.log > * > * ERROR: sci-libs/opencascade-6.3-r1 failed. > * Call stack: > * ebuild.sh, line 49: Called src_compile > * environment, line 3633: Called econf > '--prefix=/opt/opencascade-6.3/ros/lin' > '--exec-prefix=/opt/opencascade-6.3/ros/lin' '--with-tcl=/usr/lib64' > '--with-tk=/usr/lib64' '--with-dps-include=/usr/include' > '--with-dps-library=/usr/lib64' '--with-xmu-include=/usr/include' > '--with-xmu-library=/usr/lib64' '--with-gl-include=/usr/include' > '--with-gl-library=/usr/lib64' > '--with-java-include=/opt/sun-jdk-1.6.0.15/include/linux' '--with-x' > '--disable-debug' '--enable-production' > * ebuild.sh, line 534: Called die > * The specific snippet of code: > * die "econf failed" > * The die message: > * econf failed > * > * If you need support, post the topmost build error, and the call stack if > relevant. > * A complete build log is located at > '/var/tmp/portage/sci-libs/opencascade-6.3-r1/temp/build.log'. > * The ebuild environment file is located at > '/var/tmp/portage/sci-libs/opencascade-6.3-r1/temp/environment'. > * This ebuild is from an overlay named 'science': > '/usr/local/portage/layman/science/' > * >
I have seen these java include errors in several ebuilds. I changed line 130 to confargs="${confargs} --with-java-include=${java_path}/lib" Now by opencascade starts building at least. On my machine java-config -O yields /opt/sun-jre-bin-1.6.0.10 I suspect the correct path is dependant on the specific java that is installed. hth Dewald
Last ebuild (opencascade-6.3_p6-r1.ebuild) seems to get an incorrect file (or checks with the wrong size). Since this file is extreme large (>1GB), maybe it is good to investigate this matter swiftly. >>> Emerging (1 of 1) sci-libs/opencascade-6.3_p6-r1 from local_overlay >>> Downloading 'http://files.opencascade.com/Salome/Salome5.1.2/InstallWizard_5.1.2_Debian_4.0.tar.gz' --2009-11-18 23:07:48-- http://files.opencascade.com/Salome/Salome5.1.2/InstallWizard_5.1.2_Debian_4.0.tar.gz Resolving files.opencascade.com... 70.38.38.48 Connecting to files.opencascade.com|70.38.38.48|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 1117217929 (1.0G) [application/x-gzip] Saving to: `/usr/portage/distfiles/InstallWizard_5.1.2_Debian_4.0.tar.gz' 100%[===================================================================================================================>] 1,117,217,929 310K/s in 69m 43s 2009-11-19 00:17:32 (261 KB/s) - `/usr/portage/distfiles/InstallWizard_5.1.2_Debian_4.0.tar.gz' saved [1117217929/1117217929] ('Filesize does not match recorded size', 1117217929, 11126080) !!! Fetched file: InstallWizard_5.1.2_Debian_4.0.tar.gz VERIFY FAILED! !!! Reason: Filesize does not match recorded size !!! Got: 1117217929 !!! Expected: 11126080 Refetching... File renamed to '/usr/portage/distfiles/InstallWizard_5.1.2_Debian_4.0.tar.gz._checksum_failure_.Ocfanc' !!! Couldn't download 'InstallWizard_5.1.2_Debian_4.0.tar.gz'. Aborting. * Fetch failed for 'sci-libs/opencascade-6.3_p6-r1', Log file: * '/tmp/portage/sci-libs/opencascade-6.3_p6-r1/temp/build.log' >>> Failed to emerge sci-libs/opencascade-6.3_p6-r1, Log file: >>> '/tmp/portage/sci-libs/opencascade-6.3_p6-r1/temp/build.log'
Hello, When I compile version 6.3-r1 on a AMD64 machine I get this message: QA Notice : Unrecognized options configure: warning: unrecognized options: --with-dps-include --with-dps-library --with-xmu-include --with-xmu-library --with-gl-include --with-gl-library Roelof
(In reply to comment #162) > Created an attachment (id=182311) [details] > This patch is probably only required for glibc>=2.8 (please test) > I can confirm it is needed when compiling with glibc-2.9_p20081201-r2. Compile fails without it.
sci-libs/opencascade-6.3-r3 added to the main portage tree
