Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 118656

Summary: sci-libs/opencascadelib-6.2.ebuild (New package)
Product: Gentoo Linux Reporter: Jeff Shanab <jshanab>
Component: New packagesAssignee: Andreas K. Hüttel <dilfridge>
Status: RESOLVED FIXED    
Severity: enhancement CC: arthur, daniel.tourde, daniel.tourde, dewald.pieterse, divanorama, ducasse.isidore, mfrank, oli.borm, quintino, sci, squinky86, ted
Priority: High Keywords: InVCS
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Bug Depends on: 352435    
Bug Blocks:    
Attachments: opencascadelib-5.2.ebuild
opencascadelib.5.2.AMDGCCTCL.patch
Updated Ebuild
First attempt for OpenCascade 6.1
Second attempt for an ebuild
Alpha version of the ebuild. Please test it!
second 'alpha'
Third 'alpha'
We are getting closer to the holy grail...
A patch for gcc4
Beta 1
New ebuild (beta 2)
The Changelog
Beta 3
Beta 4
Changelog
Beta 5 (OpenCascade-6.1-r1)
ebuild for OpenCASCADE 6.2
ebuild for OpenCASCADE 6.2
Patch for OpenCASCADE 6.2 with gcc-4.1
New Changelog
opencascade 6.2 ebuild fails on amd64 arch.
ebuild patch: virtual/x11 fails => replaced by x11-base/xorg-x11.
New ebuild for 6.1. It takes into account a few new things and Florent's comments
New patch for 6.1
New ebuild for 6.2.
New patch for 6.2 with gcc-4.1
A slightly more advanced ebuild for 6.2.
New Changelog
Corrected 6.1-r2
Corrected 6.2-r1
lpthread argument to g++ needed for gcc-4.1
lpthread argument to g++ needed for gcc-4.1
opencascade-6.1-r3.ebuild
opencascade-6.2-r2.ebuild
New Changelog
Rebuilt from scratch taking code from R2
Environment variables template file
Gcc4.x patch for Opencascade (thanks to Jason Kraftcheck)
Malloc patch avoiding portage complaining about code quality
OpenCascade 6.2 release 4
path problem in 50opencascade
OpenCascade-6.2-r5. Included Francois' suggestion
Copy of the Open Cascade license. To be put under /usr/portage/licenses
OpenCascade: A reworked ebuild
Corrected opencascade ebuild
OpenCascade: A reworked ebuild
New ebuild with version checking for the tcltk stuff.
Corrected version with version detection for the tcl stuff
New ebuild. It's already in the science overlay
opencascade-6.2-r2.ebuild
A non working 6.3
This patch is probably only required for glibc>=2.8 (please test)
Ebuild with einstall
DESTDIR fix in Makefiles for clean install
New proposal
Ebuild for OpenCascade 6.3 Service Pack 6
Environment template for opencascade 6.3 Service Pack 6
opencascade-6.3_p6-r1 ebuild, without fetch restriction

Description Jeff Shanab 2006-01-11 06:00:25 UTC
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
Comment 1 Jeff Shanab 2006-01-11 06:02:41 UTC
Created attachment 76830 [details]
opencascadelib-5.2.ebuild
Comment 2 Jeff Shanab 2006-01-11 06:06:56 UTC
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)
Comment 3 Jakub Moc (RETIRED) gentoo-dev 2006-01-11 06:54:00 UTC
*** Bug 54998 has been marked as a duplicate of this bug. ***
Comment 4 Jakub Moc (RETIRED) gentoo-dev 2006-01-13 18:15:43 UTC
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

Comment 5 Daniel Tourde - Caelae.se 2006-06-07 11:42:51 UTC
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
Comment 6 Jeff Shanab 2006-06-08 18:40:11 UTC
Created attachment 88730 [details]
Updated Ebuild

Ebuild updated as per feedback.
Comment 7 Daniel Tourde 2006-06-19 12:19:41 UTC
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?
Comment 8 Jeff Shanab 2006-06-19 21:22:58 UTC
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.
Comment 9 Arthur Magill 2006-07-23 03:04:00 UTC
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
Comment 10 Daniel Tourde 2006-07-25 04:18:24 UTC
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
Comment 11 Daniel Tourde 2006-08-29 13:09:05 UTC
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
Comment 12 Arthur Magill 2006-08-29 14:17:17 UTC
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?
Comment 13 Daniel Tourde 2006-08-31 15:03:11 UTC
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
Comment 14 Daniel Tourde 2006-09-05 12:53:35 UTC
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
Comment 15 Arthur Magill 2006-09-05 14:37:32 UTC
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.
Comment 16 Daniel Tourde 2006-09-05 23:07:52 UTC
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
Comment 17 Daniel Tourde 2006-09-06 01:13:32 UTC
Hello,

I got some information from the OpenCascade forum: http://www.opencascade.org/org/forum/thread_10190/
I will try this tonight.

Daniel
Comment 18 Daniel Tourde 2006-09-06 10:55:26 UTC
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
Comment 19 Arthur Magill 2006-09-07 04:35:51 UTC
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.
Comment 20 Daniel Tourde 2006-09-07 04:41:23 UTC
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.
Comment 21 Arthur Magill 2006-09-08 08:00:07 UTC
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)?
Comment 22 Daniel Tourde 2006-09-13 11:31:49 UTC
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
Comment 23 Daniel Tourde 2006-09-14 09:35:38 UTC
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
Comment 24 Daniel Tourde 2006-09-14 09:37:38 UTC
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)
Comment 25 Daniel Tourde 2006-09-14 10:03:35 UTC
One more comment:
einstall fails the same way (instead of emake install)

Daniel
Comment 26 Daniel Tourde 2006-09-15 05:51:44 UTC
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.
Comment 27 Daniel Tourde 2006-09-18 14:48:03 UTC
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...
Comment 28 Daniel Tourde 2006-09-18 14:56:37 UTC
I confirm. It compiles and installs properly. Edges still need to be smoothened but in principle everything is here...

Daniel
Comment 29 Daniel Tourde 2006-09-20 05:54:28 UTC
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
Comment 30 Daniel Tourde 2006-09-21 01:34:06 UTC
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

Comment 31 Daniel Tourde 2006-09-21 03:35:46 UTC
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
Comment 32 Daniel Tourde 2006-09-24 11:45:54 UTC
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.
Comment 33 Daniel Tourde 2006-09-25 01:27:58 UTC
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
Comment 34 Daniel Tourde 2006-10-03 23:03:13 UTC
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
Comment 35 Daniel Tourde 2006-10-03 23:05:06 UTC
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.
Comment 36 Daniel Tourde 2006-10-05 01:50:01 UTC
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
Comment 37 Daniel Tourde 2006-10-22 12:26:06 UTC
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
Comment 38 Daniel Tourde 2006-10-22 12:26:54 UTC
Created attachment 100233 [details]
The Changelog
Comment 39 Daniel Tourde 2006-10-23 08:22:38 UTC
Created attachment 100290 [details]
Beta 3

Corrected a minor issue with the 50opencascade-6.1 file
Comment 40 Daniel Tourde 2006-10-27 15:10:04 UTC
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
Comment 41 Daniel Tourde 2006-10-27 15:10:49 UTC
Created attachment 100619 [details]
Changelog

A new Changelog
Comment 42 Daniel Tourde 2006-11-16 12:52:45 UTC
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... ;)
Comment 43 Michael Frank 2007-03-07 06:26:47 UTC
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
Comment 44 Daniel Tourde 2007-03-07 08:07:57 UTC
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
Comment 45 Daniel Tourde 2007-03-26 17:02:53 UTC
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)
Comment 46 Daniel Tourde 2007-03-26 17:04:10 UTC
Created attachment 114511 [details]
Beta 5 (OpenCascade-6.1-r1)

Corrected minor issues
Comment 47 Daniel Tourde 2007-03-26 17:05:20 UTC
Created attachment 114512 [details]
ebuild for OpenCASCADE 6.2 

ebuild for OpenCASCADE 6.2 (the associated patch needs some work though)
Comment 48 Daniel Tourde 2007-03-26 17:06:07 UTC
Created attachment 114513 [details]
ebuild for OpenCASCADE 6.2 

ebuild for OpenCASCADE 6.2 (the associated patch needs some work though)
Comment 49 Daniel Tourde 2007-03-26 17:07:33 UTC
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
Comment 50 Daniel Tourde 2007-03-26 17:08:17 UTC
Created attachment 114517 [details]
New Changelog

New changelog
Comment 51 Isidore 2007-05-09 16:03:46 UTC
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.
Comment 52 Isidore 2007-05-09 16:10:39 UTC
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.
Comment 53 Daniel Tourde 2007-05-22 20:29:26 UTC
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
Comment 54 Daniel Tourde 2007-05-27 17:35:03 UTC
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.
Comment 55 Daniel Tourde 2007-05-27 17:36:33 UTC
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...
Comment 56 Daniel Tourde 2007-05-27 17:38:40 UTC
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...
Comment 57 Daniel Tourde 2007-05-27 17:39:49 UTC
Created attachment 120464 [details, diff]
New patch for 6.2 with gcc-4.1

This new patch includes what Florent sent me.
Comment 58 Daniel Tourde 2007-05-27 17:41:55 UTC
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
Comment 59 Daniel Tourde 2007-05-27 17:45:56 UTC
Created attachment 120468 [details]
New Changelog
Comment 60 Isidore 2007-05-28 01:14:13 UTC
 (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 .
Comment 61 Daniel Tourde 2007-05-28 07:25:44 UTC
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. 
Comment 62 Daniel Tourde 2007-05-28 12:59:02 UTC
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
Comment 63 Daniel Tourde 2007-05-28 14:46:10 UTC
Created attachment 120524 [details]
Corrected 6.2-r1
Comment 64 Daniel Tourde 2007-05-29 07:27:33 UTC
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.
Comment 65 Daniel Tourde 2007-05-30 09:25:23 UTC
(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

Comment 66 Isidore 2007-05-30 18:19:12 UTC
(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.

Comment 67 Daniel Tourde 2007-05-31 07:21:09 UTC
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... :( )
Comment 68 Daniel Tourde 2007-05-31 07:22:03 UTC
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
> 

Comment 69 roland.graf 2007-06-09 07:43:43 UTC
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.
Comment 70 Rajil 2007-06-13 05:24:26 UTC
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
Comment 71 Isidore 2007-06-13 17:29:34 UTC
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.
Comment 72 Isidore 2007-06-13 17:30:53 UTC
Created attachment 121950 [details, diff]
lpthread argument to g++ needed for gcc-4.1

(the second patch - see previous post.)
Comment 73 Isidore 2007-06-13 17:58:50 UTC
(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.
Comment 74 Rajil 2007-06-13 19:32:49 UTC
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


Comment 75 GenSan 2007-09-11 17:18:50 UTC
Hello *,

got exactly the same error as above :-(

Any solution?

thankx
Comment 76 Daniel Tourde 2007-09-26 15:51:15 UTC
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.
> 

Comment 77 Daniel Tourde 2007-09-26 15:57:51 UTC
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
Comment 78 Daniel Tourde 2007-09-26 15:59:26 UTC
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
Comment 79 Daniel Tourde 2007-09-26 16:03:12 UTC
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
Comment 80 Álvaro Castro Castilla 2007-09-30 13:02:00 UTC
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!
Comment 81 Oliver Borm 2007-10-14 21:24:21 UTC
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. 
Comment 82 Álvaro Castro Castilla 2007-10-14 21:43:52 UTC
(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.
Comment 83 Álvaro Castro Castilla 2007-10-16 20:05:10 UTC
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.
Comment 84 Daniel Tourde 2007-10-18 08:51:54 UTC
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
Comment 85 Daniel Tourde 2007-10-18 08:53:15 UTC
> 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 

Comment 86 Daniel Tourde 2007-10-18 08:58:28 UTC
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 

Comment 87 Álvaro Castro Castilla 2007-10-18 14:15:16 UTC
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. 
> 

Comment 88 Álvaro Castro Castilla 2007-10-18 14:30:14 UTC
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.
Comment 89 Arthur Magill 2007-10-18 15:59:07 UTC
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
Comment 90 Álvaro Castro Castilla 2007-10-18 17:14:18 UTC
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.
Comment 91 Álvaro Castro Castilla 2007-10-18 18:56:14 UTC
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?
Comment 92 Daniel Tourde 2007-10-19 13:39:30 UTC
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

Comment 93 Daniel Tourde 2007-10-19 13:45:13 UTC
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

Comment 94 Daniel Tourde 2007-10-19 13:56:58 UTC
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
Comment 95 Álvaro Castro Castilla 2007-10-24 19:48:22 UTC
Created attachment 134268 [details]
Rebuilt from scratch taking code from R2
Comment 96 Álvaro Castro Castilla 2007-10-24 19:48:43 UTC
Created attachment 134269 [details]
Environment variables template file
Comment 97 Álvaro Castro Castilla 2007-10-24 19:49:19 UTC
Created attachment 134270 [details, diff]
Gcc4.x patch for Opencascade (thanks to Jason Kraftcheck)
Comment 98 Álvaro Castro Castilla 2007-10-24 19:50:17 UTC
Created attachment 134271 [details, diff]
Malloc patch avoiding portage complaining about code quality

Straightforward solution: adding stdlib.h include in the affected file.
Comment 99 Álvaro Castro Castilla 2007-10-24 20:00:46 UTC
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
Comment 100 Arthur Magill 2007-10-25 09:07:20 UTC
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
Comment 101 Arthur Magill 2007-10-25 09:24:59 UTC
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
Comment 102 Arthur Magill 2007-10-25 09:42:12 UTC
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...
Comment 103 Álvaro Castro Castilla 2007-10-25 10:30:29 UTC
(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.

Comment 104 Álvaro Castro Castilla 2007-10-25 10:32:21 UTC
(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.
Comment 105 Daniel Tourde 2007-10-30 12:25:41 UTC
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
Comment 106 Álvaro Castro Castilla 2007-10-30 18:12:13 UTC
(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!
Comment 107 Álvaro Castro Castilla 2007-10-30 18:24:32 UTC
I think I solved the qt3 issue and the 50opencascade file issue. I upload it after (re)compiling the stuff.
Comment 108 Álvaro Castro Castilla 2007-10-30 18:26:07 UTC
I just realized that the slot was 1, so I changed it to 0. That means is not slottable.
Comment 109 Álvaro Castro Castilla 2007-11-10 20:55:36 UTC
Created attachment 135676 [details]
OpenCascade 6.2 release 4

Bugfixes
Comment 110 Daniel Tourde 2007-12-03 12:02:34 UTC
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
Comment 111 Daniel Tourde 2007-12-03 12:37:42 UTC
Hello again,

false alarm, my CASROOT was wrong... Sorry about that...

Daniel
Comment 112 Daniel Tourde 2007-12-03 13:26:27 UTC
(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
Comment 113 Daniel Tourde 2007-12-03 15:09:04 UTC
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
Comment 114 Álvaro Castro Castilla 2007-12-05 09:56:48 UTC
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
> 

Comment 115 Daniel Tourde 2007-12-05 13:25:03 UTC
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.
> 
Comment 116 Daniel Tourde 2007-12-05 13:34:26 UTC
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
Comment 117 Álvaro Castro Castilla 2007-12-05 14:49:14 UTC
(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.
Comment 118 Álvaro Castro Castilla 2007-12-05 14:50:18 UTC
Created attachment 137800 [details]
path problem in 50opencascade
Comment 119 François DORIN 2008-01-11 23:22:47 UTC
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
Comment 120 Daniel Tourde 2008-01-15 08:22:32 UTC
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
Comment 121 Sébastien Fabbro (RETIRED) gentoo-dev 2008-01-15 19:34:42 UTC
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!
Comment 122 Oliver Borm 2008-01-29 02:19:02 UTC
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!
Comment 123 Álvaro Castro Castilla 2008-01-29 09:58:30 UTC
(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...

Comment 124 Jon Hood 2008-02-06 16:51:37 UTC
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
Comment 125 Jon Hood 2008-02-06 19:12:40 UTC
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
Comment 126 Jon Hood 2008-02-07 14:22:23 UTC
both issues were fixed by setting my java vm correctly.
Comment 127 Daniel Tourde - Caelae.se 2008-03-13 23:22:49 UTC
(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
Comment 128 Daniel Tourde - Caelae.se 2008-03-13 23:23:39 UTC
(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
Comment 129 Daniel Tourde - Caelae.se 2008-03-13 23:33:20 UTC
(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

Comment 130 Daniel Tourde - Caelae.se 2008-03-13 23:35:40 UTC
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
Comment 131 Sébastien Fabbro (RETIRED) gentoo-dev 2008-03-14 13:04:57 UTC
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
Comment 132 Daniel Tourde 2008-03-14 13:25:21 UTC
(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
Comment 133 Daniel Tourde 2008-03-14 13:28:29 UTC
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
Comment 134 Daniel Tourde - Caelae.se 2008-03-14 21:08:37 UTC
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
Comment 135 Dewald Pieterse 2008-04-23 18:16:19 UTC
Created attachment 150729 [details]
Corrected opencascade ebuild
Comment 136 Daniel Tourde 2008-04-24 08:16:32 UTC
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
 

Comment 137 Dewald Pieterse 2008-04-24 08:24:24 UTC
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
Comment 138 Daniel Tourde 2008-04-24 08:29:53 UTC
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.


Comment 139 Daniel Tourde - Caelae.se 2008-05-11 14:17:11 UTC
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
Comment 140 Daniel Tourde - Caelae.se 2008-05-12 17:28:53 UTC
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
Comment 141 Dewald Pieterse 2008-05-14 17:27:09 UTC
(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
Comment 142 Daniel Tourde - Caelae.se 2008-05-14 20:31:22 UTC
(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                                                                                
Comment 143 Dewald Pieterse 2008-05-15 19:48:01 UTC
> 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

Comment 144 Dewald Pieterse 2008-05-16 06:53:02 UTC
> 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
Comment 145 Dewald Pieterse 2008-05-16 08:13:36 UTC
(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)"

Comment 146 Dewald Pieterse 2008-05-18 17:27:53 UTC
Created attachment 153571 [details]
New ebuild with version checking for the tcltk stuff.
Comment 147 Dewald Pieterse 2008-05-20 17:42:17 UTC
Created attachment 153775 [details]
Corrected version with version detection for the tcl stuff
Comment 148 Daniel Tourde - Caelae.se 2008-05-20 20:19:10 UTC
(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

Comment 149 Daniel Tourde - Caelae.se 2008-05-20 20:20:46 UTC
Created attachment 153795 [details]
New ebuild. It's already in the science overlay
Comment 150 Dewald Pieterse 2008-05-21 06:37:41 UTC
(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
Comment 151 Richard Westwell 2008-05-26 18:51:04 UTC
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
Comment 152 Daniel Tourde 2008-05-27 07:20:46 UTC
(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
Comment 153 Daniel Tourde 2008-05-27 08:45:58 UTC
(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

Comment 154 Oliver Borm 2008-07-14 22:26:08 UTC
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.
Comment 155 Radu Benea 2008-09-05 08:16:30 UTC
good news - opencascade 6.3 is out and it has a makefile
Comment 156 Oliver Borm 2009-01-07 18:05:48 UTC
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?
Comment 157 Daniel Tourde 2009-01-14 11:37:33 UTC
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

Comment 158 Daniel Tourde 2009-01-14 11:39:22 UTC
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... :(
Comment 159 Brennan Sharp 2009-01-20 20:10:19 UTC
(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.
Comment 160 Bert Karwatzki 2009-02-16 19:14:54 UTC
(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.
Comment 161 Bert Karwatzki 2009-02-17 00:07:54 UTC
The cause of the dodoc error:
There is no "-r" Option for dodoc.
Comment 162 Bert Karwatzki 2009-02-17 08:30:56 UTC
Created attachment 182311 [details]
This patch is probably only required for glibc>=2.8 (please test)
Comment 163 Bert Karwatzki 2009-02-17 08:41:10 UTC
Created attachment 182314 [details]
Ebuild with einstall

replaced dodoc -r by a for loop, which destroys the directory structure
Comment 164 Bert Karwatzki 2009-02-18 19:45:35 UTC
The einstall ebuild installs the OpenCascade Headers to /opt/opencascade-6.3/ros/inc and to /usr/inc, something is going wrong ...
Comment 165 Alexander T 2009-02-20 16:27:56 UTC
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"
Comment 166 Brennan Sharp 2009-02-22 08:42:55 UTC
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.
Comment 167 Brennan Sharp 2009-02-24 21:47:56 UTC
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.
Comment 168 Bert Karwatzki 2009-02-27 00:15:58 UTC
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.
Comment 169 Daniel Tourde 2009-02-27 15:42:59 UTC
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
Comment 170 Oliver Borm 2009-03-21 13:03:43 UTC
Hello Daniel,

could you put all the changes to the science overlay?

Thanks,
Oliver
Comment 171 Olivier Crete (RETIRED) gentoo-dev 2009-05-31 17:47:26 UTC
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 
Comment 172 Justin Lecher gentoo-dev 2009-05-31 17:54:41 UTC
(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
Comment 173 Bert Karwatzki 2009-08-10 08:07:22 UTC
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
Comment 174 Bert Karwatzki 2009-08-10 08:08:56 UTC
Created attachment 200798 [details]
Environment template for opencascade 6.3 Service Pack 6
Comment 175 Bert Karwatzki 2009-08-10 18:42:25 UTC
(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
Comment 176 BlGene 2009-08-27 11:52:17 UTC
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 ). 
Comment 177 BlGene 2009-09-02 20:10:16 UTC
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

Comment 178 Dmitry Ivankov 2009-09-13 17:59:48 UTC
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.
Comment 179 Etienne Lorriaux 2009-09-17 17:27:52 UTC
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.
Comment 180 Oliver Borm 2009-09-18 08:38:39 UTC
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.
Comment 181 Vittorio 2009-10-15 12:04:38 UTC
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/'
 * 
Comment 182 Roelof Wobben 2009-11-02 20:40:10 UTC
(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/'
>  * 
> 

Comment 183 Dewald Pieterse 2009-11-03 18:57:48 UTC
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
Comment 184 ruud 2009-11-19 10:13:58 UTC
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'
Comment 185 Roelof Wobben 2009-11-19 19:51:29 UTC
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
Comment 186 Paul Brand 2009-12-11 14:47:41 UTC
(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.
Comment 187 Andreas K. Hüttel gentoo-dev 2011-03-03 01:11:17 UTC
sci-libs/opencascade-6.3-r3 added to the main portage tree