SALOME is a free software that provides a generic platform for Pre and Post-Processing for numerical simulation. It is based on an open and flexible architecture made of reusable components available as free software. It is open-source (LGPL), and you can download both the sourcecode and the executables from this site. Salome Platform: * Supports interoperability between CAD modeling and computation software (CAD-CAE link) * Makes easier the integration of new components on heterogeneous systems for numerical computation * Sets the priority to multi-physics coupling between computation software * Provides a generic user interface, user-friendly and efficient, which helps to reduce the costs and delays of carrying out the studies * Reduces training time to the specific time for learning the software solution which has been based on this platform * All functionalities are accessible through the programmatic integrated Python console
Created attachment 102571 [details] The salome-meta ebuild This is just to give an idea. It has not been tested yet.
Created attachment 102572 [details] the first attempt on an ebuild for salome-kernel First attempt. There is a problem that I cannot solve though. Please help! ;)
Created attachment 102573 [details, diff] Patch for salome-kernel This patch allows compilation with gcc-4.1.1 and VTK-5
It says: make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/var/tmp/portage/salome-kernel-3.2.2/work/salome3.2.2_SRC/KERNEL_SRC_3.2.2' >>> Source compiled. >>> Test phase [not enabled]: sci-misc/salome-kernel-3.2.2 >>> Install salome-kernel-3.2.2 into /var/tmp/portage/salome-kernel-3.2.2/image/ category sci-misc Making install in idl make[1]: Entering directory `/var/tmp/portage/salome-kernel-3.2.2/work/salome3.2.2_SRC/KERNEL_SRC_3.2.2/idl' make install-am make[2]: Entering directory `/var/tmp/portage/salome-kernel-3.2.2/work/salome3.2.2_SRC/KERNEL_SRC_3.2.2/idl' make[3]: Entering directory `/var/tmp/portage/salome-kernel-3.2.2/work/salome3.2.2_SRC/KERNEL_SRC_3.2.2/idl' /bin/install -c -d /usr/lib/python2.4/site-packages/salome /bin/install: cannot change permissions of `/usr/lib/python2.4/site-packages/salome': No such file or directory make[3]: *** [install-exec-local] Error 1 make[3]: Leaving directory `/var/tmp/portage/salome-kernel-3.2.2/work/salome3.2.2_SRC/KERNEL_SRC_3.2.2/idl' make[2]: *** [install-am] Error 2 make[2]: Leaving directory `/var/tmp/portage/salome-kernel-3.2.2/work/salome3.2.2_SRC/KERNEL_SRC_3.2.2/idl' make[1]: *** [install] Error 2 make[1]: Leaving directory `/var/tmp/portage/salome-kernel-3.2.2/work/salome3.2.2_SRC/KERNEL_SRC_3.2.2/idl' make: *** [install-recursive] Error 1 !!! ERROR: sci-misc/salome-kernel-3.2.2 failed. Call stack: ebuild.sh, line 1546: Called dyn_install ebuild.sh, line 1020: Called src_install salome-kernel-3.2.2.ebuild, line 101: Called die !!! make install failed !!! If you need support, post the topmost build error, and the call stack if relevant.
I think it is ebuild related, not salome related. My knowledge of the arcanes of ebuild is unfortunately fairly limited, so any help is welcome...
Created attachment 114639 [details] Second attempt of an ebuild for salome-kernel This ebuild builds and install files on my x86 box. It is tested with OpenCacscade 6.1 This is a raw ebuild. A lot remains to be tested, support of mpi and openpbs to begin with.
Created attachment 114650 [details] Third attempt for salome-kernel The difference between this one and the previous one, is that from now on, I'll apply all patches to the whole source tree, whatever the subpart of salome I am buiding (in case of).
Created attachment 114651 [details, diff] Patch for GEOM
Created attachment 114653 [details, diff] Patch for GUI
Created attachment 114655 [details, diff] patch for KERNEL
Created attachment 114657 [details, diff] Patch for MED
Created attachment 114659 [details, diff] Patch for NETGENPLUGIN
Created attachment 114660 [details, diff] Patch for SMESH
Created attachment 114662 [details, diff] Patch for SUPERV
Created attachment 114664 [details, diff] Patch for VISU
Salome 3.2.6 has been released. I am trying now the ebuilds I have created so far...
Created attachment 120027 [details] Salome kernel (3.2.6) I basically removed the patches applied to 3.2.2. The compilation went flawlessly. Daniel
I added a /etc/env.d/50salome-kernel-3.2.6 file containing the variable KERNEL_ROOT_DIR. The existence of this variable is necessary to compile the rest of SALOME.
Created attachment 120226 [details] A new ebuild for salome-kernel
Created attachment 131980 [details] salome kernel 3.2.6 Basically added th flags -ffriend-injection -fpermissive for gcc 4.1.x and opencascade
Created attachment 131981 [details] salome gui 3.2.6 Still a moving target. I am getting close though...
Created attachment 131983 [details, diff] GUI 3.2.6 patch This patch is still a moving target as well. I am not far off though...
Can you please add these ebuilds and patches to an overlay? Maybe the sunrise overlay?
Can you please change the SRC_URI to "http://files.opencascade.com/Salome${PV}/src${PV}.tar.gz", so the sources can be fetched easilier.
Hello Oliver, Thanks for your comments. Regarding the overlay, the problem is that the ebuilds are incomplete (some are missing) and not mature enough, IMHO, to be put on the overlay.
Hello Daniel, Could you please give some more information of your structure and progress of your 3.2.2 ebuild?
sip-4.7.1 produce a syntax error for salome-gui-3.2.6. Use sip-4.5.2-r1 instead.
Hello, > Hello Daniel, > > Could you please give some more information of your structure and progress of > your 3.2.2 ebuild? Well, here is the situation at the moment. Salome 3.2.6 is made to work on gcc3, opencascade6.x and vtk4. Opencascade (I initiated the ebuild) originally is also supposed to be compiled with gcc3 but after some discussions regarding the advantages/inconvenients of extra gcc flags vs patch we chose to make it work for gcc4 via a patch. Many people have now gcc4 and Gentoo has an ebuild for vtk5 and this is where the problem lies because there is _no_ patch available to make the transition from vtk4 to vtk5 with Salome 3.2.x. The answer upstream is 'wait until Salome 4 shows up'... Regarding the ebuild I put there: - As you can see, there are modular: salome-kernel, salome-gui etc... - They still rely on the flags given to Opencascade to work with gcc4. This has to be removed. - Salome-gui is _the_ problem. It does not build because VTK5 and VTK4 has differences... :( - The other salome-xxx have to be written. They seem to be simple to create though. I hope I am clear enough in my explanations... Daniel
Hi, I made several ebuild for Gentoo to install salome on my laptop. I found only tonight this bug report. I made several patches to build salome with vtk5 and gcc4. And salome runs :-) But I must confess some patches are "not safe" in the sense I eliminated the compilation errors. I'm not sure there will be no error while running. I forgot to precise I used version 3.2.6 of salome on x86 achitecture. Have I to open a new bug report to post my ebuilds and patches ? Or have I to post them here ?
Post them here. I am very interested by what you did and I don't see the interest of having two bug reports and basically two separated efforts. I think we can clearly envisage a merge of our current efforts. What do you think? Daniel
Created attachment 137331 [details] salome : GUI component Another ebuild for GUI component of salome
Created attachment 137336 [details, diff] Patch for GUI Component Patch the sources to compile with more versions of Qt and Sip
Created attachment 137338 [details, diff] Patch for GUI Component Patch the source to comile with vtk-5.0
Hello, I created 3 attachments : one ebuild and two patches for the GUI Component. I have to clean the ebuilds and patches before attach them. And I have to translate them in English because it's not my mother tongue ;-) I'll attach them as soon as I possible. François
Salut Francois, Thanks for your effort. I checked very quickly how you structured your salome-gui and compared to what I had done with my own salome-gui ebuild. Do you think we can merge them? We did not focus on the same thing, so I think there is a pretty good chance that the 2 ebuilds can be merged into each others nicely. Cordialement, Daniel PS: Are you aware that the latest opencascade ebuild does not use the ffriend-injection tric anymore?
Bonsoir It must be possible to merge the two ebuilds. I just have a question : does your ebuild work with einstall instead make install ? I tried it on my computer and had errors. The only way I found to install it is to disable sandbox. As you can see in my ebuild, the used way to compile the sources are not very nice. I have to execute make a first time which terminates with an error due to a problem in relation with sip, patch a generated file and relaunch the compilation. I'm looking for a better way to solve this problem, but I must confess I'm not familiar with sip. If you have any suggestion, don't hesitate :-) Otherwise, I know that OpenCASCADE doesn't need anymore -ffriend-injection, because I also made a ebuild for it and don't use it. Currently, I'm working on a ebuild for Code-Aster. It does not look very nice because Code Aster doesn't use Makefile but python scripts. I write about Code Aster because I saw salome and Code Aster can be used together. And to answer one of your question (cf salome-kernel-3.2.6.ebuild, "What is med ?"), med is a part of the Code Aster software. François PS : Are you French or do you speak French ?
Created attachment 137719 [details] salome : GUI component Hello, this ebuild merge our two ebuilds and it works fine on my computer.I don't try every use flag (only X opengl and corba). It is not necessary to disable sandbox contrary to my previous ebuild. I used configure script and make instead of econf and emake because : 1) the default gentoo's installation installs files in several directories and I'm not sure the GUI Component work correctly in this case 2) it is easier to uninstall the component manually in case of problems ;-) François
Salut Francois, > It must be possible to merge the two ebuilds. I saw that you did it. Great work. Thanks! I will take a close look at it fairly soon. I have a few questions for you regarding your Salome ebuilds: - Did you make ebuilds for the whole serie? (the kernel and the rest). If yes, can we try to merge our efforts (at least regarding the kernel)? - You install things under /opt, isn't it? Why not /usr? Well, for these kind of issues, I usually leave the final decision to the gentoo guys anyway... ;) - Did you try any MPI support? The problem is the following: OpenFOAM needs openmpi and salome uses mpich. As far as I remember, it is impossible to have both installed at the same time... :( > I just have a question : does your ebuild work with einstall instead make > install ? I tried it on my computer and had errors. The kernel ebuild worked indeed flawlessly with einstall. I am cleaning it up at the moment. What I just checked, considering that OpenCascade does _not_ use the gcc4 flags anymore is that the salome-kernel can be built without the append-flags. That basically means that the salome-gui can probably be built without these flags as well (to be confirmed though). > The only way I found to install it is to disable sandbox. > > As you can see in my ebuild, the used way to compile the sources are not very > nice. I have to execute make a first time which terminates with an error due to > a problem in relation with sip, patch a generated file and relaunch the > compilation. > > I'm looking for a better way to solve this problem, but I must confess I'm not > familiar with sip. It seems to be kind of tricky indeed. Did you find anything about the sip issue on various forums? > If you have any suggestion, don't hesitate :-) > > Otherwise, I know that OpenCASCADE doesn't need anymore -ffriend-injection, > because I also made a ebuild for it and don't use it. Can you compare your ebuild with the one we have on bugs.gentoo.org, that Alvaro and I created? That would be interesting to see if we missed anything. > Currently, I'm working on a ebuild for Code-Aster. My fellow citizen, isn't it in such cases that we do love EDF... ;) > It does not look very nice > because Code Aster doesn't use Makefile but python scripts. I write about Code > Aster because I saw salome and Code Aster can be used together. I would be very interested to test your ebuilds when you consider them ready to be tested. Why don't you open a bug by then where you would store your ebuilds? > And to answer one of your question (cf salome-kernel-3.2.6.ebuild, "What is med > ?"), med is a part of the Code Aster software. Thanks! ;) > PS : Are you French or do you speak French ? Je suis Francais mais je vis en Suède.
Hello > - Did you make ebuilds for the whole serie? (the kernel and the rest). If yes, > can we try to merge our efforts (at least regarding the kernel)? Yep, and I'm merging our two salome-kernel ebuild. I think I can post it tomorow. > - You install things under /opt, isn't it? Why not /usr? Well, for these kind > of issues, I usually leave the final decision to the gentoo guys anyway... ;) It's just a choice. I think it is easier to uninstall some package and then delete the /opt/salome folder to be sure there is no more trace of these package and to test ebuild. We can use /usr later, it's just a thing to change in the ebuilds. > - Did you try any MPI support? The problem is the following: OpenFOAM needs > openmpi and salome uses mpich. As far as I remember, it is impossible to have > both installed at the same time... :( No, I didn't. I don't know what MPI support is. I'll make some research about it. > The kernel ebuild worked indeed flawlessly with einstall. I am cleaning it up > at the moment. What I just checked, considering that OpenCascade does _not_ use > the gcc4 flags anymore is that the salome-kernel can be built without the > append-flags. That basically means that the salome-gui can probably be built > without these flags as well (to be confirmed though). Compilation of salome-gui without this flag failed. > It seems to be kind of tricky indeed. Did you find anything about the sip issue > on various forums? No, not yet. It's a way that need to be explored. > > > If you have any suggestion, don't hesitate :-) > > > > Otherwise, I know that OpenCASCADE doesn't need anymore -ffriend-injection, > > because I also made a ebuild for it and don't use it. > > Can you compare your ebuild with the one we have on bugs.gentoo.org, that > Alvaro and I created? That would be interesting to see if we missed anything. I'll do that when I have time ;-) > > Aster because I saw salome and Code Aster can be used together. > > I would be very interested to test your ebuilds when you consider them ready to > be tested. Why don't you open a bug by then where you would store your ebuilds? My ebuilds are not finished. When it is the case, I'll submit them in a bug report. There is a old one I can reopen. > Je suis Francais mais je vis en Suède. Ok, je suis Français et je vis en France ^^
Created attachment 138048 [details] ebuild for kernel component
Created attachment 138578 [details] salome : MED component
Created attachment 138580 [details] Patch for MED component
Created attachment 138581 [details] salome : GEOM component
Created attachment 138582 [details] salome : SMESH component
Created attachment 138583 [details, diff] patch for SMESH component
Created attachment 138584 [details] salome : VISU component
Created attachment 138586 [details, diff] patch for VISU component
Created attachment 138588 [details] salome : SUPERV component
Francois, I reworked a bit the salome-kernel ebuild: - I added the flags and dependencies I had in my own ebuild - I corrected bugs with the /etc/env.d file (It was not created correctly and not put at the right place). I am still puzzled with your problems regarding the sandbox. I checked your ebuild and mine and noticed a few things: - I use econf, emake, einstall. You don't. I think the best way to get portage do what we want is to use the portage functions... - Right at the beginning of the ebuild I set a KERNEL_ROOT_DIR. You don't. The ebuild as it is now seems to work on my gcc 3.4.6. x86 box (It builds at least). I am planning to try to modify the ebuild according to what I wrote and see what happens... Cordialement, Daniel
Created attachment 138877 [details] Reworked salome-kernel to reflect the merge of Francois and Daniel's work
Created attachment 138896 [details] Reworked ebuild Francois, In this ebuild I tried to solve your issue with emake, econf etc... I am almost there... Make a diff between the precedent ebuild and this one and it will be apparent to you why you had issues with these commands (it had to do with where in the tree you called them). However! There is an issue with einstall (or emake install). It wants things to be installed under /usr when we want /opt/salome-3.2.6/KERNEL If you take a look at the way the configure command is called you will see that --prefix is defined 2 (!!!!!) times. This is wrong but I don't know where it comes from. ./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-tcl=/usr/lib/ --with-tk=/usr/lib/ --prefix=/opt/salome-3.2.6/KERNEL --infodir=/opt/salome-3.2.6/KERNEL/share/info --with-x --with-xmu-include=/usr/include --with-xmu-library=/usr/lib --with-gl-include=/usr/include --with-gl-library=/usr/lib --disable-debug --enable-production --without-cppunit --build=i686-pc-linux-gnu Can you take a look at this? Daniel
Hi Daniel, Thanks for your modifications. Concerning the --prefix flag which appears 2 times, I think it is normal when we use econf. econf defines a lot of default flags (--prefix --bindir --libdir etc...) : 1) to avoid ebuild writer to have to write it themselves ;-) 2) to avoid ebuild writer to have to ask question like "where must I put lib/executable/doc files ?". There are two ways if we want to override the default values : 1) use configure script instead econf and define flags by ourselves 2) pass flags to the econf call. I'm not sure but in case of repeated flags, the flag taken into account is the last flag of the command line. In our case, for --prefix it is --prefix=/opt/salome/KERNEL. I believe it is the default behavior for configure script generated by autoconf tool. Anyway, I'm testing your last ebuild. It is compiling ^^. Oh, I try to use salome. The GEOM module seems to working. I can create objects and geometries. But I can't mesh them. I've an exception "SEGMENTATION FAULT". I hope this is due to a bad installation. And last think. The compilation have just finished and failed. The error message : /usr/bin/install -c -d /usr/lib/python2.4/site-packages/salome /usr/bin/install: Ne peut changer les permissions de `/usr/lib/python2.4/site-packages/salome': Aucun fichier ou répertoire de ce type But the /usr/lib/python2.4/site-packages exists. I'm asking if the problem is not related with sandbox. Have you sandbox enabled ? Can you check the value of the variable FEATURES in /etc/make.conf ? If you see "-sandbox" then sandbox is disabled. "sandbox" means sandbox is activated. If nor "sandbox" nor "-sandbox" are present, can you add "sandbox" to activate it and re-emerge the kernel component ?
Hello Francois, > Thanks for your modifications. > > Concerning the --prefix flag which appears 2 times, I think it is normal when > we use econf. econf defines a lot of default flags (--prefix --bindir --libdir > etc...) : > 1) to avoid ebuild writer to have to write it themselves ;-) > 2) to avoid ebuild writer to have to ask question like "where must I put > lib/executable/doc files ?". > > There are two ways if we want to override the default values : > 1) use configure script instead econf and define flags by ourselves That does not sound 'the gentoo way'. I am pretty sure the econf mecanism is there to help such kind of issues. There is just something we are missing. > 2) pass flags to the econf call. I'm not sure but in case of repeated flags, > the flag taken into account is the last flag of the command line. In our case, > for --prefix it is --prefix=/opt/salome/KERNEL. I believe it is the default > behavior for configure script generated by autoconf tool. And that's the core question, as a matter of fact. How does it really behave with two contradictory --prefix? > Anyway, I'm testing your last ebuild. It is compiling ^^. I know. Things get screwed just after that... > Oh, I try to use salome. The GEOM module seems to working. I can create objects > and geometries. But I can't mesh them. I've an exception "SEGMENTATION FAULT". > I hope this is due to a bad installation. What I am trying to do is to build the thing here as well and see what I get. Then we can compare our experiences. > And last think. The compilation have just finished and failed. The error > message : > /usr/bin/install -c -d /usr/lib/python2.4/site-packages/salome > /usr/bin/install: Ne peut changer les permissions de > `/usr/lib/python2.4/site-packages/salome': Aucun fichier ou répertoire de ce > type > > But the /usr/lib/python2.4/site-packages exists. I'm asking if the problem is > not related with sandbox. Have you sandbox enabled ? Can you check the value of > the variable FEATURES in /etc/make.conf ? FEATURES="sandbox ccache distcc distlocks autoaddcvs -userfetch" I have sandbox. > If you see "-sandbox" then sandbox is disabled. "sandbox" means sandbox is > activated. If nor "sandbox" nor "-sandbox" are present, can you add "sandbox" > to activate it and re-emerge the kernel component ? I think the problem is due to the fact that it tries to install files under /usr when it should install them in the /var/tmp/..../build area. Therefore the violation. It tries to copy file instead of generating the packet.... Daniel
Francois, Look at this. It says quite a lot... econf is not as "automagically" as I expected it to be... src_install() { # You must *personally verify* that this trick doesn't install # anything outside of DESTDIR; do this by reading and # understanding the install part of the Makefiles. # This is the preferred way to install. emake DESTDIR="${D}" install || die "emake install failed" # When you hit a failure with emake, do not just use make. It is # better to fix the Makefiles to allow proper parallelization. # If you fail with that, use "emake -j1", it's still better than make. # For Makefiles that don't make proper use of DESTDIR, setting # prefix is often an alternative. However if you do this, then # you also need to specify mandir and infodir, since they were # passed to ./configure as absolute paths (overriding the prefix # setting). #emake \ # prefix="${D}"/usr \ # mandir="${D}"/usr/share/man \ # infodir="${D}"/usr/share/info \ # libdir="${D}"/usr/$(get_libdir) \ # install || die "emake install failed" # Again, verify the Makefiles! We don't want anything falling # outside of ${D}. # The portage shortcut to the above command is simply: # #einstall || die "einstall failed" }
Thanks Daniel. The documentation contains a lot of information. But it doesn't explain why emerge fails when sandbox is enable on my computer and works perfectly for you ! I'll look inside the Makefiles to try to make a patch. I hope there are not many and many makefiles :-)
(In reply to comment #55) > Thanks Daniel. The documentation contains a lot of information. But it doesn't > explain why emerge fails when sandbox is enable on my computer and works > perfectly for you ! I think I got the answer to that: In my original ebuild, I put things under /usr (that is to say, where the --prefix was originally set). So, the holy trilogy (econf emake einstall) worked flawlessly. What you did is that you set the installation path to something else, and this is where the pain started... Things got mixed up and the sandbox warning is just reflecting that. Normal procedure: image generation, package building, installation What is happening to you: direct installation, therefore the sandbox warning. > I'll look inside the Makefiles to try to make a patch. I hope there are not > many and many makefiles :-) In the salome_adm/unix files is the answer. I think somehow we need to go to the root of this and change the prefix there, not in the ebuild. Daniel
Francois > I'll look inside the Makefiles to try to make a patch. I hope there are not > many and many makefiles :-) Try to use 'sed' in the ebuild if possible. It will be easier later on, to rework the installation directory.
Francois, > #emake \ > # prefix="${D}"/usr \ > # mandir="${D}"/usr/share/man \ > # infodir="${D}"/usr/share/info \ > # libdir="${D}"/usr/$(get_libdir) \ > # install || die "emake install failed" I am experimenting with this at the moment. It seems to have some positive effect (the prefix at least... ;) )
I checked the generated Makefile when configure with 2 --prefix flags. And the --prefix is /usr and not /opt/salome/KERNEL ! The problem must be here. So I'm searching a solution. Otherway, we can use the "standard" /usr prefix. It must solve the problem. I don't this that to change the default path could create errors like that. It's crazy ! I'll try without prefix and use the default location to see if there is an error during the compilation.
Well, I don't know how it can work but I'll try this too. Hope hope hope...
Created attachment 138925 [details] A little step further with salome-kernel Hello, This one corrected a few bugs (noticeably the version of Salome (which was 3.2.5 instead of 3.2.6)) and is an attempt to get the einstall issue worked out (it's half way through... :( )
Well, salome-kernel is still compiling, I'm waiting ^^ The Gentoo documentation says the prefered way to install a package is to use "make DESTDIR=${D} install" instead "einstall". (cf. http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1) So, if "make DESTDIR" works, I think it is not necessary to use einstall. What do you think ?
Here is what I get now. How to solve that is probably how to make sure that all libraries are installed correctly (some flag in the emake install) /usr/bin/install -c -m 644 'LocalTraceBufferPool.hxx' '/var/tmp/portage/sci-misc/salome-kernel-3.2.6/image///opt/salome-3.2.6/KERNEL/include/salome/LocalTraceBufferPool.hxx' /usr/bin/install -c -m 644 'BaseTraceCollector.hxx' '/var/tmp/portage/sci-misc/salome-kernel-3.2.6/image///opt/salome-3.2.6/KERNEL/include/salome/BaseTraceCollector.hxx' libtool: install: error: cannot install `libSALOMELocalTrace.la' to a directory not ending in /opt/salome-3.2.6/KERNEL
(In reply to comment #62) > Well, salome-kernel is still compiling, I'm waiting ^^ > > The Gentoo documentation says the prefered way to install a package is to use > "make DESTDIR=${D} install" instead "einstall". (cf. > http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1) > > So, if "make DESTDIR" works, I think it is not necessary to use einstall. What > do you think ? emake DESTDIR=${D} install I would say. OK. Time to hit the sack now. Bonne nuit!
emerge the ebuild with the standard "/usr" prefix failed too. Always the same error. I'm trying to make a patch for the corresponding Makefile.
Created attachment 138960 [details] salome-kernel. A new trial This one works with /usr
Crazy things! This works #local myconf="--prefix=${INSTALL_DIR} --with-tcl=/usr/lib/ --with-tk=/usr/lib/" local myconf="--with-tcl=/usr/lib/ --with-tk=/usr/lib/" This does not... local myconf="--prefix=${INSTALL_DIR} --with-tcl=/usr/lib/ --with-tk=/usr/lib/" #local myconf="--with-tcl=/usr/lib/ --with-tk=/usr/lib/" This works! einstall || die "einstall failed" # emake DESTDIR="${D}" install || die "emake install failed" This does not! #einstall || die "einstall failed" emake DESTDIR="${D}" install || die "emake install failed" So, how do we set up the --prefix and how do we make sure that the emake install works accordingly? Daniel
Created attachment 139043 [details] A new attempt Francois, I don't think I am far off now. Please take a look at what I did. There is still something missing regarding the location of the documentation. Can you please give it some try as well during Xmas holiday? Best regards Daniel
Created attachment 139045 [details] salome-kernel (This one works with a specified --prefix) Hello Francois, Please welcome the salome-kernel ebuild where you can actually specifiy where you want things to be installed... ;) That one was a tricky one... :( But now it works!!!! :) So, here is what I propose: - Check again this corba stuff in the ebuild to see if it can included somewhere else in a more elegant way (we specified a corba flag besides). - Check if all the files are there (you had a list of missing files) - Do the same things to all the other ones to simplify them (basically get rid of the long list of files at the end). What do you think? Daniel
Hello Daniel, First, sorry to have take time to answer but it is difficult to have an internet connection. I'm already in holidays in my Normandie ^^. I will test your ebuild now and put my commentaries as soon as possible. Best regards François
Well, I've just tested your ebuild. It works fine, but I must confess I don't know why !! It's really crazy ;-) Everything seems ok. The install works fine with sandbox. I think we can adjust the dependencies. For exemple, netgen is not necessary. Dependence of netgen is done via a plugin. And I think there is other dependencies which depend of use flags.
Problems with salome-gui The salome-gui configuration procedure do not find qwt: --------------------------------------------- Testing qwt --------------------------------------------- configure: checking for qwt... QWTHOME not defined checking for /usr/local/lib/libqwt.so... no checking for /usr/lib/libqwt.so... no no configure: WARNING: qwt not found This leads to compilation problems later on: /var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/src/Plot2d/Plot2d_Curve.h:25:22: qwt_plot.h: No such file or directory In file included from /var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/src/Plot2d/Plot2d_Curve.cxx:19: /var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/src/Plot2d/Plot2d_Curve.h:67: error: expected `,' or `...' before '&' token /var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/src/Plot2d/Plot2d_Curve.h:67: error: ISO C++ forbids declaration of `QStringList' with no type etc etc.... with a crash at the end. # locate qwt_plot.h /usr/share/doc/qwt-5.0.2-r1/html/class_qwt_plot.html /usr/share/doc/qwt-4.2.0-r3/html/class_qwt_plot.html /usr/include/qwt/qwt_plot.h /usr/include/qwt5/qwt_plot.h and # locate libqwt.so /usr/lib/libqwt.so.4.2 /usr/lib/libqwt.so.5.0 /usr/lib/libqwt.so.4 /usr/lib/libqwt.so.5 /usr/lib/libqwt.so.4.2.0 /usr/lib/libqwt.so.5.0.2 show that libqwt is there. It is simply not 'seen' Do you know how to solve that elegantly? Daniel
Hello, > # locate libqwt.so > /usr/lib/libqwt.so.4.2 > /usr/lib/libqwt.so.5.0 > /usr/lib/libqwt.so.4 > /usr/lib/libqwt.so.5 > /usr/lib/libqwt.so.4.2.0 > /usr/lib/libqwt.so.5.0.2 > > show that libqwt is there. It is simply not 'seen' > > Do you know how to solve that elegantly? re-emerge qwt, solved this particular issue. Daniel
But I end up with this. Any idea? cd SALOME_PY ; make lib make[3]: Entering directory `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/build/src/SALOME_PY' rm -fr .libs/libSalomePy.la .libs/libSalomePy.* .libs/libSalomePy.* gcc -shared SalomePy.lo SALOMEDSSK.lo SALOMEDS_AttributesSK.lo SALOME_ExceptionSK.lo SALOME_GenericObjSK.lo -L../../lib/salome -lstdc++ -L/usr/lib/python2.4/config -lpython2.4 -ldl -lutil -L/usr/qt/3/lib -lqt-mt -L/usr/lib/vtk -L/usr/lib/vtk/python -lvtkCommon -lvtkGraphics -lvtkImaging -lvtkFiltering -lvtkIO -lvtkRendering -lvtkHybrid -lGL -lGLU -lX11 -lXt -lGL -lGLU -lSalomeApp -lvtkCommonPython -lvtkGraphicsPython -lvtkImagingPython -lnsl -lm -ldl -lc -Wl,-soname -Wl,libSalomePy.so.0 -o .libs/libSalomePy.so.0.0.0 /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/../../../../i686-pc-linux-gnu/bin/ld: cannot find -lvtkCommonPython collect2: ld returned 1 exit status make[3]: *** [libSalomePy.la] Error 1 make[3]: Leaving directory `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/build/src/SALOME_PY' make[2]: *** [lib_SALOME_PY] Error 2 make[2]: Leaving directory `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/build/src' make[1]: *** [lib_src] Error 2 make[1]: Leaving directory `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/build' make: *** [all] Error 2
Hello, It turns out that I had a patch against that. Francois, considering that your system is more generic than what I used (you consider vtk4 and vtk5 when I only considered vtk5), can you try to develop your patch with regard to what I used? Thanks in advance Daniel --- GUI_SRC_3.2.6/adm_local/unix/config_files/check_vtk.m4.org 2007-04-24 18:41:04.000000000 +0200 +++ GUI_SRC_3.2.6/adm_local/unix/config_files/check_vtk.m4 2007-05-26 12:32:50.000000000 +0200 @@ -76,7 +76,7 @@ if test -z $VTKHOME then AC_MSG_WARN(undefined VTKHOME variable which specify where vtk was compiled) - if test -f /usr/include/vtk/vtkPlane.h ; then + if test -f /usr/include/vtk-5.0/vtkPlane.h ; then AC_MSG_RESULT(trying /usr) VTKHOME="/usr" fi @@ -84,9 +84,9 @@ if test ! -z $VTKHOME then - LOCAL_INCLUDES="-I$VTKHOME/include/vtk $LOCAL_INCLUDES" - LOCAL_LIBS="-L$VTKHOME/lib${LIB_LOCATION_SUFFIX}/vtk -L$VTKHOME/lib${LIB_LOCATION_SUFFIX}/vtk/python $LOCAL_LIBS" - TRY_LINK_LIBS="-L$VTKHOME/lib${LIB_LOCATION_SUFFIX}/vtk -L$VTKHOME/lib${LIB_LOCATION_SUFFIX}/vtk/python $TRY_LINK_LIBS" + LOCAL_INCLUDES="-I$VTKHOME/include/vtk-5.0 $LOCAL_INCLUDES" + LOCAL_LIBS="-L$VTKHOME/lib${LIB_LOCATION_SUFFIX}/vtk-5.0 -L/usr/lib/python2.4/site-packages/vtk $LOCAL_LIBS" + TRY_LINK_LIBS="-L$VTKHOME/lib${LIB_LOCATION_SUFFIX}/vtk-5.0 -L/usr/lib/python2.4/site-packages/vtk/ $TRY_LINK_LIBS" fi dnl vtk headers @@ -142,4 +142,4 @@ # Save cache AC_CACHE_SAVE -])dnl \ No newline at end of file +])dnl
Please add dependency to bug #155424 as I do not have permission to do so.
Hi Daniel, What ebuild did you use ? Mine or your ? On my machine, I have just vtk-5. Not 4. So, I don't know if compilation works. And I've just realize that the vtk-5 patch must be applicated only when vtk-5 is detected :-) I remember I had some problem about missing include files. Adding /usr/include/vtk-5 to include search path solve the problem. Did you try it ? Otherwise, have you got problems with sip ?
Daniel, I have a question about salome-kernel. When installing the component, and if you execute the runSalome script, does python complain about a missing module ? I ask you the question because you comment the line in my ebuild which correct the bug for me. So have you also this problem ?
oups, the script is runSalome.py and not runSalome. Sorry for the mistake.
(In reply to comment #76) > Please add dependency to bug #155424 as I do not have permission to do so. What do you mean Jon? The dependency to netgen is specified in the salome-kernel ebuild (that I partly wrote). Francois mentionned that the netgen-salome link is a module issue. So it might turns out that the netgen support becomes a flag. We will see in the future when we will adjust the ebuilds (we are still trying to get the thing compiled) Daniel
Salut Francois, > Hi Daniel, > > What ebuild did you use ? Mine or your ? Yours, with your patches (even though I had also an ebuild and a set of patches on my side, see the previous comments in this thread). > On my machine, I have just vtk-5. Not 4. So, I don't know if compilation works. I am also trying with vtk5. I don't think vtk4 will ever be seen on gentoo (we might have to consider this fact and get rid of the vtk5 warning). In fact the problem is that salome 3.2.6 has been written for vtk4, not vtk5. This leads to some compilation issue. > And I've just realize that the vtk-5 patch must be applicated only when vtk-5 > is detected :-) That sounds reasonable... ;) However, as I said, I don't think Markus will ever bring vtk4 to gentoo. To get vtk4 and vtk5 in parallel seems to be a daunting task he is not really willing to deal with (lack of time, I suppose). > I remember I had some problem about missing include files. Adding > /usr/include/vtk-5 to include search path solve the problem. Did you try it ? As I said, I am using your ebuild. However, I think I will reinteger the patch I mentionned a few message ago. > Otherwise, have you got problems with sip ? I haven't got that far... :( Daniel
Francois, > Daniel, I have a question about salome-kernel. When installing the component, > and if you execute the runSalome script, does python complain about a missing > module ? Here is what I get. Is it what you meant? /opt/salome-3.2.6/KERNEL/bin/salome $ ./runSalome.py Configure parser: Warning : could not find user configuration file Searching for a free port for naming service: 2810 - OK Traceback (most recent call last): File "./runSalome.py", line 984, in ? clt,args = main() File "./runSalome.py", line 975, in main searchFreePort(args, save_config) File "./runSalome.py", line 927, in searchFreePort import CORBA ImportError: No module named CORBA > I ask you the question because you comment the line in my ebuild which correct > the bug for me. So have you also this problem ? I suppose the commenting was a mistake from my side. It's probably because I did not really get why it was there and thought "OK, I'll dealt with that later on". If you bring it back, how does it behave? Daniel
(In reply to comment #81) > > As I said, I am using your ebuild. However, I think I will reinteger the patch > I mentionned a few message ago. What absent minded I am ! I totaly forgot I created some symlinks ! I create a symlink libvtkCommonPython.so to libvtkCommonPythonD.so. There are symlinks I created manually : - libvtkCommonPython.so -> libvtkCommonPythonD.so - libvtkGraphicsPython.so -> libvtkGraphicsPythonD.so - libvtkImagingPython.so -> libvtkImagingPythonD.so I hope I forget nothing ;-) Well, I suppose we have to patch some Makefile to use the correct library rather create symlinks. Can you create these symlink in /usr/lib to verify that it solves your problem ?
(In reply to comment #82) > > Here is what I get. Is it what you meant? > Exactly. We have to tell to python interpreter that the module CORBA is from omniORB.
Hello again, > What absent minded I am ! I totaly forgot I created some symlinks ! I create a > symlink libvtkCommonPython.so to libvtkCommonPythonD.so. > > There are symlinks I created manually : > - libvtkCommonPython.so -> libvtkCommonPythonD.so > - libvtkGraphicsPython.so -> libvtkGraphicsPythonD.so > - libvtkImagingPython.so -> libvtkImagingPythonD.so > > I hope I forget nothing ;-) > > Well, I suppose we have to patch some Makefile to use the correct library > rather create symlinks. > > Can you create these symlink in /usr/lib to verify that it solves your problem > ? I tried something else (and it seems to work), I patched the check_vtk.m4 file to tell exactly where these libraries are (because they do exist, they are just not found because the path is wrong in the check_vtk.m4 file) Daniel
(In reply to comment #84) > (In reply to comment #82) > > > > Here is what I get. Is it what you meant? > > > Exactly. We have to tell to python interpreter that the module CORBA is from > omniORB. So, the thing that I commented out should be brought back then... ;) Daniel
Created attachment 139956 [details] Reworked GUI This one works for me. I will try to simplify it as I did with salome-kernel
Created attachment 139958 [details, diff] A modified patch A slightly modified patch (takes care of the check_vtk.m4 issue)
Created attachment 139964 [details] A slightly modified patch to fit the needs of the new ebuild.
Created attachment 139965 [details] A reworked ebuild. Not functional though.... :( Francois, I tried to applied to the GUI ebuild what was applied to the KERNEL one (basically the possibility to install it wherever we want, without this sandbox trick of yours) The structure is there but it does not work... :( Please see this: --------------------------------------------- Testing Kernel --------------------------------------------- configure: checking for Kernel... ./configure: line 15585: test: too many arguments configure: WARNING: "Cannot find compiled Kernel module distribution" for Kernel: no Which is strange (note however that I call econf with, indeed, a lot of options...) I also got the following: config.status: creating ./adm_local/unix/make_commence config.status: WARNING: /var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/adm_local/unix/make_commence.in seems to ignore the --datarootdir setting config.status: creating ./adm_local/unix/make_conclude config.status: creating ./salome_adm/unix/make_module and finally: make[3]: Leaving directory `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/src/SUPERVGraph' cd LightApp ; make lib make[3]: Entering directory `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/src/LightApp' make[3]: *** No rule to make target `HDFexplorer.hxx', needed by `LightApp_HDFDriver.lo'. Stop. make[3]: Leaving directory `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/src/LightApp' make[2]: *** [lib_LightApp] Error 2 make[2]: Leaving directory `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/src' make[1]: *** [lib_src] Error 2 make[1]: Leaving directory `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6' make: *** [all] Error 2 I don't know if all these issues are related though. Any idea? Daniel
I will test your ebuild and your patch to see exactly what happened.
I solved some of the issues there. The trick was to use: econf --prefix=${INSTALL_DIR} --docdir=${INSTALL_DIR}/share/doc/salome --infodir=${INSTALL_DIR}/share/info ${myconf} || die "configuration failed" instead of econf --prefix=${INSTALL_DIR} --docdir=${INSTALL_DIR}/share/doc/salome --infodir=${INSTALL_DIR}/share/info "${myconf}" || die "configuration failed" (note the quote around ${myconf}...) I end up with this: >>> Install salome-gui-3.2.6 into /var/tmp/portage/sci-misc/salome-gui-3.2.6/image/ category sci-misc /usr/bin/install -c -d /usr/share/salome/resources/gui ACCESS DENIED mkdir: /usr/share/salome /usr/bin/install -c -d /var/tmp/portage/sci-misc/salome-gui-3.2.6/image///opt/salome-3.2.6/GUI/bin/salome /usr/bin/install -c -d /var/tmp/portage/sci-misc/salome-gui-3.2.6/image///opt/salome-3.2.6/GUI/include/salome (/usr/bin/install -c -d /var/tmp/portage/sci-misc/salome-gui-3.2.6/image///opt/salome-3.2.6/GUI/salome_adm/unix || exit 1); /usr/bin/install -c ./bin/VERSION ./bin/runLightSalome.csh ./bin/runLightSalome.sh /var/tmp/portage/sci-misc/salome-gui-3.2.6/image///opt/salome-3.2.6/GUI/bin/salome (sed 's/^prefix=/#prefix=/' ./adm_local/unix/make_commence > /var/tmp/portage/sci-misc/salome-gui-3.2.6/image///opt/salome-3.2.6/GUI/salome_adm/unix/make_commence || exit 1); /usr/bin/install: cannot create directory `/usr/share/salome': Permission denied make: *** [install-resources] Error 1 make: *** Waiting for unfinished jobs.... * * ERROR: sci-misc/salome-gui-3.2.6 failed. * Call stack: * ebuild.sh, line 1701: Called dyn_install * ebuild.sh, line 1138: Called qa_call 'src_install' * ebuild.sh, line 44: Called src_install * salome-gui-3.2.6.ebuild, line 196: Called die * The specific snippet of code: * emake prefix="${D}"/"${INSTALL_DIR}" docdir="${D}"/${INSTALL_DIR}/share/doc/salome infodir="${D}"/"${INSTALL_DIR}"/share/info install || die "emake install failed" * The die message: * emake install 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/salome-gui-3.2.6/temp/build.log'. * This ebuild is from an overlay: '/usr/local/portage/' * --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/var/log/sandbox/sandbox-sci-misc_-_salome-gui-3.2.6-3790.log" mkdir: /usr/share/salome -------------------------------------------------------------------------------- It seems that somehow, I need to declare a 'share' directory. Daniel PS: This is still there. > I also got the following: > config.status: creating ./adm_local/unix/make_commence > config.status: WARNING: > /var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/adm_local/unix/make_commence.in > seems to ignore the --datarootdir setting > config.status: creating ./adm_local/unix/make_conclude > config.status: creating ./salome_adm/unix/make_module Daniel
Created attachment 139973 [details] That one seems to work... :) The problem mentionned above have disappeared. This ebuild remains to be thoroughly tested though but the transition to the 'holy' econf/emake/einstall has been done. No need anymore to add a list of file to be added to the package... ;) Daniel
> The problem mentionned above have disappeared. Cool ! And a good news is that I have found a way to resolve the sip problem more properly ! I will make a patch and post the new ebuild and the new patch. But before doing this, I have to test it to check that all works fine ;-)
OK. This will be probably my last comment for the day... ;) First we need to add to the KERNEL and GUI ebuild the following line: echo "PATH=${INSTALL_DIR}/bin/salome" >> ./90${P} to add the path to salome to the searching list. It would give something like: echo "${MODULE_NAME}_ROOT_DIR=${INSTALL_DIR}" > ./90${P} echo "LDPATH=${INSTALL_DIR}/lib/salome" >> ./90${P} echo "PATH=${INSTALL_DIR}/bin/salome" >> ./90${P} dodir /etc/env.d insinto /etc/env.d doins 90${P} Now, here is the interesting part, so to say, When I run runLightSalome.csh I get: /opt/salome-3.2.6/GUI/bin/salome $ File cannot be opened QtxResourceMgr: Could not load resource file "/home/ted/.LightApprc.3.2.6" File cannot be opened QtxResourceMgr: Could not load resource file "/opt/salome-3.2.6/GUI/share/salome/resources/gui/LightApp.xml" Language not specified. Assumed: en and I get a 'Can not load application library "libLightApp.so": /opt/salome-3.2.6/GUI/lib/salome/libPlot2d.so.0: undefined symbol: _ZN7QwtPlot12drawContentsEP8QPainter Any idea on this one? Daniel
(In reply to comment #95) > OK. This will be probably my last comment for the day... ;) > > First we need to add to the KERNEL and GUI ebuild the following line: > echo "PATH=${INSTALL_DIR}/bin/salome" >> ./90${P} > to add the path to salome to the searching list. > > It would give something like: > echo "${MODULE_NAME}_ROOT_DIR=${INSTALL_DIR}" > ./90${P} > echo "LDPATH=${INSTALL_DIR}/lib/salome" >> ./90${P} > echo "PATH=${INSTALL_DIR}/bin/salome" >> ./90${P} > dodir /etc/env.d > insinto /etc/env.d > doins 90${P} > Ok, it's not really a problem ;-) > Now, here is the interesting part, so to say, > > When I run runLightSalome.csh > I get: > /opt/salome-3.2.6/GUI/bin/salome $ File cannot be opened > QtxResourceMgr: Could not load resource file "/home/ted/.LightApprc.3.2.6" > File cannot be opened > QtxResourceMgr: Could not load resource file > "/opt/salome-3.2.6/GUI/share/salome/resources/gui/LightApp.xml" > Language not specified. Assumed: en > > and I get a 'Can not load application library "libLightApp.so": > /opt/salome-3.2.6/GUI/lib/salome/libPlot2d.so.0: undefined symbol: > _ZN7QwtPlot12drawContentsEP8QPainter > > Any idea on this one? > Well, I had a similar error with the SMESH component when I tried to mesh a simple geometry. To be honest, I look at the source of salome and I believe some feature are not yet implemented. I saw some code like : if (foo == bar) { // foo == bar } else { // foo != bar } with no statement in the both cases ! I hoped the problem was due to a wrong installation but I doubt.
Hello, > > First we need to add to the KERNEL and GUI ebuild the following line: > > echo "PATH=${INSTALL_DIR}/bin/salome" >> ./90${P} > > to add the path to salome to the searching list. > Ok, it's not really a problem ;-) Not really indeed... ;) I think I start the thing the wrong way. I suppose I should start 'runSalome' but then, I have this corba issue. Could you please modify the kernel ebuild tonight and bring back the Corba thing. If sed is problematic, try 'dosed'. I will retest the whole thing tomorrow. > I hoped the problem was due to a wrong installation but I doubt. We have not ruled this out yet... ;) Daniel
Created attachment 140002 [details] working salome-kernel ebuild
Created attachment 140005 [details] new salome-gui ebuild
Created attachment 140007 [details, diff] patch for salome-gui component to be use with sip-4.1.7
Created attachment 140030 [details] A few minor changes. Francois, I slightly modified the kernel ebuild you produced yesterday. Here are my motivations: Opencascade and docutils are required. So I brought them back in the dependencies. When the kernel is built, you'll see at the beginning a list of the required libraries/utilities. Regarding DEPEND vs RDEPEND, the Gentoo developer guide is clear (http://devmanual.gentoo.org/general-concepts/dependencies/index.html) but it is not really clear in my mind where our dependencies should be (Runtime dependent vs compile). So, I suppose your changes are right... ;) Daniel PS: $ runSalome Configure parser: Warning : could not find user configuration file Searching for a free port for naming service: 2810 2811 - OK Lancement du Naming Service runNS.sh > /tmp/logs/ted/salomeNS.log 2>&1 Searching Naming Service + found in 0.1 seconds Searching /Registry in Naming Service +th. 3075180224 ------- SALOME_Registry_Server.cxx [57] : Begin of: SALOME_Registry_Server th. 3075180224 COMPILED with SALOME_Registry_Server.cxx [58] : g++, Jan 4 2008 at 09:55:33 th. 3075180224 - Trace SALOME_Registry_Server.cxx [59] : argc=3 th. 3075180224 - Trace SALOME_NamingService.cxx [50] : SALOME_NamingService default constructor th. 3075180224 - Trace SALOME_Registry_Server.cxx [130] : Registry Server: Naming Service was found th. 3075180224 - Trace SALOME_NamingService.cxx [95] : SALOME_NamingService initialisation th. 3075180224 - Trace RegistryService.cxx [49] : Passage dans RegistryService::RegistryService() th. 3075180224 - Trace SALOME_NamingService.cxx [384] : Resolve() : Registry (object) not found th. 3075180224 - Trace SALOME_NamingService.cxx [128] : BEGIN OF Register: /Registry th. 3075180224 - Trace SALOME_Registry_Server.cxx [189] : On attend les requetes des clients th. 3075180224 - Trace SALOME_Registry_Server.cxx [193] : Activation du POA th. 3075180224 - Trace SALOME_Registry_Server.cxx [197] : Lancement de l'ORB found in 0.5 seconds Searching /Kernel/ModulCatalog in Naming Service +th. 3062683328 - Trace SALOME_ModuleCatalog_Server.cxx [100] : Module Catalog Server: Naming Service was found th. 3062683328 - Trace SALOME_ModuleCatalog_impl.cxx [54] : Catalog creation th. 3062683328 ------- SALOME_ModuleCatalog_impl.cxx [558] : Begin of: _parse_xml_file th. 3062683328 - Trace SALOME_ModuleCatalog_impl.cxx [559] : file=/opt/salome-3.2.6/KERNEL/share/salome/resources/kernel/KERNELCatalog.xml th. 3062683328 - Trace SALOME_ModuleCatalog_impl.cxx [132] : General path list OK th. 3062683328 ------- SALOME_ModuleCatalog_impl.cxx [558] : Begin of: _parse_xml_file th. 3062683328 - Trace SALOME_ModuleCatalog_impl.cxx [559] : file=/home/ted/Salome/resources/CatalogModulePersonnel.xml th. 3062683328 - Trace SALOME_ModuleCatalog_impl.cxx [148] : Personal path list OK th. 3062683328 - Trace SALOME_NamingService.cxx [65] : SALOME_NamingService creation th. 3062683328 - Trace SALOME_NamingService.cxx [128] : BEGIN OF Register: /Kernel/ModulCatalog th. 3062683328 - Trace SALOME_ModuleCatalog_Server.cxx [154] : Running CatalogServer. found in 0.5 seconds RunStudy Searching /myStudyManager in Naming Service +th. 3015678336 - Trace SALOMEDS_Server.cxx [52] : SALOMEDS_Server - main th. 3015678336 - Trace SALOMEDS_Server.cxx [108] : SalomeDS Server: Naming Service was found th. 3015678336 - Trace SALOME_NamingService.cxx [65] : SALOME_NamingService creation th. 3015678336 - Trace SALOME_NamingService.cxx [749] : BEGIN OF Create_Directory th. 3015678336 - Trace SALOME_NamingService.cxx [128] : BEGIN OF Register: /Study/ th. 3015678336 - Trace SALOME_NamingService.cxx [65] : SALOME_NamingService creation th. 3015678336 - Trace SALOME_NamingService.cxx [128] : BEGIN OF Register: /myStudyManager found in 0.5 seconds Searching /Containers/paris/FactoryServer in Naming Service +th. 3061425856 COMPILED with SALOME_ContainerManagerServer.cxx [31] : g++, Jan 4 2008 at 09:56:37 th. 3061425856 ------- SALOME_ContainerManagerServer.cxx [32] : Begin of: SALOME_ContainerManagerServer th. 3061425856 - Trace SALOME_ContainerManager.cxx [48] : constructor th. 3061425856 - Trace SALOME_NamingService.cxx [65] : SALOME_NamingService creation th. 3061425856 - Trace SALOME_NamingService.cxx [65] : SALOME_NamingService creation th. 3061425856 - Trace SALOME_ResourcesCatalog_Handler.cxx [48] : SALOME_ResourcesCatalog_Handler creation th. 3061425856 - Trace SALOME_NamingService.cxx [128] : BEGIN OF Register: /ContainerManager th. 3061425856 - Trace SALOME_ContainerManager.cxx [71] : constructor end th. 3061692096 COMPILED with SALOME_Container.cxx [76] : g++, Jan 4 2008 at 09:56:33 th. 3061692096 ------- SALOME_Container.cxx [77] : Begin of: SALOME_Container th. 3061692096 - Trace SALOME_Container.cxx [80] : argv[1]=FactoryServer th. 3061692096 - Trace Container_init_python.cxx [50] : ================================================================= th. 3061692096 - Trace Container_init_python.cxx [51] : Python Initialization... th. 3061692096 - Trace Container_init_python.cxx [52] : ================================================================= th. 3061692096 - Trace Container_init_python.cxx [60] : KERNEL_PYTHON::_gtstate=0x806c870 LocalTraceBufferPool::retrieve, sem_wait: Interrupted system call th. 3061692096 - Trace Container_i.cxx [123] : paris 19997 Engines_Container_i starting argc 2 Thread 3061692096 th. 3061692096 - Trace Container_i.cxx [128] : argv0 SALOME_Container th. 3061692096 - Trace Container_i.cxx [128] : argv1 FactoryServer th. 3061692096 - Trace Container_i.cxx [137] : argv[1]=FactoryServer th. 3061692096 - Trace SALOME_NamingService.cxx [50] : SALOME_NamingService default constructor th. 3061692096 - Trace SALOME_NamingService.cxx [95] : SALOME_NamingService initialisation th. 3061692096 - Trace Container_i.cxx [164] : _containerName=/Containers/paris/FactoryServer th. 3061692096 - Trace SALOME_NamingService.cxx [128] : BEGIN OF Register: /Containers/paris/FactoryServer th. 3061692096 - Trace Container_i.cxx [167] : Engines_Container_i::Engines_Container_i : Container name /Containers/paris/FactoryServer th. 3061692096 - Trace Container_i.cxx [178] : myCommand=pyCont = SALOME_Container.SALOME_Container_i('/Containers/paris/FactoryServer','IOR:010000001a00000049444c3a456e67696e65732f436f6e7461696e65723a312e30000000010000000000000068000000010102000f0000003135302e32323... found in 0.5 seconds Start SALOME, elapsed time : 2.2 seconds additional external python interpreters: 0 th. 3061692096 - Trace SALOME_FileTransfer_i.cxx [38] : fileTransfer_i::fileTransfer_i
(In reply to comment #101) > Created an attachment (id=140030) [edit] > A few minor changes. > > Francois, > > I slightly modified the kernel ebuild you produced yesterday. > Here are my motivations: > Opencascade and docutils are required. So I brought them back in the > dependencies. When the kernel is built, you'll see at the beginning a list of > the required libraries/utilities. > Oups, I made a mistake about opencascase ! I forgot do add the dependency ! OpenCascase is intalled on my computer, but I did it manually. So, I don't have an ebuild for opencascade in my portage tree. For docutils I don't know. I don't remember I cut this dependence. It must be again a wrong manipulation from myself. > Regarding DEPEND vs RDEPEND, the Gentoo developer guide is clear > (http://devmanual.gentoo.org/general-concepts/dependencies/index.html) but it > is not really clear in my mind where our dependencies should be (Runtime > dependent vs compile). So, I suppose your changes are right... ;) I hope ^^. And it's true it's not easy to have the correct dependencies !
Created attachment 140032 [details] salome-gui, a few minor changes Francois, Thank you very much for the great work on the salome-gui ebuild. I have built it without problems with the new patch and I have also slightly modified it. Here is what I propose: - I reintroduced the opencascade ebuild dependency - I renamed all the 'disabled-xxx' by xxx, using the ! to actually disable them. I think it is more 'gentoo' style - I corrected the list of USE to reflect the addition of new flags as well as the use of mpi - I added the missing 'PATH' in the etc/env.d file I have a couple of question for you: - I saw that you simplified the X/opengl configuration flags. Does it work for you? I know mine were a bit complicated but once upon a time (cannot remember if it was for OpenCascade or for Salome-kernel) I had to specify all the details to get it work. - All these viewer, that can be enabled/disabled, do you think they are the reasons why vtk, opencascade etc... have to be included as dependencies? And now, the one cent question, how do I start the whole thing? Neither runSalome nor runLightSalome give me anything of interested... Daniel
Hi! > Oups, I made a mistake about opencascase ! I forgot do add the dependency ! > OpenCascase is intalled on my computer, but I did it manually. So, I don't have > an ebuild for opencascade in my portage tree. Please check the ebuild Alvaro and I wrote: http://bugs.gentoo.org/show_bug.cgi?id=118656 > For docutils I don't know. I don't remember I cut this dependence. It must be > again a wrong manipulation from myself. I brought it back. No worries mate! > > is not really clear in my mind where our dependencies should be (Runtime > > dependent vs compile). So, I suppose your changes are right... ;) > I hope ^^. And it's true it's not easy to have the correct dependencies ! I agree.... Daniel
> Thank you very much for the great work on the salome-gui ebuild. You're welcome ;-) > I have built it without problems with the new patch and I have also slightly > modified it. Here is what I propose: > - I reintroduced the opencascade ebuild dependency > - I renamed all the 'disabled-xxx' by xxx, using the ! to actually disable > them. I think it is more 'gentoo' style > - I corrected the list of USE to reflect the addition of new flags as well as > the use of mpi > - I added the missing 'PATH' in the etc/env.d file Ok, no problem. > I have a couple of question for you: > - I saw that you simplified the X/opengl configuration flags. Does it work for > you? I know mine were a bit complicated but once upon a time (cannot remember > if it was for OpenCascade or for Salome-kernel) I had to specify all the > details to get it work. I search in configure script for really effective flag and with-wmu-include is nowhere for exemple. And I could run salome after. So I suppose it's working ^^ > - All these viewer, that can be enabled/disabled, do you think they are the > reasons why vtk, opencascade etc... have to be included as dependencies? Maybe conditionnal dependencies ? > And now, the one cent question, how do I start the whole thing? > Neither runSalome nor runLightSalome give me anything of interested... I use runSalome script. But I need 3 components to be installed before have a GUI : KERNEL, GUI and MED. Currently, I have only KERNEL and GUI component and the GUI doesn't start. I will install MED component to check what I'm saying is true ;-)
Hello, > I use runSalome script. But I need 3 components to be installed before have a > GUI : KERNEL, GUI and MED. > > Currently, I have only KERNEL and GUI component and the GUI doesn't start. I > will install MED component to check what I'm saying is true ;-) I don't know if you have seen it but there is an ebuild for med now on bugs.gentoo.org. I built it without any problem. I tried your ebuild for salome-med and I got the following: * Applying salome-med-3.2.6_gcc4.patch ... [ ok ] >>> Source unpacked. >>> Compiling source in /var/tmp/portage/sci-misc/salome-med-3.2.6 ... Creating new file 'configure.in' ... done Creating 'configure' script ... aclocal-1.10: couldn't open directory `/opt/salome-3.2.6/GUI/adm_local/unix/config_files': No such file or directory configure.in:134: error: possibly undefined macro: AC_ENABLE_DEBUG If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.in:135: error: possibly undefined macro: AC_DISABLE_PRODUCTION configure.in:143: error: possibly undefined macro: AC_ENABLE_STATIC configure.in:145: error: possibly undefined macro: AC_LIBTOOL_DLOPEN configure.in:146: error: possibly undefined macro: AC_PROG_LIBTOOL configure.in:172: error: possibly undefined macro: AC_CXX_WARNINGS configure.in:173: error: possibly undefined macro: AC_CXX_TEMPLATE_OPTIONS configure.in:174: error: possibly undefined macro: AC_DEPEND_FLAG configure.in:192: error: possibly undefined macro: AC_CXX_USE_STD_IOSTREAM configure.in:199: error: possibly undefined macro: AC_CXX_HAVE_SSTREAM configure.in:207: error: possibly undefined macro: AC_LINKER_OPTIONS failed (check file permissions and/or user quotas ...) * /var/tmp/portage/sci-misc/salome-med-3.2.6/work/src3.2.6/MED_SRC_3.2.6/configure --prefix=/var/tmp/portage/sci-misc/salome-med-3.2.6/image/opt/salome-3.2.6/MED Source root directory : /var/tmp/portage/sci-misc/salome-med-3.2.6/work/src3.2.6/MED_SRC_3.2.6 Build root directory : /var/tmp/portage/sci-misc/salome-med-3.2.6/work/build /var/tmp/portage/sci-misc/salome-med-3.2.6/work/src3.2.6/MED_SRC_3.2.6/configure: line 1718: WITH_KERNEL: command not found checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking for sh... /bin/sh checking for ar... ar Daniel
> > I tried your ebuild for salome-med and I got the following: > I also have this error and it comes from a patch you made ! http://bugs.gentoo.org/attachment.cgi?id=139964 In fact, I don't understand why you comment the installation of adm_local install: - cp -rf @top_srcdir@/adm_local @prefix@ +# cp -rf @top_srcdir@/adm_local @prefix@ And the build_configure script of med component are looing for this directory Have you got some problem with the copy to remove it ? In this case, I suppose we have to patch the med component. Otherwise, we can just modify the patch...
Hello Francois, > I also have this error and it comes from a patch you made ! > http://bugs.gentoo.org/attachment.cgi?id=139964 > > In fact, I don't understand why you comment the installation of adm_local I don't remember either. It's something I did months ago, with my original ebuild... ;) > install: > - cp -rf @top_srcdir@/adm_local @prefix@ > +# cp -rf @top_srcdir@/adm_local @prefix@ > > And the build_configure script of med component are looing for this directory Yes indeed... > Have you got some problem with the copy to remove it ? In this case, I suppose > we have to patch the med component. Otherwise, we can just modify the patch... Let's begin by removing the patch. We will see how far we get... ;) Daniel
That's why I added the patch.... + make resources make[2]: Entering directory `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/doc' make[2]: Nothing to be done for `resources'. make[2]: Leaving directory `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/doc' + for d in src doc adm_local + cd adm_local + make resources make[2]: Entering directory `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/adm_local' cp -rf ../adm_local .. cp: `../adm_local' and `../adm_local' are the same file make[2]: *** [resources] Error 1 make[2]: Leaving directory `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/adm_local' + exit 1 make[1]: *** [resources] Error 1 make[1]: Leaving directory `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6' make: *** [all] Error 2 > > I tried your ebuild for salome-med and I got the following: > > > I also have this error and it comes from a patch you made ! > http://bugs.gentoo.org/attachment.cgi?id=139964 So, I suppose we need to add the catalogue in the list of files to be included. We can use something like: dodir xxx insinto xxx doins yyy Daniel
Created attachment 140064 [details] salome-gui (Add the adm_local folder) Here is a corrected ebuild to add the missing adm_local directory (needed by salome-med). Daniel
Francois, The ebuild you proposed for MED works for me. I am planning to 'gentooify' it using emake econf etc... I try to run runSalome but still, no interesting result (some python/corba messages and that's it!). Does it work on your side? Daniel PS: x86 gcc3.4.6 here
Created attachment 140066 [details] salome-med. First proposal (after 'gentooing'...) Francois, Here is my first proposal. I am building it now. We will see... I join a new patch as well. Daniel
Created attachment 140068 [details, diff] A minor patch for the salome-med ebuild
(In reply to comment #111) > Francois, > > The ebuild you proposed for MED works for me. I am planning to 'gentooify' it > using emake econf etc... > > I try to run runSalome but still, no interesting result (some python/corba > messages and that's it!). Does it work on your side? > > Daniel > > PS: x86 gcc3.4.6 here > I've begun to gentoify my ebuild, but now I have a problem with sandbox ! I'm trying to resolve it. And then, I still don't have med composant installed.
well, we did similar things ;-) I propose after we finished with the med component not to work on the same component on the same time (= not modify and searching resolving problem, but we can always test ^^). I think we can work faster in that way. And it will avoid we do the same things ;-) What do you thinking about this idea ?
Hello, > well, we did similar things ;-) We are having fun indeed and we start to see the end of all of this, that's the most exciting moment... ;) > I propose after we finished with the med component not to work on the same > component on the same time (= not modify and searching resolving problem, but > we can always test ^^). I think we can work faster in that way. And it will > avoid we do the same things ;-) What do you thinking about this idea ? That's fine by me! ;) About the sandbox, it has probably something to do with the --prefix + the others (they are the important ones) in econf and then, the equivalent list in einstall. I have been struggling quite a lot with this before I understood the way it works. Look at what has been done in GUI, that's fairly self explaining... ;)
> About the sandbox, it has probably something to do with the --prefix + the > others (they are the important ones) in econf and then, the equivalent list in > einstall. I have been struggling quite a lot with this before I understood the > way it works. Look at what has been done in GUI, that's fairly self > explaining... ;) One big mistake : I didn't initialise the INSTALL_DIR variable ! So --prefix="${INSTALL_DIR}" was replace by --prefix="" The compilation is still running. I'm waiting now ^^
Created attachment 140071 [details, diff] Modification of the previous patch
Created attachment 140073 [details] salome-med (second proposal) I think the adm_local folder also needs to be added. This remains to be checked though. What I noticed is that I had the same kind of issue here than with GUI (adm_local stuffs, therefore the additional patch)
Hello, > One big mistake : I didn't initialise the INSTALL_DIR variable ! So > --prefix="${INSTALL_DIR}" was replace by --prefix="" > > The compilation is still running. I'm waiting now ^^ I'm curious. Then we can compare what we did. Daniel
Status with MED: I have a sandbox issue but I do not really know how to solve that one... If you have any idea... By for now Daniel + make install make[3]: Entering directory `/var/tmp/portage/sci-misc/salome-med-3.2.6/work/src3.2.6/MED_SRC_3.2.6/src/MedClient/test' /usr/bin/install -c -d /var/tmp/portage/sci-misc/salome-med-3.2.6/image///opt/salome-3.2.6/MED/share/resources/med + for d in environ test1 test2 + cd environ + make install make[4]: Entering directory `/var/tmp/portage/sci-misc/salome-med-3.2.6/work/src3.2.6/MED_SRC_3.2.6/src/MedClient/test/environ' mkdir -p /opt/salome-3.2.6/MED/Tests/environ cp -rf runEnvironTests csh /opt/salome-3.2.6/MED/Tests/environ ACCESS DENIED open_wr: /opt/salome-3.2.6/MED/Tests/environ/runEnvironTests ACCESS DENIED unlink: /opt/salome-3.2.6/MED/Tests/environ/runEnvironTests cp: cannot remove `/opt/salome-3.2.6/MED/Tests/environ/runEnvironTests': Permission denied ACCESS DENIED open_wr: /opt/salome-3.2.6/MED/Tests/environ/csh/Makefile ACCESS DENIED unlink: /opt/salome-3.2.6/MED/Tests/environ/csh/Makefile cp: cannot remove `/opt/salome-3.2.6/MED/Tests/environ/csh/Makefile': Permission denied ACCESS DENIED open_wr: /opt/salome-3.2.6/MED/Tests/environ/csh/runEnvironTests.in cp: cannot create regular file `/opt/salome-3.2.6/MED/Tests/environ/csh/runEnvironTests.in': Permission denied ACCESS DENIED open_wr: /opt/salome-3.2.6/MED/Tests/environ/csh/init1 ACCESS DENIED unlink: /opt/salome-3.2.6/MED/Tests/environ/csh/init1 cp: cannot remove `/opt/salome-3.2.6/MED/Tests/environ/csh/init1': Permission denied ACCESS DENIED open_wr: /opt/salome-3.2.6/MED/Tests/environ/csh/init2 ACCESS DENIED unlink: /opt/salome-3.2.6/MED/Tests/environ/csh/init2 cp: cannot remove `/opt/salome-3.2.6/MED/Tests/environ/csh/init2': Permission denied ACCESS DENIED open_wr: /opt/salome-3.2.6/MED/Tests/environ/csh/init3 ACCESS DENIED unlink: /opt/salome-3.2.6/MED/Tests/environ/csh/init3 cp: cannot remove `/opt/salome-3.2.6/MED/Tests/environ/csh/init3': Permission denied ACCESS DENIED open_wr: /opt/salome-3.2.6/MED/Tests/environ/csh/runEnvironTests ACCESS DENIED unlink: /opt/salome-3.2.6/MED/Tests/environ/csh/runEnvironTests cp: cannot remove `/opt/salome-3.2.6/MED/Tests/environ/csh/runEnvironTests': Permission denied ACCESS DENIED open_wr: /opt/salome-3.2.6/MED/Tests/environ/csh/runContainer ACCESS DENIED unlink: /opt/salome-3.2.6/MED/Tests/environ/csh/runContainer cp: cannot remove `/opt/salome-3.2.6/MED/Tests/environ/csh/runContainer': Permission denied ACCESS DENIED open_wr: /opt/salome-3.2.6/MED/Tests/environ/csh/Makefile.in cp: cannot create regular file `/opt/salome-3.2.6/MED/Tests/environ/csh/Makefile.in': Permission denied ACCESS DENIED open_wr: /opt/salome-3.2.6/MED/Tests/environ/csh/stopContainer ACCESS DENIED unlink: /opt/salome-3.2.6/MED/Tests/environ/csh/stopContainer cp: cannot remove `/opt/salome-3.2.6/MED/Tests/environ/csh/stopContainer': Permission denied ACCESS DENIED open_wr: /opt/salome-3.2.6/MED/Tests/environ/csh/stopContainer.in cp: cannot create regular file `/opt/salome-3.2.6/MED/Tests/environ/csh/stopContainer.in': Permission denied ACCESS DENIED open_wr: /opt/salome-3.2.6/MED/Tests/environ/csh/init1.in cp: cannot create regular file `/opt/salome-3.2.6/MED/Tests/environ/csh/init1.in': Permission denied ACCESS DENIED open_wr: /opt/salome-3.2.6/MED/Tests/environ/csh/init2.in cp: cannot create regular file `/opt/salome-3.2.6/MED/Tests/environ/csh/init2.in': Permission denied ACCESS DENIED open_wr: /opt/salome-3.2.6/MED/Tests/environ/csh/init3.in cp: cannot create regular file `/opt/salome-3.2.6/MED/Tests/environ/csh/init3.in': Permission denied ACCESS DENIED open_wr: /opt/salome-3.2.6/MED/Tests/environ/csh/runContainer.in cp: cannot create regular file `/opt/salome-3.2.6/MED/Tests/environ/csh/runContainer.in': Permission denied make[4]: *** [install] Error 1
(In reply to comment #121) > Status with MED: > I have a sandbox issue but I do not really know how to solve that one... > If you have any idea... > What is your emake install command line ? Do you define the prefix flag with something like "--prefix=${D}/${INSTALL_DIR}" ?
Well, I have a similar error. I'm trying a patch. I'll tell you if it work or not when compilation will be finished.
Created attachment 140086 [details, diff] fixed a Makefile to support DESTDIR
Created attachment 140088 [details] new salome-med ebuild
Daniel, MED component is now compiling. But I cannot run salome. I don't know why, but I have no GUI when I run runSalome. I'm looking for this problem. If you have any idea, tell me ;-)
> and I get a 'Can not load application library "libLightApp.so": > /opt/salome-3.2.6/GUI/lib/salome/libPlot2d.so.0: undefined symbol: > _ZN7QwtPlot12drawContentsEP8QPainter > > Any idea on this one? > Yes. have you recently installed qwt-5 ? I have on my computer both v4 and v5. And I believe v4 include for compilation, but v5 for linking ! So the problem. I'll check in after launch....
> Yes. have you recently installed qwt-5 ? I have on my computer both v4 and v5. > And I believe v4 include for compilation, but v5 for linking ! So the problem. > I'll check in after launch.... > I confirm what I was saying : it use v4 include files but v5 lib ! I'm working on a patch for check_qwt.M4 to use the correct lib files. I've tested use qwt-v5 but in failed to compile. So, the simpliest way is to use the correct version of libraries...
Created attachment 140280 [details] salome-gui. Minor change No need to specify clearly where location of the salome kernel. KERNEL_ROOT_DIR in /etc/env.d is there for that....
Created attachment 140283 [details] salome-gui : correct a bug Some files need to be in share/salome and not in share. Now we can launch the GUI. And no need of MED component to launch it. Again a mistake from myself ;-)
Created attachment 140301 [details] salome-gui. Resynced Francois and Daniel's work Francois, I resynced our ebuilds. We have to be careful not to fork our own work... ;) One more thing, you did not attached the qwt patch... Daniel
> Some files need to be in share/salome and not in share. Now we can launch the > GUI. And no need of MED component to launch it. Again a mistake from myself ;-) Great to read that you solved the issue. You are good my friend... ;) Do you think this issue with share/salome is also relevant for KERNEL and MED? Daniel PS: I am building the packages on an x86 machine with gcc-4.1.2 at the moment (I was using gcc-3.4.6 before)
Created attachment 140303 [details] salome-med. Resynced Francois' and Daniel's work Francois, I have resynced our work with the MED ebuild. Daniel
> I resynced our ebuilds. We have to be careful not to fork our own work... ;) > One more thing, you did not attached the qwt patch... Well, in fact, it doesn't work. So you can skip the patch. I dont' find a way to use libqwt.so.4 instead of libqwt.so.5. Currently, I've modified manually the link /usr/lib/libqwt.so to point to /usr/lib/libqwt.so.4. We have to find a better solution. Any idea ?
(In reply to comment #132) > > Some files need to be in share/salome and not in share. Now we can launch the > > GUI. And no need of MED component to launch it. Again a mistake from myself ;-) > > Great to read that you solved the issue. You are good my friend... ;) > Do you think this issue with share/salome is also relevant for KERNEL and MED? > I think it'll be a good thing to do this for every component. > Daniel > > PS: I am building the packages on an x86 machine with gcc-4.1.2 at the moment > (I was using gcc-3.4.6 before) > gcc-4.2.2 on a x86 machine
Francois, > > > Some files need to be in share/salome and not in share. Now we can launch the > > > GUI. And no need of MED component to launch it. Again a mistake from myself ;-) > > > > Great to read that you solved the issue. You are good my friend... ;) > > Do you think this issue with share/salome is also relevant for KERNEL and MED? > > > I think it'll be a good thing to do this for every component. OK. That's not very difficult to do... ;) > > PS: I am building the packages on an x86 machine with gcc-4.1.2 at the moment > > (I was using gcc-3.4.6 before) > > > gcc-4.2.2 on a x86 machine That's good. It gives us the opportunity to test with different compilers. I have salome running here now. I solved the qwt problem the simplest way, I unemerge 5.0.2 and I created a link for libqwt.so as you did. Quick and dirty.... :( I wanted to see what the result would be with KERNEL, GUI and MED and indeed, I have a running salome now... :) It's clear that it needs the other modules but the system seems to work (so far so good). That feels good... ;) I will focus on GEOM now. Daniel
Created attachment 140366 [details] salome-geom : Gentooification.... This one seems to work. There is a patch associated to it
Created attachment 140368 [details, diff] A patch associated to the new salome-geom ebuild The new salome-geom ebuild is a proof of concept. I did not check things into details (neither all the flags nor all the possibilities offered by the GEOM package). We will have to do that later on...
Created attachment 140373 [details] salome-superv: Gentooification Here as well, this is a proof of concept. The ebuild works but needs to be carefully reviewed regarding the flags and the econf options. Daniel
Created attachment 140375 [details, diff] patch for the new salome-superv ebuild This is a simple patch. Cousin of the ones already produced for the other modules (it's always the same kind of issues). Similar patches need to be produced for the remaining modules. Daniel
Francois, It seems that I have some kind of issue with MED. When I start runSalome, I can read: $ runSalome ******************************************************* * * Environment variable PYCALCULATOR_ROOT_DIR must be set * Module PYCALCULATOR will be not available * ******************************************************** ******************************************************* * * Environment variable COMPONENT_ROOT_DIR must be set * Module COMPONENT will be not available * ******************************************************** ******************************************************* * * Environment variable VISU_ROOT_DIR must be set * Module VISU will be not available * ******************************************************** ******************************************************* * * Environment variable SMESH_ROOT_DIR must be set * Module SMESH will be not available * ******************************************************** which is OK because some of the modules have not been installed, however I can also read: **************************************************************** * Warning: SMESH not found in resources. * Module will not be available **************************************************************** **************************************************************** * Warning: VISU not found in resources. * Module will not be available **************************************************************** **************************************************************** * Warning: MED not found in resources. * Module will not be available **************************************************************** **************************************************************** * Warning: COMPONENT not found in resources. * Module will not be available **************************************************************** **************************************************************** * Warning: PYCALCULATOR not found in resources. * Module will not be available **************************************************************** which is not cause MED _is_ there.... Any idea? Daniel
Created attachment 140378 [details] salome-med. Now the module is loaded by the GUI Corrected the bug that led to my previous remark. The correction was simple: to setup correctly the --datadir (../share/salome and not ../share) Daniel
Created attachment 140385 [details] salome-visu: Gentooification...
Created attachment 140386 [details, diff] Additional patch for salome-visu
Francois, Can you take care of these three ones?: **************************************************************** * Warning: SMESH not found in resources. * Module will not be available **************************************************************** **************************************************************** * Warning: COMPONENT not found in resources. * Module will not be available **************************************************************** **************************************************************** * Warning: PYCALCULATOR not found in resources. * Module will not be available **************************************************************** It should not be very difficult to produce the ebuilds. I propose that you use and modify what we produced so far (visu, superv, whatever, they are all the same) with the patches you provided a few weeks ago. Once we have all the ebuilds available, we can start to check them one by one to see if nothing had been forgotten. Cordialement, Daniel
(In reply to comment #145) > Francois, > > Can you take care of these three ones?: > **************************************************************** > * Warning: SMESH not found in resources. > * Module will not be available > **************************************************************** > **************************************************************** > * Warning: COMPONENT not found in resources. > * Module will not be available > **************************************************************** > **************************************************************** > * Warning: PYCALCULATOR not found in resources. > * Module will not be available > **************************************************************** > > It should not be very difficult to produce the ebuilds. I propose that you use > and modify what we produced so far (visu, superv, whatever, they are all the > same) with the patches you provided a few weeks ago. > > Once we have all the ebuilds available, we can start to check them one by one > to see if nothing had been forgotten. > Ok, I'll do it, but I don't know if it will be today. I've a car accident yesterday. My car is broken and I'm looking for a new one. I will do it when I could.
Francois, > Ok, I'll do it, but I don't know if it will be today. I've a car accident > yesterday. My car is broken and I'm looking for a new one. J! I hope you did not hurt yourself or anyone else. I was trying to fix the smesh ebuild this morning but I do not have access to all the patches. In your ebuild, you make reference to salome-smesh-3.2.6.patch, salome-smesh-3.2.6_debug.patch and salome-smesh-3.2.6_GetSource.patch but you only provided the first one. Can you give me the missing patches? Thanks in advance. Daniel
Created attachment 140455 [details] salome-kernel. Cleaning work Hello Francois, I have started to clean the salome-kernel ebuild and to focus on the OpenPBS issue. Here is the situation: - OpenPBS is not supported by Gentoo anymore. It has been replaced by Torque (some derivate work) - The OPENPBS variable is a tricky one and somehow, I do not succeed to get the OpenPBS option on, during the configuration. Once this is solved, I will take a look at the MPICH2 stuff as well. BTW, I modified a bit the behavior of the doc flag, it's more Gentoo style now... ;) Daniel
Created attachment 140466 [details] salome-kernel. Continued the cleaning work + openpbs work Francois, Here is a reworked version of the ebuild: - I reworked the action of the X and opengl flags. What I had created before was not so wise, basically Salome _needs_ X11, so, if no X flag, no salome! ... - I have started to work on the OpenPBS issue but I'll need your help. As I wrote before, OpenPBS is replaced by Torque. This means that the check_openpbs.m4 file needs to be patched. I have shyly started but it is far from complete... At the moment, the configuration sees that there is OpenPBS (if we use the appropriate flag) but cannot find the library (It is a problem of name, libpbs became libtorque). So, I started to modify check_openpbs.m4 in this spirit but apparently I missed part of it... testing OpenPBS --------------- checking pbs_ifl.h usability... yes checking pbs_ifl.h presence... yes checking for pbs_ifl.h... yes checking for pbs_connect in -lpbs... no configure: WARNING: OpenPBS library not found So, can you take a look at it? Thanks in advance Daniel
Created attachment 140468 [details, diff] The embryonic openpbs patch
Hello Daniel, Nobody was hurt but I have not slept for 2 days ! I'm tired but impossible to sleep. I see you progress a lot. Thank you for your work ! I'll try it your ebuilds and patches. And I will looking for your problem with torque.
> I was trying to fix the smesh ebuild this morning but I do not have access to > all the patches. In your ebuild, you make reference to > salome-smesh-3.2.6.patch, salome-smesh-3.2.6_debug.patch and > salome-smesh-3.2.6_GetSource.patch but you only provided the first one. > Can you give me the missing patches? And the other patches can be skip for the moment. It was a try to resolve a runtime bug. But it was not successful. I forgot to delete them.
Created attachment 140472 [details] salome-smesh: Gentooification As for the other, this is a very first attempt (functional though). The ebuild needs to be polished... Daniel
Created attachment 140474 [details, diff] salome-smesh: complementary patch to the one already provided by Francois
Hello Daniel I'm trying to install opencasace with your ebuild, but it failed because I have not enough free space on my partition. 3Go was not enough. So, I think it could be a good idea to precise this on the beginning of the opencascade ebuild with an einfo command. Currently, I'm installing it with more free space. When it is installed, I will suggest a minimum free space to the corresponding bug report, because lost more than one day of compilation is enraging ! François
Hello Francois, Sorry about that. It is mentionned as a comment in the ebuild I think but you are right, it should be a warning stopping the process in case of lack of place. Once again, sorry about that, mate. Daniel > Hello Daniel > > I'm trying to install opencasace with your ebuild, but it failed because I have > not enough free space on my partition. 3Go was not enough. So, I think it could > be a good idea to precise this on the beginning of the opencascade ebuild with > an einfo command. > > Currently, I'm installing it with more free space. When it is installed, I will > suggest a minimum free space to the corresponding bug report, because lost more > than one day of compilation is enraging ! > > François >
I'm continuing to have trouble with salome-kernel: SALOME_GenericObj_i.cc: In constructor 'SALOME::GenericObj_i::GenericObj_i(PortableServer::POA*)': SALOME_GenericObj_i.cc:45: error: '_default_POA' is not a member of 'PortableServer::RefCountServantBase'
Hello Jon > I'm continuing to have trouble with salome-kernel: > > SALOME_GenericObj_i.cc: In constructor > 'SALOME::GenericObj_i::GenericObj_i(PortableServer::POA*)': > SALOME_GenericObj_i.cc:45: error: '_default_POA' is not a member of > 'PortableServer::RefCountServantBase' > Can you post a longer log or add a complete log in attachment ? Because it is difficult to help you with so few information... François
Created attachment 140637 [details, diff] salome-kernel patch for my system Sure: I'm using 64-bit (~amd64), gcc-4.2.2 and trying to compile salome-kernel, but not getting anywhere. Attached is a patch that at least moves the build process along for me. The problem I was having previously was with a deprecated omniORB call. If you upgrade to omniORB-4.1.1, you'll see that the class "RefCountServantBase" was deprecated. Therefore, this patch changes it to ServantBase. I encountered many other compile errors and managed to fix a few. Please let me know if I should keep doing this, or if I'm wasting my time. # emerge --info Portage 2.1.4_rc14 (default-linux/amd64/2007.0, gcc-4.2.2, glibc-2.7-r1, 2.6.16.54-0.2.3-smp x86_64) ================================================================= System uname: 2.6.16.54-0.2.3-smp x86_64 Intel(R) Xeon(R) CPU X5365 @ 3.00GHz Timestamp of tree: Mon, 07 Jan 2008 01:47:01 +0000 app-shells/bash: 3.2_p33 dev-java/java-config: 1.3.7, 2.1.3 dev-lang/python: 2.4.3-r4, 2.5.1-r4 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.10-r5 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.61-r1 sys-devel/automake: 1.9.6-r2, 1.10 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="amd64 ~amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-Os -pipe -fomit-frame-pointer -march=nocona" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /var/spool/torque" 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="-Os -pipe -fomit-frame-pointer -march=nocona" 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 --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/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acl amd64 apache2 bcmath berkdb bitmap-fonts bzip2 cairo cli cracklib crypt cups curl dri fortran ftp gd gdbm gif gpm iconv imap ipv6 isdnlog java jpeg midi mmx mudflap mysql ncurses nls nptl nptlonly opengl openmp openpbs pam pcntl pcre perl php posix postgres ppds pppd python qt3 readline reflection session snv spl sse sse2 ssl svg tcpd threads tiff truetype-fonts type1-fonts unicode xml xorg 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
by the way, I'm up to the following error in the build process: /bin/sh ../../libtool --tag=CXX --mode=compile x86_64-pc-linux-gnu-g++ -DPACKAGE_NAME=\"Salome2\ Project\" -DPACKAGE_TARNAME=\"salome\" -DPACKAGE_VERSION=\"3.2.6\" -DPACKAGE_STRING=\"Salome2\ Project\ 3.2.6\" -DPACKAGE_BUGREPORT=\"gboulant@CS\" -DPACKAGE=\"salome\" -DVERSION=\"3.2.6\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBDL=1 -DHAVE_LIBRT=1 -DHAVE_LIBM=1 -DHAVE_NAMESPACES= -DHAVE_PTHREAD=1 -D__x86__=1 -D__linux__=1 -D__OSVERSION__=1 -DOMNIORB=1 -DCORBA_HAVE_POA=1 -DCORBA_ORB_INIT_HAVE_3_ARGS=1 -DCORBA_ORB_INIT_THIRD_ARG=\"omniORB\" -DRM=\"/bin/rm\" -DSH=\"/bin/sh\" -DCP=\"/bin/cp\" -DRSH=\"/usr/bin/rsh\" -DRCP=\"/usr/bin/rcp\" -DSSH=\"/usr/bin/ssh\" -DSCP=\"/usr/bin/scp\" -I. -I/usr/include/python2.5 -I./../Basics -I./../SALOMELocalTrace -I../../salome_adm/unix -I/usr/include/python2.5 -I./../Basics -I./../SALOMELocalTrace -DHAVE_CONFIG_H -DHAVE_SOCKET -m64 -D_OCC64 -Os -pipe -fomit-frame-pointer -march=nocona -m64 -ffriend-injection -fpermissive -g -D_DEBUG_ -Wno-deprecated -Wparentheses -Wreturn-type -Wunused -pthread -MT libSalomeBatch_la-Batch_BatchManager.lo -MD -MP -MF .deps/libSalomeBatch_la-Batch_BatchManager.Tpo -c -o libSalomeBatch_la-Batch_BatchManager.lo `test -f 'Batch_BatchManager.cxx' || echo './'`Batch_BatchManager.cxx x86_64-pc-linux-gnu-g++ "-DPACKAGE_NAME=\"Salome2 Project\"" -DPACKAGE_TARNAME=\"salome\" -DPACKAGE_VERSION=\"3.2.6\" "-DPACKAGE_STRING=\"Salome2 Project 3.2.6\"" -DPACKAGE_BUGREPORT=\"gboulant@CS\" -DPACKAGE=\"salome\" -DVERSION=\"3.2.6\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBDL=1 -DHAVE_LIBRT=1 -DHAVE_LIBM=1 -DHAVE_NAMESPACES= -DHAVE_PTHREAD=1 -D__x86__=1 -D__linux__=1 -D__OSVERSION__=1 -DOMNIORB=1 -DCORBA_HAVE_POA=1 -DCORBA_ORB_INIT_HAVE_3_ARGS=1 -DCORBA_ORB_INIT_THIRD_ARG=\"omniORB\" -DRM=\"/bin/rm\" -DSH=\"/bin/sh\" -DCP=\"/bin/cp\" -DRSH=\"/usr/bin/rsh\" -DRCP=\"/usr/bin/rcp\" -DSSH=\"/usr/bin/ssh\" -DSCP=\"/usr/bin/scp\" -I. -I/usr/include/python2.5 -I./../Basics -I./../SALOMELocalTrace -I../../salome_adm/unix -I/usr/include/python2.5 -I./../Basics -I./../SALOMELocalTrace -DHAVE_CONFIG_H -DHAVE_SOCKET -m64 -D_OCC64 -Os -pipe -fomit-frame-pointer -march=nocona -m64 -ffriend-injection -fpermissive -g -D_DEBUG_ -Wno-deprecated -Wparentheses -Wreturn-type -Wunused -pthread -MT libSalomeBatch_la-Batch_BatchManager.lo -MD -MP -MF .deps/libSalomeBatch_la-Batch_BatchManager.Tpo -c Batch_BatchManager.cxx -fPIC -DPIC -o .libs/libSalomeBatch_la-Batch_BatchManager.o mv -f .deps/libSalomeBatch_la-Batch_BatchManager.Tpo .deps/libSalomeBatch_la-Batch_BatchManager.Plo /bin/sh ../../libtool --tag=CXX --mode=compile x86_64-pc-linux-gnu-g++ -DPACKAGE_NAME=\"Salome2\ Project\" -DPACKAGE_TARNAME=\"salome\" -DPACKAGE_VERSION=\"3.2.6\" -DPACKAGE_STRING=\"Salome2\ Project\ 3.2.6\" -DPACKAGE_BUGREPORT=\"gboulant@CS\" -DPACKAGE=\"salome\" -DVERSION=\"3.2.6\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBDL=1 -DHAVE_LIBRT=1 -DHAVE_LIBM=1 -DHAVE_NAMESPACES= -DHAVE_PTHREAD=1 -D__x86__=1 -D__linux__=1 -D__OSVERSION__=1 -DOMNIORB=1 -DCORBA_HAVE_POA=1 -DCORBA_ORB_INIT_HAVE_3_ARGS=1 -DCORBA_ORB_INIT_THIRD_ARG=\"omniORB\" -DRM=\"/bin/rm\" -DSH=\"/bin/sh\" -DCP=\"/bin/cp\" -DRSH=\"/usr/bin/rsh\" -DRCP=\"/usr/bin/rcp\" -DSSH=\"/usr/bin/ssh\" -DSCP=\"/usr/bin/scp\" -I. -I/usr/include/python2.5 -I./../Basics -I./../SALOMELocalTrace -I../../salome_adm/unix -I/usr/include/python2.5 -I./../Basics -I./../SALOMELocalTrace -DHAVE_CONFIG_H -DHAVE_SOCKET -m64 -D_OCC64 -Os -pipe -fomit-frame-pointer -march=nocona -m64 -ffriend-injection -fpermissive -g -D_DEBUG_ -Wno-deprecated -Wparentheses -Wreturn-type -Wunused -pthread -MT libSalomeBatch_la-Batch_Couple.lo -MD -MP -MF .deps/libSalomeBatch_la-Batch_Couple.Tpo -c -o libSalomeBatch_la-Batch_Couple.lo `test -f 'Batch_Couple.cxx' || echo './'`Batch_Couple.cxx x86_64-pc-linux-gnu-g++ "-DPACKAGE_NAME=\"Salome2 Project\"" -DPACKAGE_TARNAME=\"salome\" -DPACKAGE_VERSION=\"3.2.6\" "-DPACKAGE_STRING=\"Salome2 Project 3.2.6\"" -DPACKAGE_BUGREPORT=\"gboulant@CS\" -DPACKAGE=\"salome\" -DVERSION=\"3.2.6\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBDL=1 -DHAVE_LIBRT=1 -DHAVE_LIBM=1 -DHAVE_NAMESPACES= -DHAVE_PTHREAD=1 -D__x86__=1 -D__linux__=1 -D__OSVERSION__=1 -DOMNIORB=1 -DCORBA_HAVE_POA=1 -DCORBA_ORB_INIT_HAVE_3_ARGS=1 -DCORBA_ORB_INIT_THIRD_ARG=\"omniORB\" -DRM=\"/bin/rm\" -DSH=\"/bin/sh\" -DCP=\"/bin/cp\" -DRSH=\"/usr/bin/rsh\" -DRCP=\"/usr/bin/rcp\" -DSSH=\"/usr/bin/ssh\" -DSCP=\"/usr/bin/scp\" -I. -I/usr/include/python2.5 -I./../Basics -I./../SALOMELocalTrace -I../../salome_adm/unix -I/usr/include/python2.5 -I./../Basics -I./../SALOMELocalTrace -DHAVE_CONFIG_H -DHAVE_SOCKET -m64 -D_OCC64 -Os -pipe -fomit-frame-pointer -march=nocona -m64 -ffriend-injection -fpermissive -g -D_DEBUG_ -Wno-deprecated -Wparentheses -Wreturn-type -Wunused -pthread -MT libSalomeBatch_la-Batch_Couple.lo -MD -MP -MF .deps/libSalomeBatch_la-Batch_Couple.Tpo -c Batch_Couple.cxx -fPIC -DPIC -o .libs/libSalomeBatch_la-Batch_Couple.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/bits/ostream_insert.h: In function 'std::basic_ostream<_CharT, _Traits>& std::__ostream_insert(std::basic_ostream<_CharT, _Traits>&, const _CharT*, std::streamsize) [with _CharT = char, _Traits = std::char_traits<char>]': /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/bits/basic_string.h:2404: instantiated from 'std::basic_ostream<_CharT, _Traits>& std::operator<<(std::basic_ostream<_CharT, _Traits>&, const std::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]' Batch_Couple.cxx:61: instantiated from here /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/bits/ostream_insert.h:82: error: invalid use of incomplete type 'struct std::basic_ostream<char, std::char_traits<char> >' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/iosfwd:64: error: declaration of 'struct std::basic_ostream<char, std::char_traits<char> >' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/bits/ostream_insert.h:84: error: invalid use of incomplete type 'struct std::basic_ostream<char, std::char_traits<char> >' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/iosfwd:64: error: declaration of 'struct std::basic_ostream<char, std::char_traits<char> >' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/bits/ostream_insert.h:84: error: invalid use of incomplete type 'struct std::basic_ostream<char, std::char_traits<char> >' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/iosfwd:64: error: declaration of 'struct std::basic_ostream<char, std::char_traits<char> >' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/bits/ostream_insert.h:89: error: invalid use of incomplete type 'struct std::basic_ostream<char, std::char_traits<char> >' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/iosfwd:64: error: declaration of 'struct std::basic_ostream<char, std::char_traits<char> >' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/bits/ostream_insert.h:94: error: invalid use of incomplete type 'struct std::basic_ostream<char, std::char_traits<char> >' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/iosfwd:64: error: declaration of 'struct std::basic_ostream<char, std::char_traits<char> >' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/bits/ostream_insert.h:94: error: invalid use of incomplete type 'struct std::basic_ostream<char, std::char_traits<char> >' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/iosfwd:64: error: declaration of 'struct std::basic_ostream<char, std::char_traits<char> >' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/bits/ostream_insert.h:94: error: invalid use of incomplete type 'struct std::basic_ostream<char, std::char_traits<char> >' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/iosfwd:64: error: declaration of 'struct std::basic_ostream<char, std::char_traits<char> >' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/bits/basic_string.h:2404: instantiated from 'std::basic_ostream<_CharT, _Traits>& std::operator<<(std::basic_ostream<_CharT, _Traits>&, const std::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]' Batch_Couple.cxx:61: instantiated from here /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/bits/ostream_insert.h:97: error: invalid use of incomplete type 'struct std::basic_ostream<char, std::char_traits<char> >' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/iosfwd:64: error: declaration of 'struct std::basic_ostream<char, std::char_traits<char> >' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/bits/basic_string.h:2404: instantiated from 'std::basic_ostream<_CharT, _Traits>& std::operator<<(std::basic_ostream<_CharT, _Traits>&, const std::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]' Batch_Couple.cxx:61: instantiated from here /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/bits/ostream_insert.h:99: error: invalid use of incomplete type 'struct std::basic_ostream<char, std::char_traits<char> >' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/iosfwd:64: error: declaration of 'struct std::basic_ostream<char, std::char_traits<char> >' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/bits/ostream_insert.h:104: error: invalid use of incomplete type 'struct std::basic_ostream<char, std::char_traits<char> >' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/iosfwd:64: error: declaration of 'struct std::basic_ostream<char, std::char_traits<char> >' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/bits/ostream_insert.h:107: error: invalid use of incomplete type 'struct std::basic_ostream<char, std::char_traits<char> >' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/iosfwd:64: error: declaration of 'struct std::basic_ostream<char, std::char_traits<char> >' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/bits/ostream_insert.h:107: error: invalid use of incomplete type 'struct std::basic_ostream<char, std::char_traits<char> >' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/iosfwd:64: error: declaration of 'struct std::basic_ostream<char, std::char_traits<char> >' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/bits/ostream_insert.h: In function 'void std::__ostream_fill(std::basic_ostream<_CharT, _Traits>&, std::streamsize) [with _CharT = char, _Traits = std::char_traits<char>]': /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/bits/ostream_insert.h:96: instantiated from 'std::basic_ostream<_CharT, _Traits>& std::__ostream_insert(std::basic_ostream<_CharT, _Traits>&, const _CharT*, std::streamsize) [with _CharT = char, _Traits = std::char_traits<char>]' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/bits/basic_string.h:2404: instantiated from 'std::basic_ostream<_CharT, _Traits>& std::operator<<(std::basic_ostream<_CharT, _Traits>&, const std::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]' Batch_Couple.cxx:61: instantiated from here /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/bits/ostream_insert.h:62: error: invalid use of incomplete type 'struct std::basic_ostream<char, std::char_traits<char> >' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/iosfwd:64: error: declaration of 'struct std::basic_ostream<char, std::char_traits<char> >' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/bits/ostream_insert.h:64: error: invalid use of incomplete type 'struct std::basic_ostream<char, std::char_traits<char> >' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/iosfwd:64: error: declaration of 'struct std::basic_ostream<char, std::char_traits<char> >' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/bits/ostream_insert.h:67: error: invalid use of incomplete type 'struct std::basic_ostream<char, std::char_traits<char> >' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/iosfwd:64: error: declaration of 'struct std::basic_ostream<char, std::char_traits<char> >' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/bits/ostream_insert.h:70: error: invalid use of incomplete type 'struct std::basic_ostream<char, std::char_traits<char> >' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/iosfwd:64: error: declaration of 'struct std::basic_ostream<char, std::char_traits<char> >' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/bits/ostream_insert.h:70: error: invalid use of incomplete type 'struct std::basic_ostream<char, std::char_traits<char> >' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/iosfwd:64: error: declaration of 'struct std::basic_ostream<char, std::char_traits<char> >' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/bits/ostream_insert.h: In function 'void std::__ostream_write(std::basic_ostream<_CharT, _Traits>&, const _CharT*, std::streamsize) [with _CharT = char, _Traits = std::char_traits<char>]': /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/bits/ostream_insert.h:98: instantiated from 'std::basic_ostream<_CharT, _Traits>& std::__ostream_insert(std::basic_ostream<_CharT, _Traits>&, const _CharT*, std::streamsize) [with _CharT = char, _Traits = std::char_traits<char>]' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/bits/basic_string.h:2404: instantiated from 'std::basic_ostream<_CharT, _Traits>& std::operator<<(std::basic_ostream<_CharT, _Traits>&, const std::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]' Batch_Couple.cxx:61: instantiated from here /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/bits/ostream_insert.h:50: error: invalid use of incomplete type 'struct std::basic_ostream<char, std::char_traits<char> >' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/iosfwd:64: error: declaration of 'struct std::basic_ostream<char, std::char_traits<char> >' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/bits/ostream_insert.h:52: error: invalid use of incomplete type 'struct std::basic_ostream<char, std::char_traits<char> >' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/iosfwd:64: error: declaration of 'struct std::basic_ostream<char, std::char_traits<char> >' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/bits/ostream_insert.h:54: error: invalid use of incomplete type 'struct std::basic_ostream<char, std::char_traits<char> >' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/iosfwd:64: error: declaration of 'struct std::basic_ostream<char, std::char_traits<char> >' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/bits/ostream_insert.h:54: error: invalid use of incomplete type 'struct std::basic_ostream<char, std::char_traits<char> >' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/iosfwd:64: error: declaration of 'struct std::basic_ostream<char, std::char_traits<char> >' make[2]: *** [libSalomeBatch_la-Batch_Couple.lo] Error 1 make[2]: Leaving directory `/var/tmp/portage/sci-misc/salome-kernel-3.2.6/work/src3.2.6/KERNEL_SRC_3.2.6/src/Batch' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/sci-misc/salome-kernel-3.2.6/work/src3.2.6/KERNEL_SRC_3.2.6/src' make: *** [all-recursive] Error 1
(In reply to comment #159) > Created an attachment (id=140637) [edit] > salome-kernel patch for my system > > Sure: I'm using 64-bit (~amd64), gcc-4.2.2 and trying to compile salome-kernel, > but not getting anywhere. Attached is a patch that at least moves the build > process along for me. > The problem I was having previously was with a deprecated omniORB call. If you > upgrade to omniORB-4.1.1, you'll see that the class "RefCountServantBase" was > deprecated. Therefore, this patch changes it to ServantBase. I encountered many > other compile errors and managed to fix a few. Please let me know if I should > keep doing this, or if I'm wasting my time. > I think you can continue. I didn't update to omniORB-4.1.1, so I can't check for the deprecated call. For your another problem, I'm not sure and I may say a stupid thing but I have the impression this error comes from gcc. Can you use a previus stable version of gcc (4.1.1 for exemple) and rebuild the package again ?
(In reply to comment #160) Hello Jon I give you the command line use to compile Batch_Couple.cxx : g++ "-DPACKAGE_NAME=\"Salome2 Project\"" -DPACKAGE_TARNAME=\"salome\" -DPACKAGE_VERSION=\"3.2.5\" "-DPACKAGE_STRING=\"Salome2 Project 3.2.5\"" -DPACKAGE_BUGREPORT=\"gboulant@CS\" -DPACKAGE=\"salome\" -DVERSION=\"3.2.5\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBDL=1 -DHAVE_LIBRT=1 -DHAVE_LIBM=1 -DHAVE_NAMESPACES= -DHAVE_PTHREAD=1 -D__x86__=1 -D__linux__=1 -D__OSVERSION__=1 -DOMNIORB=1 -DCORBA_HAVE_POA=1 -DCORBA_ORB_INIT_HAVE_3_ARGS=1 -DCORBA_ORB_INIT_THIRD_ARG=\"omniORB\" -DRM=\"/bin/rm\" -DSH=\"/bin/sh\" -DCP=\"/bin/cp\" -DRSH=\"/usr/bin/rsh\" -DRCP=\"/usr/bin/rcp\" -DSSH=\"/usr/bin/ssh\" -DSCP=\"/usr/bin/scp\" -I. -I. -DHAVE_SOCKET -g -D_DEBUG_ -Wno-deprecated -Wparentheses -Wreturn-type -Wunused -pthread -MT Batch_Couple.lo -MD -MP -MF .deps/Batch_Couple.Tpo -c Batch_Couple.cxx -fPIC -DPIC -o .libs/Batch_Couple.o It works on my computer. The compiler is i686-pc-gnu-linux gcc-4.2.2. It the same version as yours, but a different architecture. The error can comes from : - a bug of gcc for your architecture - a problem with macro definition (see -D options). I know it is not a very helpful post but it's all I can do...
Francois, Did you have the time to take a look at this? Daniel > Created an attachment (id=140466) [edit] > salome-kernel. Continued the cleaning work + openpbs work > > Francois, > > Here is a reworked version of the ebuild: > - I reworked the action of the X and opengl flags. What I had created before > was not so wise, basically Salome _needs_ X11, so, if no X flag, no salome! ... > - I have started to work on the OpenPBS issue but I'll need your help. As I > wrote before, OpenPBS is replaced by Torque. This means that the > check_openpbs.m4 file needs to be patched. I have shyly started but it is far > from complete... At the moment, the configuration sees that there is OpenPBS > (if we use the appropriate flag) but cannot find the library (It is a problem > of name, libpbs became libtorque). So, I started to modify check_openpbs.m4 in > this spirit but apparently I missed part of it... > > testing OpenPBS > --------------- > checking pbs_ifl.h usability... yes > checking pbs_ifl.h presence... yes > checking for pbs_ifl.h... yes > checking for pbs_connect in -lpbs... no > configure: WARNING: OpenPBS library not found > > So, can you take a look at it? > > Thanks in advance > > Daniel >
Created attachment 141242 [details] new gui-ebuild : works in presence of qwt-5
Created attachment 141243 [details, diff] a patch for salome-gui to use qwt-4 instead of qwt-5 when both are installed
Hello Daniel, Sorry for the absence, but I've a lot of work and red papers ! > > Did you have the time to take a look at this? > No, but I will try to solve this tonight ;-) François
Created attachment 141250 [details, diff] a working openpbs patch I added some modifications to your patch and now it works. torque is correctly detected. The compilation step is in progress. I hope there will be no compilation error... François
> > The compilation step is in progress. I hope there will be no compilation > error... > Well, no error for me. Can you confirm ? François
Created attachment 141252 [details] cleaning work
Created attachment 141254 [details, diff] patch for salome-smesh
Created attachment 141256 [details, diff] avoid a copy error during installation
Created attachment 141257 [details, diff] avoid a copy error during installation of the documentation
(In reply to comment #165) > Created an attachment (id=141243) [edit] > a patch for salome-gui to use qwt-4 instead of qwt-5 when both are installed Great! Thanks for the hard work. How to make sure that qwt-4 is installed? I think we should clearly specify it in the dependencies, somehow. Daniel
Hello Francois, > Created an attachment (id=141250) [edit] > a working openpbs patch > > I added some modifications to your patch and now it works. torque is correctly > detected. > > The compilation step is in progress. I hope there will be no compilation > error... > > François It works! Perfect! Similar patches will have to be applied to the other ebuilds, I suspect... Daniel
> It works! Perfect! > Similar patches will have to be applied to the other ebuilds, I suspect... > I don't think. The patched file is check_openpbs.m4. I can see when I was looking for resolve the qwt problem, that m4 files are installed once with a component, and if another component need this file then it looks after the installed file. For exemple, the check_openpbs.m4 will be installed with KERNEL component. If a component is using check_openpbs.m4, then it uses the file under ${KERNEL_ROOT_DIR} and not the file in the source archive. So, I think it is not needed to patch this file again.
Hi Francois, > > It works! Perfect! > > Similar patches will have to be applied to the other ebuilds, I suspect... > > > I don't think. The patched file is check_openpbs.m4. I can see when I was > looking for resolve the qwt problem, that m4 files are installed once with a > component, and if another component need this file then it looks after the > installed file. OK. Even better then... ;) BTW, I saw that you created an smesh ebuild. I had created one. What's the difference? Daniel PS: I am cleaning the kernel ebuild to make it even more gentoo (after advices from the gentoo team, see the opencascade and netgen bugs). I post it within a jiffy.
Created attachment 141462 [details] salome-kernel. Cleaning work Francois, I continued with the cleaning work. I followed the advices given in http://bugs.gentoo.org/show_bug.cgi?id=118656, namely: - Cleaned up the DEPEND list. However, I do think that we can do better. Above all, we need to clarify the situation between DEPEND and RDEPEND - Moved some of the commands from src_compile to src_unpack - Use of use_with and use_enable. This seems to be more reliable. In this respect, everything went fine except for MPI. I simply do not succeed to include the couple without-mpi, with-mpich and without-mpi, without-mpich. Very strange... - Make the econf and einstall more readable... I propose that we follow the same policy regarding the cleaning of the other ebuilds. What do you think? Daniel
(In reply to comment #164) > Created an attachment (id=141242) [edit] > new gui-ebuild : works in presence of qwt-5 The patch is not included in the ebuild. Is it the way it is supposed to be? Daniel
Francois, > > Created an attachment (id=141242) [edit] > > new gui-ebuild : works in presence of qwt-5 > > The patch is not included in the ebuild. Is it the way it is supposed to be? Sorry, apparently I was on crack when I wrote this... ;) I saw it afterward Please find the reworked ebuild (I applied the same changes than the ones I applied to kernel). Daniel
Created attachment 141473 [details] salome-gui: Cleaning work
Created attachment 141474 [details] salome-kernel: corba support is now a flag Hello Francois, I tried to sync kernel and gui. In gui corba is a flag, so I did the same with kernel. To be thoroughly tested though... ;) Daniel
Created attachment 141475 [details] salome-gui: Minor change Minor changes in the rdepend section (that needs to be checked). Please test this ebuild. It works here but I do not use all the switches. Daniel
Hello, This will probably interest Jon. I have successfully built the latest salome-kernel on an amd64 box. However, I use gcc-3.4.6. I did not need Jon patch. So, it is clearly an issue with gcc4 on amd64. Daniel emerge --info Portage 2.1.3.19 (default-linux/amd64/2006.1/desktop, gcc-3.4.6, glibc-2.6.1-r0, 2.6.23-gentoo-r3 x86_64) ================================================================= System uname: 2.6.23-gentoo-r3 x86_64 AMD Athlon(tm) 64 Processor 3800+ Timestamp of tree: Mon, 21 Jan 2008 17:16:01 +0000 app-shells/bash: 3.2_p17-r1 dev-java/java-config: 1.3.7, 2.0.33-r1 dev-lang/python: 2.3.6-r3, 2.4.4-r6 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.10-r5 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 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.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.23-r2 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=athlon64 -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 /var/lib/hsqldb" 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/splash /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-march=athlon64 -O2 -pipe"
Created attachment 141565 [details] salome-kernel: AMD64 improvement Hello, This new ebuild contains a few improvements: - QWT 4.2.0 is the one that would be checked (slot 0) - I tried to correct the issue with lib vs. lib64 on amd64 system. In princip libraries are now installed under a lib64 directory (and not a mix of lib and lib64 as before). This remains to be tested though. Note: Regarding AMD64, the present ebuild works with gcc 3.4.6. Jon's patch for gcc 4 based system has not been included yet. It seems that some other issues need to be solved on such systems (see one of the previous message from Jon) Daniel
Created attachment 141572 [details] salome-gui: AMD64 improvement Applied the same changes than the ones applied to the kernel.
Francois, The few improvements made to the kernel and gui ebuilds have raised on my side a few questions. I think we need to discuss a few points before we move on: - I made CORBA optional (as mentionned in the ./configure --help: Optional Features: --disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no) --enable-FEATURE[=ARG] include FEATURE [ARG=yes] --enable-corba-gen Generate CORBA stuff [default=yes] - You created a patch to deal with the qwt4-5 issue - I triggered the systematic built of qwt4 - I added some support to AMD64 (by choosing either lib or lib64 (the $(get_lib) command from multilib) So here are the results of some tests / thoughts: - If kernel builds correctly without support for Corba, GUI does not! Please do the test and see for yourself. I do not really understand the problem with GUI and what strikes me the most is that according to ./configure, Corba is optional. It might turn out that it is not... Then we need to modify the ebuilds accordingly - I am puzzled by your patch. If I understand it correctly, it created a link called libqwt-salome to libqwt-4.2.0 when qwt5 is installed. Here I have only qwt4 (I removed qwt5). The patch is therefore not triggered. I do need to create manually /usr/lib/libqwt.so as a link to libqwt-4.2.0.so. Otherwise GUI does not built! The point is that the configuration procedure looks for a libqwt.so So here is what I would propose to do instead: - trigger qwt4 using x11-libs/qwt:0 in the dependency list - Use the variable QWTHOME to avoid any mismatch with qwt5 (if qwt is installed). - Make sure the configuration procedure looks for libqwt.4.so and not libqwt.so (That would probably be a patch). I think this would be simpler, more reliable (would work whatever the original status with qwt: not present, v5 present, v4 present, v4 and v5 present)) and would make things simpler with lib64. - I will test tonight the ebuild on my amd64 box. However, I suspect that the GUI (mix between patches / sed and $(get_lib)) will cause troubles. Therefore my previous point. So, what do you think? What's your opinion about the Corba stuff and the qwt issue? Best regards Daniel
Hello Daniel, I'm sorry but I have not a lot of time to work on the ebuilds these days. > So here are the results of some tests / thoughts: > - If kernel builds correctly without support for Corba, GUI does not! Please do > the test and see for yourself. I do not really understand the problem with GUI > and what strikes me the most is that according to ./configure, Corba is > optional. It might turn out that it is not... Then we need to modify the > ebuilds accordingly I will see this as soon as possible. > - I am puzzled by your patch. If I understand it correctly, it created a link > called libqwt-salome to libqwt-4.2.0 when qwt5 is installed. Yes, that's it > Here I have only qwt4 (I removed qwt5). The patch is therefore not triggered. > I do need to create manually /usr/lib/libqwt.so as a link to libqwt-4.2.0.so. > Otherwise GUI does not built! The point is that the configuration procedure > looks for a libqwt.so > So here is what I would propose to do instead: > - trigger qwt4 using x11-libs/qwt:0 in the dependency list > - Use the variable QWTHOME to avoid any mismatch with qwt5 (if qwt is > installed). > - Make sure the configuration procedure looks for libqwt.4.so and not > libqwt.so (That would probably be a patch). That the problem. I didn't found a way to specify a version of a library. With -l flag we specify only a library name. It's why a create a symlink which point on libqwt.so.4. > I think this would be simpler, more reliable (would work whatever the > original status with qwt: not present, v5 present, v4 present, v4 and v5 > present)) and would make things simpler with lib64. It think so. But I don't know how realize that. > - I will test tonight the ebuild on my amd64 box. However, I suspect that the > GUI (mix between patches / sed and $(get_lib)) will cause troubles. Therefore > my previous point. > > So, what do you think? > What's your opinion about the Corba stuff and the qwt issue? I will test Corba to see what error exactly happened. And for qwt, it coulb be a good idea to check the difference between v4 and v5 API to create a patch to compile with libqwt.so.5. I think we can keep this idea for later. First, we need to make reliable ebuild ;-) Best regards. François
Well, I have a problem with salome-kernel : I can't compile it ! I have an error about libstc++.la missing. I'm not sure it's related with your modifications. I will check my last update to see if it's not the source of the problem... François
Hello Francois, I doubt this is related to the changes I included. I've never had the problem you mentionned. This sounds more like a gcc problem to me. Daniel > Well, I have a problem with salome-kernel : I can't compile it ! I have an > error about libstc++.la missing. I'm not sure it's related with your > modifications. I will check my last update to see if it's not the source of the > problem... > > François >
> This sounds more like a gcc problem to me. I think so. I have reinstall gcc recently and libstc++.la has disappeared ! I'm checking how resolve this...
Hello Daniel, I have cleaned up my system, have resolved broken dependencies, etc... It takes a long time because I have to reemerge some big ebuild (kde, openoffice, opencasace), but now, my system is correctly working ! I will test your modifications and make a report later. Best regards. François
My report : - Kernel can be built without corba - Gui can be built without corba too ! I don't know what's your problem, but it work perfectly on my computer. Can you post a log ?
Created attachment 142892 [details, diff] salome-kernel-3.2.6-pyobject.patch I could not build salome-kernel without the attached patch. I will also post the updated ebuild with fixed indention (tabs were interchanged with spaces), and with the new patch being applied.
Created attachment 142894 [details] sci-misc/salome-kernel-3.2.6.ebuild with PyObject and indention fixes (amd64 gcc-4.2) Additional information: # emerge --info 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/toolchain /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 qt3support qt4 readline recode reflection ruby samba sdl session simplexml soap sockets spell spl sqlite sse sse2 ssl svg 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
Ah, note also that I'm using opencascade from the "science" overlay, so sci-libs/opencascade was changed to sci-misc/opencascade.
For reference, I am building salome on an octo-core 32G mem 64-bit xeon machine. Now, I am having sip trouble. When building salome-gui, it will get to the following place and seem to freeze: make[4]: Entering directory `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/src/SALOME_PYQT/SALOME_PYQT_GUI' /usr/bin/sip -t WS_X11 -t Qt_3_3_0 -s ".cc" -c . -I SALOME_PYQT_GUI.sip Note that I have Qt-4 and Qt-3 installed: # emerge =x11-libs/qt-4* =x11-libs/qt-3* -p ... [ebuild R ] x11-libs/qt-4.3.3 [ebuild R ] x11-libs/qt-3.3.8-r4 I have tried both the stable and snapshot version of sip: dev-python/sip-4.7.4_pre20080202 and dev-python/sip-4.7.3 (note that the dev version is a custom ebuild) Any pointers on how to get past this aparent freeze? There is no cpu or memory usage by the sip program.
Created attachment 142905 [details] sci-misc/salome-gui-3.2.6.ebuild sip will freeze when an incorrect version of PyQt is installed. Attached is the corrected dependency structure for it (along with fixed spaces/tabs). Now, however, I am getting the following error: + cd ResExporter + make depend make[3]: Entering directory `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/src/ResExporter' make[3]: Nothing to be done for `depend'. make[3]: Leaving directory `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/src/ResExporter' + for d in Qtx Style DDS QDS SUIT STD CAF CAM SUITApp LogWindow ObjBrowser Prs OBJECT GLViewer VTKViewer SVTK OCCViewer SOCC PyInterp PythonConsole Plot2d SPlot2d SUPERVGraph LightApp ResExporter RegistryDisplay TOOLSGUI Event Session SalomeApp SALOME_SWIG SALOME_PY SALOME_PYQT + cd RegistryDisplay + make depend make[3]: Entering directory `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/src/RegistryDisplay' make[3]: *** No rule to make target `.depend', needed by `depend'. Stop. make[3]: Leaving directory `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/src/RegistryDisplay' + exit 1 make[2]: *** [depend] Error 1 make[2]: Leaving directory `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/src' + exit 1 make[1]: *** [depend] Error 1 make[1]: Leaving directory `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6' make: *** [all] Error 2
Hello Jon I tested your ebuild and your patch for salome-kernel and it doesn't work anymore on y computer ! emerge --info : Portage 2.1.4.4 (default-linux/x86/2007.0/desktop, gcc-4.1.2, glibc-2.6.1-r0, 2.6.23-hardened-r4 i686) ================================================================= System uname: 2.6.23-hardened-r4 i686 Intel(R) Celeron(R) CPU 420 @ 1.60GHz Timestamp of tree: Mon, 18 Feb 2008 11:30:01 +0000 ccache version 2.4 [disabled] app-shells/bash: 3.2_p17-r1 dev-java/java-config: 1.3.7, 2.1.4 dev-lang/python: 2.4.4-r6 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r7 sys-apps/baselayout: 1.12.10-r5 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 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.23-r3 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=i686 -mtune=i686 -pipe -mmmx -msse -msse2" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config /usr/spool/PBS" 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/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -march=i686 -mtune=i686 -pipe -mmmx -msse -msse2" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="ftp://mirror.ovh.net/gentoo-distfiles" LANG="fr_FR@euro" LC_ALL="fr_FR@euro" LINGUAS="fr" MAKEOPTS="-j2" 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/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acl acpi alsa apache2 arts berkdb bitmap-fonts bzip2 cairo cdr cli corba cracklib crypt cups dbus dri dvd dvdr dvdread eds emboss encode esd evo fam firefox fortran gdbm gif gnome gpm gstreamer gtk hal iconv ipv6 isdnlog java jpeg kde kerberos ldap mad midi mikmod mp3 mpeg mpi mudflap ncurses nls nptl nptlonly ogg opengl openmp openpbs oss pam pcre pdf perl png pppd python qt3 qt3support qt4 quicktime readline reflection sdl session spell spl ssl svg tcpd threads tiff truetype truetype-fonts type1-fonts unicode vorbis win32codecs x86 xml xorg xv zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 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" LINGUAS="fr" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS I think the problem is related with the python version. I use 2.4.4 since you use 2.5.1. What do you think about this issue ?
Sorry, but no idea. I think first you forgot the MAKEOPTS="-j1" but it is present. Maybe there is an previous error you didn't see, and this error is a consequence of the previous error... `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/src/RegistryDisplay' > make[3]: *** No rule to make target `.depend', needed by `depend'. Stop. > make[3]: Leaving directory > `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/src/RegistryDisplay' > + exit 1 > make[2]: *** [depend] Error 1 > make[2]: Leaving directory > `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/src' > + exit 1 > make[1]: *** [depend] Error 1 > make[1]: Leaving directory > `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6' > make: *** [all] Error 2 >
Jon, Thank you very much for your contribution. I will test your ebuild and see if I get the same kind of problem that the ones reported by you and Francois. A few comments: - I know about the opencascade sci-libs / sci-misc issue. I have been _heavily_ involved in the creation of the ebuild. However, when it has been included in the overlay, Sebastien chose to change its group (I need to discuss this with him, opencascade _is_ a library...) - Do not change x11-libs/qwt:0 into x11-libs/qwt. This was _not_ a typo. By writing :0 you clearly state which slot (version) you want to have. qwt4 is the one we need (slot 0), _not_ qwt5 - Why PyQt4-3.13? This one _does not_ exist in portage. The one that exists is PyQT-3.13 Having said that, I will try your ebuild with the patch and see what I get. Regards Daniel > Created an attachment (id=142892) [edit] > salome-kernel-3.2.6-pyobject.patch > > I could not build salome-kernel without the attached patch. I will also post > the updated ebuild with fixed indention (tabs were interchanged with spaces), > and with the new patch being applied. >
Hello Francois, > I'm sorry but I have not a lot of time to work on the ebuilds these days. > > > So here are the results of some tests / thoughts: > > - If kernel builds correctly without support for Corba, GUI does not! Please do > > the test and see for yourself. I do not really understand the problem with GUI > > and what strikes me the most is that according to ./configure, Corba is > > optional. It might turn out that it is not... Then we need to modify the > > ebuilds accordingly > I will see this as soon as possible. How strange that it works for you and not for me... :( Here is what I get when I do not use the corba flag: + cd ResExporter + make depend make[3]: Entering directory `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/src/ResExporter' make[3]: Nothing to be done for `depend'. make[3]: Leaving directory `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/src/ResExporter' + for d in Qtx Style DDS QDS SUIT STD CAF CAM SUITApp LogWindow ObjBrowser Prs OBJECT GLViewer VTKViewer SVTK OCCViewer SOCC PyInterp PythonConsole Plot2d SPlot2d SUPERVGraph LightApp ResExporter RegistryDisplay TOOLSGUI Event Session SalomeApp SALOME_SWIG SALOME_PY SALOME_PYQT + cd RegistryDisplay + make depend make[3]: Entering directory `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/src/RegistryDisplay' make[3]: *** No rule to make target `.depend', needed by `depend'. Stop. make[3]: Leaving directory `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/src/RegistryDisplay' + exit 1 make[2]: *** [depend] Error 1 make[2]: Leaving directory `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/src' + exit 1 make[1]: *** [depend] Error 1 make[1]: Leaving directory `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6' make: *** [all] Error 2 * * ERROR: sci-misc/salome-gui-3.2.6 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 3383: Called die * The specific snippet of code: * MAKEOPTS="-j1" emake || die "Compilation failed" * The die message: * Compilation failed Any idea?
Hello, I know what this one is... ;) That's the corba flag. Jon, see my comment above but here you have exactly what happens to me when I do not use the corba flag. Francois, how can it work for you when it does not for us?... Daniel > Sorry, but no idea. I think first you forgot the MAKEOPTS="-j1" but it is > present. Maybe there is an previous error you didn't see, and this error is a > consequence of the previous error... > > `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/src/RegistryDisplay' > > make[3]: *** No rule to make target `.depend', needed by `depend'. Stop. > > make[3]: Leaving directory > > `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/src/RegistryDisplay' > > + exit 1 > > make[2]: *** [depend] Error 1 > > make[2]: Leaving directory > > `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/src' > > + exit 1 > > make[1]: *** [depend] Error 1 > > make[1]: Leaving directory > > `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6' > > make: *** [all] Error 2 > > >
Jon, > Having said that, I will try your ebuild with the patch and see what I get. I tried the ebuild with your patch and I get the following error message: make[3]: Entering directory `/var/tmp/portage/sci-misc/salome-kernel-3.2.6/work/src3.2.6/KERNEL_SRC_3.2.6/src/Batch_SWIG' /bin/sh ../../libtool --tag=CXX --mode=compile i686-pc-linux-gnu-g++ -DPACKAGE_NAME=\"Salome2\ Project\" -DPACKAGE_TARNAME=\"salome\" -DPACKAGE_VERSION=\"3.2.6\" -DPACKAGE_STRING=\"Salome2\ Project\ 3.2.6\" -DPACKAGE_BUGREPORT=\"gboulant@CS\" -DPACKAGE=\"salome\" -DVERSION=\"3.2.6\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBDL=1 -DHAVE_LIBRT=1 -DHAVE_LIBM=1 -DHAVE_NAMESPACES= -DHAVE_PTHREAD=1 -D__x86__=1 -D__linux__=1 -D__OSVERSION__=1 -DOMNIORB=1 -DCORBA_HAVE_POA=1 -DCORBA_ORB_INIT_HAVE_3_ARGS=1 -DCORBA_ORB_INIT_THIRD_ARG=\"omniORB\" -DRM=\"/bin/rm\" -DSH=\"/bin/sh\" -DCP=\"/bin/cp\" -DRSH=\"/usr/bin/rsh\" -DRCP=\"/usr/bin/rcp\" -DSSH=\"/usr/bin/ssh\" -DSCP=\"/usr/bin/scp\" -I. -I/usr/include/python2.4 -I. -I./../Batch -DHAVE_SOCKET -march=pentium4 -O2 -pipe -fomit-frame-pointer -O -Wno-deprecated -Wparentheses -Wreturn-type -Wunused -pthread -MT _libBatch_Swig_la-swig_wrap.lo -MD -MP -MF .deps/_libBatch_Swig_la-swig_wrap.Tpo -c -o _libBatch_Swig_la-swig_wrap.lo `test -f 'swig_wrap.cpp' || echo './'`swig_wrap.cpp mkdir .libs i686-pc-linux-gnu-g++ "-DPACKAGE_NAME=\"Salome2 Project\"" -DPACKAGE_TARNAME=\"salome\" -DPACKAGE_VERSION=\"3.2.6\" "-DPACKAGE_STRING=\"Salome2 Project 3.2.6\"" -DPACKAGE_BUGREPORT=\"gboulant@CS\" -DPACKAGE=\"salome\" -DVERSION=\"3.2.6\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBDL=1 -DHAVE_LIBRT=1 -DHAVE_LIBM=1 -DHAVE_NAMESPACES= -DHAVE_PTHREAD=1 -D__x86__=1 -D__linux__=1 -D__OSVERSION__=1 -DOMNIORB=1 -DCORBA_HAVE_POA=1 -DCORBA_ORB_INIT_HAVE_3_ARGS=1 -DCORBA_ORB_INIT_THIRD_ARG=\"omniORB\" -DRM=\"/bin/rm\" -DSH=\"/bin/sh\" -DCP=\"/bin/cp\" -DRSH=\"/usr/bin/rsh\" -DRCP=\"/usr/bin/rcp\" -DSSH=\"/usr/bin/ssh\" -DSCP=\"/usr/bin/scp\" -I. -I/usr/include/python2.4 -I. -I./../Batch -DHAVE_SOCKET -march=pentium4 -O2 -pipe -fomit-frame-pointer -O -Wno-deprecated -Wparentheses -Wreturn-type -Wunused -pthread -MT _libBatch_Swig_la-swig_wrap.lo -MD -MP -MF .deps/_libBatch_Swig_la-swig_wrap.Tpo -c swig_wrap.cpp -fPIC -DPIC -o .libs/_libBatch_Swig_la-swig_wrap.o swig_wrap.cpp: In function `PyObject* _wrap_new_Job__SWIG_1(PyObject*, PyObject*)': swig_wrap.cpp:1477: error: `Py_ssize_t' was not declared in this scope swig_wrap.cpp:1477: error: expected `;' before "pos" swig_wrap.cpp:1478: error: `pos' was not declared in this scope swig_wrap.cpp:1478: warning: unused variable 'pos' swig_wrap.cpp:1477: warning: unused variable 'Py_ssize_t' swig_wrap.cpp: In function `PyObject* _wrap_new_Job__SWIG_2(PyObject*, PyObject*)': swig_wrap.cpp:1535: error: `Py_ssize_t' was not declared in this scope swig_wrap.cpp:1535: error: expected `;' before "pos" swig_wrap.cpp:1536: error: `pos' was not declared in this scope swig_wrap.cpp:1536: warning: unused variable 'pos' swig_wrap.cpp:1535: warning: unused variable 'Py_ssize_t' swig_wrap.cpp: In function `PyObject* _wrap_new_Job__SWIG_3(PyObject*, PyObject*)': swig_wrap.cpp:1587: error: `Py_ssize_t' was not declared in this scope swig_wrap.cpp:1587: error: expected `;' before "pos" swig_wrap.cpp:1588: error: `pos' was not declared in this scope swig_wrap.cpp:1588: warning: unused variable 'pos' swig_wrap.cpp:1587: warning: unused variable 'Py_ssize_t' swig_wrap.cpp:1615: error: `Py_ssize_t' was not declared in this scope swig_wrap.cpp:1615: error: expected `;' before "pos" swig_wrap.cpp:1616: error: `pos' was not declared in this scope swig_wrap.cpp:1616: warning: unused variable 'pos' swig_wrap.cpp:1615: warning: unused variable 'Py_ssize_t' swig_wrap.cpp: In function `PyObject* _wrap_Job_setParametre(PyObject*, PyObject*)': swig_wrap.cpp:1812: error: `Py_ssize_t' was not declared in this scope swig_wrap.cpp:1812: error: expected `;' before "pos" swig_wrap.cpp:1813: error: `pos' was not declared in this scope swig_wrap.cpp:1813: warning: unused variable 'pos' swig_wrap.cpp:1812: warning: unused variable 'Py_ssize_t' swig_wrap.cpp: In function `PyObject* _wrap_Job_setEnvironnement(PyObject*, PyObject*)': swig_wrap.cpp:1915: error: `Py_ssize_t' was not declared in this scope swig_wrap.cpp:1915: error: expected `;' before "pos" swig_wrap.cpp:1916: error: `pos' was not declared in this scope swig_wrap.cpp:1916: warning: unused variable 'pos' swig_wrap.cpp:1915: warning: unused variable 'Py_ssize_t' swig_wrap.cpp: In function `PyObject* _wrap_JobId_alterJob__SWIG_0(PyObject*, PyObject*)': swig_wrap.cpp:2362: error: `Py_ssize_t' was not declared in this scope swig_wrap.cpp:2362: error: expected `;' before "pos" swig_wrap.cpp:2363: error: `pos' was not declared in this scope swig_wrap.cpp:2363: warning: unused variable 'pos' swig_wrap.cpp:2362: warning: unused variable 'Py_ssize_t' swig_wrap.cpp:2390: error: `Py_ssize_t' was not declared in this scope swig_wrap.cpp:2390: error: expected `;' before "pos" swig_wrap.cpp:2391: error: `pos' was not declared in this scope swig_wrap.cpp:2391: warning: unused variable 'pos' swig_wrap.cpp:2390: warning: unused variable 'Py_ssize_t' swig_wrap.cpp: In function `PyObject* _wrap_JobId_alterJob__SWIG_1(PyObject*, PyObject*)': swig_wrap.cpp:2442: error: `Py_ssize_t' was not declared in this scope swig_wrap.cpp:2442: error: expected `;' before "pos" swig_wrap.cpp:2443: error: `pos' was not declared in this scope swig_wrap.cpp:2443: warning: unused variable 'pos' swig_wrap.cpp:2442: warning: unused variable 'Py_ssize_t' swig_wrap.cpp: In function `PyObject* _wrap_JobId_alterJob__SWIG_2(PyObject*, PyObject*)': swig_wrap.cpp:2503: error: `Py_ssize_t' was not declared in this scope swig_wrap.cpp:2503: error: expected `;' before "pos" swig_wrap.cpp:2504: error: `pos' was not declared in this scope swig_wrap.cpp:2504: warning: unused variable 'pos' swig_wrap.cpp:2503: warning: unused variable 'Py_ssize_t' swig_wrap.cpp: In function `PyObject* _wrap_JobId_setParametre(PyObject*, PyObject*)': swig_wrap.cpp:2659: error: `Py_ssize_t' was not declared in this scope swig_wrap.cpp:2659: error: expected `;' before "pos" swig_wrap.cpp:2660: error: `pos' was not declared in this scope swig_wrap.cpp:2660: warning: unused variable 'pos' swig_wrap.cpp:2659: warning: unused variable 'Py_ssize_t' swig_wrap.cpp: In function `PyObject* _wrap_JobId_setEnvironnement(PyObject*, PyObject*)': swig_wrap.cpp:2720: error: `Py_ssize_t' was not declared in this scope swig_wrap.cpp:2720: error: expected `;' before "pos" swig_wrap.cpp:2721: error: `pos' was not declared in this scope swig_wrap.cpp:2721: warning: unused variable 'pos' swig_wrap.cpp:2720: warning: unused variable 'Py_ssize_t' swig_wrap.cpp: In function `PyObject* _wrap_BatchManager_alterJob__SWIG_0(PyObject*, PyObject*)': swig_wrap.cpp:3448: error: `Py_ssize_t' was not declared in this scope swig_wrap.cpp:3448: error: expected `;' before "pos" swig_wrap.cpp:3449: error: `pos' was not declared in this scope swig_wrap.cpp:3449: warning: unused variable 'pos' swig_wrap.cpp:3448: warning: unused variable 'Py_ssize_t' swig_wrap.cpp:3476: error: `Py_ssize_t' was not declared in this scope swig_wrap.cpp:3476: error: expected `;' before "pos" swig_wrap.cpp:3477: error: `pos' was not declared in this scope swig_wrap.cpp:3477: warning: unused variable 'pos' swig_wrap.cpp:3476: warning: unused variable 'Py_ssize_t' swig_wrap.cpp: In function `PyObject* _wrap_BatchManager_alterJob__SWIG_1(PyObject*, PyObject*)': swig_wrap.cpp:3538: error: `Py_ssize_t' was not declared in this scope swig_wrap.cpp:3538: error: expected `;' before "pos" swig_wrap.cpp:3539: error: `pos' was not declared in this scope swig_wrap.cpp:3539: warning: unused variable 'pos' swig_wrap.cpp:3538: warning: unused variable 'Py_ssize_t' swig_wrap.cpp: In function `PyObject* _wrap_BatchManager_alterJob__SWIG_2(PyObject*, PyObject*)': swig_wrap.cpp:3609: error: `Py_ssize_t' was not declared in this scope swig_wrap.cpp:3609: error: expected `;' before "pos" swig_wrap.cpp:3610: error: `pos' was not declared in this scope swig_wrap.cpp:3610: warning: unused variable 'pos' swig_wrap.cpp:3609: warning: unused variable 'Py_ssize_t' swig_wrap.cpp: At global scope: swig_wrap.cpp:231: warning: 'swig_type_info* SWIG_TypeDynamicCast(swig_type_info*, void**)' defined but not used swig_wrap.cpp:419: warning: 'const char* SWIG_UnpackDataName(const char*, void*, size_t, const char*)' defined but not used swig_wrap.cpp:499: warning: 'void SWIG_PropagateClientData(swig_type_info*)' defined but not used swig_wrap.cpp:1198: warning: 'void* SWIG_Python_MustGetPtr(PyObject*, swig_type_info*, int, int)' defined but not used swig_wrap.cpp:1212: warning: 'int SWIG_Python_ConvertPacked(PyObject*, void*, size_t, swig_type_info*, int)' defined but not used swig_wrap.cpp:4439: warning: 'void SWIG_Python_addvarlink(PyObject*, char*, PyObject*(*)(), int (*)(PyObject*))' defined but not used make[3]: *** [_libBatch_Swig_la-swig_wrap.lo] Error 1 make[3]: Leaving directory `/var/tmp/portage/sci-misc/salome-kernel-3.2.6/work/src3.2.6/KERNEL_SRC_3.2.6/src/Batch_SWIG' make[2]: *** [all] Error 2 make[2]: Leaving directory `/var/tmp/portage/sci-misc/salome-kernel-3.2.6/work/src3.2.6/KERNEL_SRC_3.2.6/src/Batch_SWIG' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/sci-misc/salome-kernel-3.2.6/work/src3.2.6/KERNEL_SRC_3.2.6/src' make: *** [all-recursive] Error 1 * * ERROR: sci-misc/salome-kernel-3.2.6 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 3393: Called die * The specific snippet of code: * emake || die "compilation failed" * The die message: * compilation failed paris salome-kernel # emerge --info Portage 2.1.4.4 (default-linux/x86/2007.0/desktop, gcc-3.4.6, glibc-2.6.1-r0, 2.6.23-gentoo-r3 i686) ================================================================= System uname: 2.6.23-gentoo-r3 i686 Intel(R) Xeon(TM) CPU 2.80GHz Timestamp of tree: Tue, 19 Feb 2008 07:46:01 +0000 ccache version 2.4 [enabled] app-shells/bash: 3.2_p17-r1 dev-java/java-config: 1.3.7, 2.1.4 dev-lang/python: 2.3.6-r4, 2.4.4-r6 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r7 sys-apps/baselayout: 1.12.10-r5 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 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.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -O2 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config /usr/spool/PBS /var/bind /var/lib/hsqldb" 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/splash /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-march=pentium4 -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache distcc distlocks metadata-transfer sandbox sfperms strict unmerge-orphans" GENTOO_MIRRORS="ftp://trumpetti.atm.tut.fi/gentoo/ http://gentoo.osuosl.org http://www.ibiblio.org/pub/Linux/distributions/gentoo" LANG="en_US.UTF-8" LC_ALL="en_US.UTF-8" LDFLAGS="-Wl,-O1" LINGUAS="en sv fr si" MAKEOPTS="-j5" 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/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="3dnow X Xaw3d aac aalib accessibility acl acpi ada adns aiglx aim akode alsa amarok ansi apache2 apm arts asf auctex audiofile automount bash-completion bcmath beagle berkdb bidi bitmap-fonts blas bonobo boost boundchecking bzip2 bzlib c++ cairo calendar caps cdb cdr cgi cjk clearcase cli cmucl cpdflib cpudetection cracklib crypt cscope ctype cups curl curlwrappers cvs d dba dbase dbm dbus dbx deprecated dga dio directfb discouraged divx4linux doc dri dvb dvd dvdr dvdread eds emacs emacs-w3 emboss encode esd ethereal evo exif expat fam fastcgi fbcon ffcall ffmpeg fftw filepro firebird firefox flac flatfile foomaticdb fortran freetds ftp gcc-libffi gcj gd gdbm ggi gif ginac glut gmp gnome gnustep gnutls gphoto2 gpm gsnd gstreamer gtk gtkhtml guile hal haskell hdf5 iconv icq icu idn imagemagick imap imlib innodb iodbc ipv6 isdnlog jabber jack java javascript joystick jpeg junit kde kdeenablefinal kerberos krb4 ladcca lapack lcms ldap leim libgda lzo mad maildir mailwrapper mbox mhash midi mikmod milter mime ming mjpeg mmap mmx mng mono motif mozbranding mp3 mpeg mplayer msession msn mudflap mule mysql mysqli nas ncurses netcdf new-login nis nls nptl nptlonly nsplugin nvidia objc objc++ odbc offensive ofx ogg openal opengl openmp oscar oss pam pascal pcntl pcre pda pdf perforce perl php pic pie plotutils plugin png portaudio posix postgres povray ppds pppd prelude profile python qhull qt3 qt3support qt4 quicktime readline reflection regex ruby samba sasl scanner sdl seamonkey session simplexml slang slp sndfile snmp soap sockets socks5 sox speex spell spl sql sqlite sse sse2 ssl stlport subversion svg svga sysvipc szip tcl tcltk tcpd tetex theora threads tidy tiff tk tokenizer truetype truetype-fonts type1-fonts unicode usb vhosts vorbis wddx win32codecs winbind wmf wxwindows x86 xcomposite xface xft xine xinerama xml xml2 xmlrpc xorg xosd xpm xprint xsl xv xvid yahoo yaz zeo zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 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" LINGUAS="en sv fr si" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS and I have: dev-lang/python-2.3.6-r4 dev-lang/python-2.4.4-r6 dev-python/sip-4.7.3 dev-python/PyQt-3.17.3 dev-python/PyQt4-4.3.3 dev-lang/swig-1.3.31 installed on my system Daniel
Created attachment 143984 [details] An experimental salome-gui Hello, With this experimental salome-gui ebuild, I am trying to solve the issue with qwt-4. The problem is the following: salome-3.2.6 works with qwt4, not with qwt5 (the changes between these 2 libraries is so large that no simple patch is available (see the salome-platform.org forum)) To trigger the qwt4 library as a dependency is not difficult (it's slot 0, qwt:0 in the dependency list). What is a bit tricker is to get the code to compile against libqwt.so.4 and not against libqwt.so. The key seems to be in the check_qwt.m4 file (see the joined patch). Francois proposed to create a link on the fly. I am not so appealled by this solution. I think we should modify the check_qwt.m4 accordingly. My patch in principle checks if libqwt.so.4 is present and compile against it (I replaced -lqwt by -llibqwt.so.4). However, I still end up with strange things: i686-pc-linux-gnu-g++ -march=pentium4 -O2 -pipe -fomit-frame-pointer -I/usr/include/vtk-5.0 -I/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/../KERNEL_SRC_3.2.6/src/Basics/Test -O -Wno-deprecated -Wparentheses -Wreturn-type -Wunused -pthread -DOMNIORB_VERSION=4 -D__x86__ -D__linux__ -DCOMP_CORBA_DOUBLE -DCOMP_CORBA_LONG -I../../include/salome -I. -I. -I/usr/include -I/usr/include/omniORB4 -I/usr/include/COS -I/usr/qt/3/include -DQT_THREAD_SUPPORT -DQT_CLEAN_NAMESPACE -DOCC_VERSION_MAJOR=6 -DOCC_VERSION_MINOR=2 -DOCC_VERSION_MAINTENANCE=0 -DLIN -DLINTEL -DCSFDB -DNo_exception -DHAVE_CONFIG_H -DHAVE_LIMITS_H -DHAVE_WOK_CONFIG_H -DOCC_CONVERT_SIGNALS -I/opt/opencascade-6.2/ros/inc -I/usr/include/vtk-5.0 /usr/include/qwt -I/usr/include -c SVTK_Prs.cxx -fPIC -DPIC -o SVTK_Prs.lo i686-pc-linux-gnu-g++: /usr/include/qwt: linker input file unused because linking not done i686-pc-linux-gnu-g++: /usr/include/qwt: linker input file unused because linking not done cc1plus: /usr/include/qwt: No such file or directory Note the direct /usr/include/qwt, that's weird (it should be -I/usr/include/qwt I suppose). Besides, during the identification I get the following: --------------------------------------------- Testing qwt --------------------------------------------- configure: checking for qwt... QWTHOME not defined checking for /usr/local/lib/libqwt.so.4... no checking for /usr/lib/libqwt.so.4... yes libqwt.so.4 detected in /usr/lib checking qwt.h usability... yes checking qwt.h presence... yes checking for qwt.h... yes checking linking qwt library... unable to link with qwt library QWTHOME environment variable may be wrong So, it finds the library but the test in check_qwt.m4 cannot use it... :( To define QWTHOME did not help (apparently, but please try as well). So, Francois, Jon, I think I am half way but I am stuck. Any help is welcome... Daniel
Created attachment 143986 [details] A reworked patch to use qwt4 and not qwt5 This patch seems to be uncomplete. I am probably not too far off but somehow, I missed something (see my previous message) Any help is welcome... Daniel
> How strange that it works for you and not for me... :( I've found the explanation : - compiling salome-gui without corba works if salome-kernel was built with corba enabled ; - compiling salome-gui without corba doesn't work if salome-kernel was build wihtout corba.
Created attachment 144011 [details, diff] a new working patch for use qwt-4 instead qwt-5
Hello, > > How strange that it works for you and not for me... :( > I've found the explanation : > - compiling salome-gui without corba works if salome-kernel was built with > corba enabled ; > - compiling salome-gui without corba doesn't work if salome-kernel was build > wihtout corba. Well, reading the salome FAQ I think I found the answer to this: 3.9. How CORBA is used in Salome? Most SALOME components are written based on CORBA middleware. Thus they have servers inside. Such servers can be run in special processes or inside the main process (collocated mode). 3.10. What is a light version of Salome? You can use the “light” SALOME configuration if you don’t need CORBA in the application. This configuration provides a GUI framework to write classical one-process GUI applications (SALOME light components). Such components can be run separately or can work together in the same session with classical full components. The light configuration of SALOME does not depend on CORBA. There is an example of light component – “LIGHT_SRC” coming with SALOME Install Wizard. So, it's pretty clear. If we want to be independent of Corba, we need to find the way to cleanly build the "LIGHT" version of Salome (probably the LIGHT_SRC module). I think that's something we can do, once we are happy with the actual structure. So, I propose for the time being to preserve the 'corba' flag but to have it 'on' systematically. When the LIGHT_SRC module is produced, we can try to make all of this work in a flawless way (using the salome-meta ebuild for instance). What do you think? Daniel
Hello Francois, > Created an attachment (id=144011) [edit] > a new working patch for use qwt-4 instead qwt-5 You fixed it! Great... ;) It seems that indeed I was not so far off... ;) Daniel
Created attachment 144061 [details] A finalised salome-gui In the experimental salome-gui that I proposed yesterday, the clean up was not complete with regard to the new way to deal with the qwt4 issue. Now it is... Daniel
Created attachment 144063 [details, diff] A finalised patch to use qwt4 and not qwt5 I corrected a minor issue with the patch (dealing with how QWTHOME is used in the reference to the location of libqwt.so.4). Daniel
Jon, In which context is this patch required? It triggers problem on my system but it is necessary on yours. So, I think we should apply it selectively. Therefore my question... Is it because of gcc-4.2? Is it an amd64 issue? Daniel > Created an attachment (id=142892) [edit] > salome-kernel-3.2.6-pyobject.patch > > I could not build salome-kernel without the attached patch. I will also post > the updated ebuild with fixed indention (tabs were interchanged with spaces), > and with the new patch being applied. >
Hi Daniel, Bad news : the patch didn't work. Salome-gui can be compiled, but there is an error when runSalome is launched due to a missing symbol. The last working patch for salome-gui is http://bugs.gentoo.org/attachment.cgi?id=141243 If someone has an another suggestion... (In reply to comment #211) > Created an attachment (id=144063) [edit] > A finalised patch to use qwt4 and not qwt5 > > I corrected a minor issue with the patch (dealing with how QWTHOME is used in > the reference to the location of libqwt.so.4). > > Daniel >
Created attachment 144084 [details] salome-geom : Gentooification, step 2 I reworked a bit the ebuild to make it more gentoo friendly and more readable... - Reworked the dependency list - Checked the flags - Use of use_enable and use_with - More amd64 friendly It seems that Corba is _not_ optional for this module. It has to be there, apparently. Of course, the ebuild remains to be thoroughly tested.
Hi! > Bad news : the patch didn't work. Salome-gui can be compiled, but there is an > error when runSalome is launched due to a missing symbol. Yes, same thing here. I suspect that it does not find the library. Is it possible to get a list of the libraries (and their locations) a binary relies on? Daniel
Created attachment 144086 [details, diff] a new working patch for use qwt-4 instead qwt-5
(In reply to comment #216) > Created an attachment (id=144086) [edit] > a new working patch for use qwt-4 instead qwt-5 > Daniel, I found the solution to solve our problem. Can you test it please ?
> Is it possible to get a list of the libraries (and their locations) a binary > relies on? > > Daniel > It is possible for dynamic librairies with the ldd command.
Hello, > Daniel, > > I found the solution to solve our problem. Can you test it please ? I tested it. It works! Perfect! That was not a hard one in principle but not an easy one in term of syntax... -l:libqwt.so.4 I will never forget that one... ;) Daniel
Created attachment 144089 [details] salome-gui : Minor syntaxic corrections
Created attachment 144091 [details] salome-geom : Minor corrections
Created attachment 144093 [details] salome-med : Gentooification, step 2 I reworked a bit the ebuild to make it more gentoo friendly and more readable... - Reworked the dependency list - Checked the flags - Use of use_enable and use_with - More amd64 friendly It seems that Corba is _not_ optional for this module. It has to be there, apparently. Of course, the ebuild remains to be thoroughly tested. BTW, do you know what LSF is? It's an option in .configure but I do not know to what it relates. Daniel
Created attachment 144098 [details] salome-superv : Gentooification, step 2 Same global remarks than previously. Daniel
Created attachment 144105 [details] salome-superv : Minor corrections
Created attachment 144107 [details] salome-visu : Gentooification, step 2 Same remarks as previously regarding the update of this ebuild. Daniel
Created attachment 144117 [details] salome-smesh : Gentooification, step 2 Dito
Created attachment 144119 [details] salome-kernel : Minor corrections
Francois, I think we are in a pretty good shape now with this set of ebuilds (even though the impact of some flags need to be carefully checked). Some modules are still missing (NETGENPLUGIN CALCULATOR COMPONENT PYCALCULATOR GHS3DPLUGIN...) What do you think? Should we concentrate on them? I suppose it will probably not be very difficult (we have a good basis for ebuilds and in many cases, the patches were of the same nature and fairly trivial...) It's more a question of time than anything else... Daniel
(In reply to comment #228) > Francois, > > I think we are in a pretty good shape now with this set of ebuilds (even though > the impact of some flags need to be carefully checked). > Some modules are still missing (NETGENPLUGIN CALCULATOR COMPONENT PYCALCULATOR > GHS3DPLUGIN...) > What do you think? Should we concentrate on them? > I suppose it will probably not be very difficult (we have a good basis for > ebuilds and in many cases, the patches were of the same nature and fairly > trivial...) > It's more a question of time than anything else... > > Daniel > Hi Daniel, Thanks for your works. For the missings component, I think we can do VISU, COMPONENT and PYCALCULTOR because salome complains about these modules if there are not installed. Afer that, I think we have to focus on use flags. What do you think about this ? Best regards François
Francois, > For the missings component, I think we can do VISU, COMPONENT and PYCALCULTOR > because salome complains about these modules if there are not installed. VISU is already there, on this bug report. Checked the ebuilds and the patches. Daniel
Created attachment 144182 [details] salome-component: First ebuild First ebuild for Salome-component. A fairly simple one to fix... ;)
Created attachment 144184 [details, diff] salome-component accompanying patch
Created attachment 144185 [details] salome-pycalculator : First ebuild Here is the first ebuild for the pycalculator. - I am not so sure it needs salome-gui as a dependency - I have a sandbox violation: f test VERSIONX != X; then \ /usr/bin/install -c ./bin/VERSION /var/tmp/portage/sci-misc/salome-pycalculator-3.2.6/image///opt/salome-3.2.6/PYCALCULATOR/bin/salome; \ fi + for d in idl src + cd idl + make install make[1]: Entering directory `/var/tmp/portage/sci-misc/salome-pycalculator-3.2.6/work/src3.2.6/PYCALCULATOR_SRC_3.2.6/idl' /usr/bin/install -c -d /opt/salome-3.2.6/PYCALCULATOR/lib/python2.4/site-packages/salome /usr/bin/install -c -d /var/tmp/portage/sci-misc/salome-pycalculator-3.2.6/image///opt/salome-3.2.6/PYCALCULATOR/idl/salome ACCESS DENIED mkdir: /opt/salome-3.2.6/PYCALCULATOR /usr/bin/install -c -m 644 PYCALCULATOR_Gen.idl /var/tmp/portage/sci-misc/salome-pycalculator-3.2.6/image///opt/salome-3.2.6/PYCALCULATOR/idl/salome /usr/bin/install: cannot create directory `/opt/salome-3.2.6/PYCALCULATOR': Permission denied make[1]: *** [install-pyidl] Error 1 make[1]: Leaving directory `/var/tmp/portage/sci-misc/salome-pycalculator-3.2.6/work/src3.2.6/PYCALCULATOR_SRC_3.2.6/idl' + exit 1 make: *** [install] Error 1 I suspect the Makefile.in in the idl directory to be responsible. Unfortunately I do not know how to patch it. Francois, any inspiration?... Daniel
Created attachment 144187 [details, diff] salome-pycalculator : First patch Here is the patch accompanying the salome-pycalculator ebuild. The patch is uncomplete though (see my previous comment) and the ebuild does not work yet.
Created attachment 144188 [details] salome-meta : updated to reflect the add of component and pycalculator
> VISU is already there, on this bug report. Checked the ebuilds and the patches. > Oups, sorry, I didn't see it !
> I suspect the Makefile.in in the idl directory to be responsible. Unfortunately > I do not know how to patch it. > > Francois, any inspiration?... > I'll test it to see exactly where the problem is in the Makefile and try to patch it.
(In reply to comment #231) > Created an attachment (id=144182) [edit] > salome-component: First ebuild > > First ebuild for Salome-component. A fairly simple one to fix... ;) I have this strange message with the component. Do you have it? **************************************************************** * Warning: PYCALCULATOR not found in resources. * Module will not be available **************************************************************** SetSignal( Standard_False ) is not implemented... **************************************************************** * Warning: library Component cannot be found * Module will not be available **************************************************************** Calling QApplication::exit() with exit code = 0 th. 3015939776 end of trace I do not really understand why Salome do not find the Component libraries when ldconfig -v finds them... Very strange... Daniel
> **************************************************************** > * Warning: PYCALCULATOR not found in resources. > * Module will not be available > **************************************************************** > SetSignal( Standard_False ) is not implemented... > **************************************************************** > * Warning: library Component cannot be found > * Module will not be available > **************************************************************** > Calling QApplication::exit() with exit code = 0 > th. 3015939776 end of trace > > I do not really understand why Salome do not find the Component libraries when > ldconfig -v finds them... Very strange... Is the environment variable COMPONENT_ROOT_DIR set correctly ?
(In reply to comment #239) > > **************************************************************** > > * Warning: PYCALCULATOR not found in resources. > > * Module will not be available > > **************************************************************** > > SetSignal( Standard_False ) is not implemented... > > **************************************************************** > > * Warning: library Component cannot be found > > * Module will not be available > > **************************************************************** > > Calling QApplication::exit() with exit code = 0 > > th. 3015939776 end of trace > > > > I do not really understand why Salome do not find the Component libraries when > > ldconfig -v finds them... Very strange... > Is the environment variable COMPONENT_ROOT_DIR set correctly ? > /etc/env.d $ cat 90salome-component-3.2.6 COMPONENT_ROOT_DIR=/opt/salome-3.2.6/COMPONENT LDPATH=/opt/salome-3.2.6/COMPONENT/lib/salome PATH=/opt/salome-3.2.6/COMPONENT/bin/salome First thing I checked... I even did an etc-update and env-update coupled with a source /etc/profile to be sure env | grep ROOT SUPERV_ROOT_DIR=/opt/salome-3.2.6/SUPERV KERNEL_ROOT_DIR=/opt/salome-3.2.6/KERNEL COMPONENT_ROOT_DIR=/opt/salome-3.2.6/COMPONENT VISU_ROOT_DIR=/opt/salome-3.2.6/VISU CASROOT=/opt/opencascade-6.2/ros SMESH_ROOT_DIR=/opt/salome-3.2.6/SMESH MED_ROOT_DIR=/opt/salome-3.2.6/MED GEOM_ROOT_DIR=/opt/salome-3.2.6/GEOM VTK_DATA_ROOT=/usr/share/vtk/data ROOTPATH=/usr/kde/3.5/sbin:/usr/kde/3.5/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/athena/bin:/usr/i686-pc-linux-gnu/gcc-bin/3.4.6:/opt/blackdown-jdk-1.4.2.03/bin:/opt/blackdown-jdk-1.4.2.03/jre/bin:/usr/qt/3/bin:/opt/opencascade-6.2/ros/Linux/bin/:/usr/i686-pc-linux-gnu/gnat-gcc-bin/4.1:/usr/libexec/gnat-gcc/i686-pc-linux-gnu/4.1:/opt/firebird/bin:/usr/games/bin:/usr/share/omniORB/bin/scripts:/opt/salome-3.2.6/COMPONENT/bin/salome:/opt/salome-3.2.6/GEOM/bin/salome:/opt/salome-3.2.6/GUI/bin/salome:/opt/salome-3.2.6/KERNEL/bin/salome:/opt/salome-3.2.6/MED/bin/salome:/opt/salome-3.2.6/SMESH/bin/salome:/opt/salome-3.2.6/SUPERV/bin/salome:/opt/salome-3.2.6/VISU/bin/salome MKL_ROOT=/opt/intel/mkl GUI_ROOT_DIR=/opt/salome-3.2.6/GUI
Created attachment 144198 [details] a working pycalculator ebuild Daniel, I resolved the sandbox problem. Can you test the ebuild please ? If it corretly works, we have to modify it to take into account the right version of python.
Francois, > I resolved the sandbox problem. Can you test the ebuild please ? > If it corretly works, we have to modify it to take into account the right > version of python. It builds indeed. Great! I have a few comments questions: - Why is this python stuff put under /usr/lib/python2.4/site-packages/? The other modules store things under /opt/salome-3.2.6/"module_name"/lib/python2.4/site-packages/salome How make sure that python will indeed find the files it needs in these directories BTW? - When I start runSalome, I end up with: SetSignal( Standard_False ) is not implemented... **************************************************************** * Warning: library Component cannot be found * Module will not be available **************************************************************** **************************************************************** * Warning: library PyCalculator cannot be found * Module will not be available **************************************************************** Calling QApplication::exit() with exit code = 0 th. 3015055040 end of trace Is it the case for you as well? I might have to reboot the machine, as a matter of fact. Daniel
> - Why is this python stuff put under /usr/lib/python2.4/site-packages/? > The other modules store things under > /opt/salome-3.2.6/"module_name"/lib/python2.4/site-packages/salome Well, I don't know ^^. I just put these file where I think they must be. I've just seen some package install files into /opt/salome-3.2.6/"module_name"/lib/python2.4/site-packages/salome. > How make sure that python will indeed find the files it needs in these > directories BTW? I don't know. We must to check this point. > - When I start runSalome, I end up with: > SetSignal( Standard_False ) is not implemented... > **************************************************************** > * Warning: library Component cannot be found > * Module will not be available > **************************************************************** > **************************************************************** > * Warning: library PyCalculator cannot be found > * Module will not be available > **************************************************************** > Calling QApplication::exit() with exit code = 0 > th. 3015055040 end of trace > > Is it the case for you as well? I might have to reboot the machine, as a matter > of fact. I also have this problem but no idea.
Daniel, I found some information on the salome website http://www.salome-platform.org/forum/?thread=1005&groupid=10&forumid=9&message_id=1015 "Two last messages (about Component and PyCalculator) are just warnings to inform that these modules do not have GUI libraries - and it is OK with them." So I think it is normal
Hello, > I found some information on the salome website > http://www.salome-platform.org/forum/?thread=1005&groupid=10&forumid=9&message_id=1015 > > > "Two last messages (about Component and PyCalculator) are just warnings to > inform that these modules do not have GUI libraries - and it is OK with them." > > So I think it is normal Fine! That basically means that the only thing we need to do with these two ebuilds is to remove the dependency on the GUI. We are getting closer and closer Francois... ;) What remains is this python issue and Jon's patch. - Regarding the python thing, I think we should put the python files under /opt/salome, for consistency and find out how to make sure that these files will be found and used by Python. - Regarding Jon's patch in Kernel, it does not work for me. I am curious to hear from Jon in which case the patch is necessary (amd64? gcc-4.2? something else). Daniel
> That basically means that the only thing we need to do with these two ebuilds > is to remove the dependency on the GUI. I think we can do that. > > We are getting closer and closer Francois... ;) YYYYYYEEEEEEEEESSSSSSSSS ! > What remains is this python issue and Jon's patch. > - Regarding the python thing, I think we should put the python files under > /opt/salome, for consistency and find out how to make sure that these files > will be found and used by Python. Ok, I'll search on the internet if a found some information about how add a directory to python's search path. > - Regarding Jon's patch in Kernel, it does not work for me. I am curious to > hear from Jon in which case the patch is necessary (amd64? gcc-4.2? something > else). It doesn't work for me too. I think it is related with the python version. He uses version 2.5
> > > What remains is this python issue and Jon's patch. > > - Regarding the python thing, I think we should put the python files under > > /opt/salome, for consistency and find out how to make sure that these files > > will be found and used by Python. > Ok, I'll search on the internet if a found some information about how add a > directory to python's search path. It seems that the environment variable "PYTHONPATH" is what we are looking for...
Hello, > > > - Regarding the python thing, I think we should put the python files under > > > /opt/salome, for consistency and find out how to make sure that these files > > > will be found and used by Python. > > Ok, I'll search on the internet if a found some information about how add a > > directory to python's search path. > It seems that the environment variable "PYTHONPATH" is what we are looking > for... That would basically mean for every ebuild, add a line at the end, adding to the 90salome-'module' a PYTHONPATH. Regarding salome-pycalculator, to slightly modify what you added to point to /opt/salome/... like the others. Can you do that? Daniel
Created attachment 144223 [details] correct the installation path for python modules There is one thing to do : to determine the version of python. But I have no idea to do this properly
Hello Francois, > There is one thing to do : to determine the version of python. But I have no > idea to do this properly I do... ;) Daniel
Created attachment 144305 [details] salome-pycalculator : Fix the python issue - Get automatically the right python version number by using the python class - Removed the unnecessary dependency to salome-gui Daniel
Created attachment 144306 [details] salome-component: Added PYTHONPATH to the /etc/env.d file Corrected salome-component by: - removing dependency to salome-gui - Added PYTHONPATH
Created attachment 144308 [details] salome-geom: Added PYTHONPATH
Created attachment 144310 [details] salome-gui: Added PYTHONPATH
Created attachment 144311 [details] salome-kernel: Added PYTHONPATH
Created attachment 144313 [details] salome-med: Added PYTHONPATH
Created attachment 144314 [details] salome-smesh: Added PYTHONPATH
Created attachment 144316 [details] salome-superv: Added PYTHONPATH
Created attachment 144318 [details] salome-pycalculator : Fixed a minor bug
Created attachment 144320 [details] salome-visu: Added PYTHONPATH
Hello Francois, Everything seems to build flawlessly on my box, calling the salome-meta ebuild, I get everything installed apparently correctly. I have a minor problem though, could you please tell me if you experience it? When I click on the Help/Module Help menu, I only get help for the Kernel module. Not for the rest. It feels strange. What do you think? Daniel
I haven't tested all the flags so far. OpenPBS should be easy to test (at least to check that salome builds). Regarding MPI I am more suspicious and unfortunately, unable to check that it works. That would probably be a task for Jon (considering the hardware at his disposal). Daniel
Hello Daniel, THank for your works ! And it is so... easy to get the python version ! The problem was to know how to do ! (like the :libqwt.so.4 ;-)) > I have a minor problem though, could you please tell me if you experience it? > When I click on the Help/Module Help menu, I only get help for the Kernel > module. Not for the rest. It feels strange. What do you think? I have also this problem, and after check, the help is loaded by the GUI module. The code is in src/LighApp/LighApp_Application.cxx. The problem is the help is search in MODULE_ROOT_DIR/doc and not MODULE_ROOT_DIR/share/doc, except for the KERNEL module ! It's why the help for KERNEL module appears. So 2 solutions : - modify each ebuild to put its documentation into ROOT_MODULE_DIR/doc instead of ROOT_MODULE_DIR - patch the LightApp_Application.cxx source files. What do you think about this ? François
Hello, > THank for your works ! And it is so... easy to get the python version ! The > problem was to know how to do ! (like the :libqwt.so.4 ;-)) Indeed... ;) Let's say that I had to struggle with this one before... ;) > I have also this problem, and after check, the help is loaded by the GUI > module. The code is in src/LighApp/LighApp_Application.cxx. The problem is the > help is search in MODULE_ROOT_DIR/doc and not MODULE_ROOT_DIR/share/doc, except > for the KERNEL module ! It's why the help for KERNEL module appears. OK. > So 2 solutions : > - modify each ebuild to put its documentation into ROOT_MODULE_DIR/doc instead > of ROOT_MODULE_DIR > - patch the LightApp_Application.cxx source files. In one case, we need to modify ebuilds, in the other case we need to add a minor patch. Let me play a bit with the ebuild, to see if it requires a lot of work on that front or not... Daniel
Hello, > In one case, we need to modify ebuilds, in the other case we need to add a > minor patch. > Let me play a bit with the ebuild, to see if it requires a lot of work on that > front or not... I tried to play with the --docdir flag, removing the /share and it did not help.... So, I would suggest to patch the LightApp_Application.cxx files. Can you take care of it? Daniel
> I tried to play with the --docdir flag, removing the /share and it did not > help.... I do it too and it works for GUI component. Which module did you try ? > So, I would suggest to patch the LightApp_Application.cxx files. > Can you take care of it? I can do it if it is really necessary, but as I said before, I could modify the docdir flag without problem. I will try an another module...
Hello, > I do it too and it works for GUI component. Which module did you try ? MED. > > So, I would suggest to patch the LightApp_Application.cxx files. > > Can you take care of it? > I can do it if it is really necessary, but as I said before, I could modify the > docdir flag without problem. I will try an another module... If the simple ebuild modification works for you, then let's choose this option. Daniel
Daniel, In fact, there are 2 kinds of documentations : - a documentation for the GUI - a documentation for the API Under salome, only the GUI doc is available, not the API. Unfortunately, MED component comes without GUI's doc. It is why you think it doesn't work. I'll post modified ebuilds later. Best regards. François
Created attachment 144347 [details] salome-component : change doc installation path
Created attachment 144348 [details] salome-geom : change doc installation path
Created attachment 144350 [details] salome-gui : change doc installation path
Created attachment 144352 [details] salome-med : change doc installation path
Created attachment 144353 [details] salome-pycalculator : change doc installation path
Created attachment 144354 [details] salome-smesh : change doc installation path
Created attachment 144356 [details] salome-superv : change doc installation path
Created attachment 144357 [details] salome-visu : change doc installation path
Daniel, can you attach your patch for salome-smesh please ? I did'nt found salome-smesh-3.2.6_makefiles.patch. Thank you ! François
Created attachment 144557 [details, diff] salome-smesh: Makefile patch Joined the missing patch to salome-smesh and removed old ebuilds Daniel
Comment on attachment 140474 [details, diff] salome-smesh: complementary patch to the one already provided by Francois Francois, the pactch you required was already there... ;) I added it again anyway
Hello Francois, Jon I have been rebuilding all the packages using the debug and openpbs flag. No compilation issue whatsoever... Besides, now I get all the documentation browsable through the help menu. Thanks Francois! Here is a short list of the few things that remain to be done: - OpenPBS support builds but I don't know how to test that it really works... - MPI support has not been tested. I have no mean to do that. Jon, can you? - Jon's patch which is a problem for Francois and I but which is necessary to Jon. How to include it in a flawless way? - Support for Corba and lightSalome. What to do and how to do it? Daniel
Hello Daniel, > Francois, the pactch you required was already there... ;) Oups, I missed it. Sorry ^^. And to answer your question, I have no idea. I don't know how to test neither openPBS nor MPI. For the Jon's patch, I suspect it is related to the version of Python. Best regards. François
Hi guys! Seems you did some serious work here :). I just tried to try ;) the ebuilds but apart from the fact that the salome file server seems to be down currently, it is quite a pain to manually download all the ebuilds and patches (of which there are several versions with identical names btw). Judging from the comments below, the ebuilds have come a long way since comments #23 and #25 and testing would be a lot easier from an overlay...
Hi guys, excellent work. Just one comment, from the science overlay, opencascade resides under sci-misc and not sci-lib? Dewald
(In reply to comment #283) > Hi guys, excellent work. Just one comment, from the science overlay, > opencascade resides under sci-misc and not sci-lib? > > Dewald Thanks Dewald. Regarding this issue I have a comment... I am one of the authors of the Opencascade ebuild. Alvaro helped me to settle things down. I asked a few weeks ago Sebastien F. if he could put the opencascade ebuild in the science overlay. He kindly did. However... I have always treated opencascade as a set of library, therefore I had chosen sci-libs. Sebastien chose sci-misc. I don't really know why... So, in your humble opinion, should it be in sci-libs or in sci-misc? Daniel
(In reply to comment #280) Dewald, as you can see, there a few minor questions left. Can you help us regarding OpenPBS and MPI? Daniel > Hello Francois, Jon > > I have been rebuilding all the packages using the debug and openpbs flag. No > compilation issue whatsoever... Besides, now I get all the documentation > browsable through the help menu. Thanks Francois! > > Here is a short list of the few things that remain to be done: > - OpenPBS support builds but I don't know how to test that it really works... > - MPI support has not been tested. I have no mean to do that. Jon, can you? > - Jon's patch which is a problem for Francois and I but which is necessary to > Jon. How to include it in a flawless way? > - Support for Corba and lightSalome. What to do and how to do it? > > Daniel >
I have the same error that http://bugs.gentoo.org/show_bug.cgi?id=155974#c160 during the compilation of salome-kernel. I used the last ebuild and my emerge --info is Portage 2.1.4.4 (default-linux/x86/2007.0/desktop, gcc-4.2.0, glibc-2.6.1-r0, 2.6.23-gentoo-r8 i686) ================================================================= System uname: 2.6.23-gentoo-r8 i686 Intel(R) Pentium(R) M processor 1.80GHz Timestamp of tree: Sun, 09 Mar 2008 09:00:01 +0000 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] app-shells/bash: 3.2_p17-r1 dev-java/java-config: 1.3.7, 2.1.4 dev-lang/python: 2.4.4-r9 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 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.23-r3 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium-m -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/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/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -march=pentium-m -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--with-bdeps y" FEATURES="distlocks fixpackages metadata-transfer sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="fr_FR.UTF-8" LC_ALL="fr_FR.UTF-8" LINGUAS="en en_GB fr" MAKEOPTS="-j2" 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/zugaina /usr/portage/local/layman/sunrise /usr/portage/local/layman/berkano /usr/portage/local/layman/voip /usr/portage/local/layman/liquidx /usr/portage/local/layman/science /usr/portage/local/layman/java-gcj-overlay /usr/portage/local/layman/java-overlay /usr/portage/local/layman/gentopia /usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X a52 aac aalib acl acpi alsa arts avahi avisynth bash-completion berkdb bluetooth bzip2 cairo cdr clflush cli cmov cracklib crypt cups cx8 daap dbus de dri dts dvd dvdr dvdread eds emboss encode esd est evo fam fbcon ffmpeg firefox fortran fpu fpu_exception fxsr gd gdbm gif gpm gstreamer gtk hal iconv ipv6 isdnlog jpeg jpeg2k kde kdeenablefinal kdehiddenvisibility kerberos lcms libcaca libnotify logrotate lua mad mca mce midi mikmod mmx mmxext mp3 mpeg msr mtrr mudflap ncurses nfs nls nptl nptlonly ogg opengl openmp oss pam pat pbe pcre pdf perl pge png pppd pse python qt3 qt3support qt4 quicktime readline reflection samba sdl sep session socks5 spell spl ss sse sse2 ssl svg tcltk tcpd tetex threads tiff tm tm2 truetype tsc unicode utempter v4l v4l2 vhosts vme vorbis win32codecs wp x264 x86 xcomposite xml xorg xv xvid zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 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 synaptics mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en en_GB fr" LIRC_DEVICES="sir" USERLAND="GNU" VIDEO_CARDS="vesa fbdev radeon" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS Is that related to the version of gcc ?
(In reply to comment #286) > I have the same error that http://bugs.gentoo.org/show_bug.cgi?id=155974#c160 > during the compilation of salome-kernel. > Is that related to the version of gcc ? Hello! I don't know. Please try the following: comment out in the ebuild the following line: #epatch ${FILESDIR}/${P}-pyobject.patch and tell us if it worked. One more thing: You need the corba flag on for salome-kernel and salome-gui This will be taken care of more elegantly in the future. Daniel
> > I don't know. Please try the following: comment out in the ebuild the following > line: #epatch ${FILESDIR}/${P}-pyobject.patch and tell us if it worked. > > One more thing: You need the corba flag on for salome-kernel and salome-gui > This will be taken care of more elegantly in the future. > Hi, I tried again with this line uncommented but still I get the same error. I add the corba flag too to the both packages. Any clue ? pierre,
(In reply to comment #286) > I have the same error that http://bugs.gentoo.org/show_bug.cgi?id=155974#c160 > during the compilation of salome-kernel. > [...] > Is that related to the version of gcc ? > the same error is observed here: https://llistes.projectes.lafarga.cat/pipermail/clam-devel/2007/000718.html but I didn't figure out how to solve it yet.
(In reply to comment #289) > (In reply to comment #286) > > I have the same error that http://bugs.gentoo.org/show_bug.cgi?id=155974#c160 > > during the compilation of salome-kernel. > > [...] > > Is that related to the version of gcc ? > > > > the same error is observed here: > https://llistes.projectes.lafarga.cat/pipermail/clam-devel/2007/000718.html > > but I didn't figure out how to solve it yet. > Well I created this patch: >>> --- src3.2.6/KERNEL_SRC_3.2.6/src/Batch/Batch_Couple.cxx.bak 2007-04-24 17:34:17.000000000 +0200 +++ src3.2.6/KERNEL_SRC_3.2.6/src/Batch/Batch_Couple.cxx 2008-03-12 00:37:09.000000000 +0100 @@ -26,7 +26,7 @@ * Projet : Salome 2 * */ - +#include <iostream> #include "Batch_Couple.hxx" using namespace std; <<< and added this line to the ebuild # epatch ${FILESDIR}/${P}-pyobject.patch epatch ${FILESDIR}/${P}-Batch_Couple.patch It corrects the error for me and salome-kernel is now merged :)
Hi, (again) I took the last ebuild for salome-gui but I get this 'simple' error: --------------------------------------------- copying resource files, shell scripts, and xml files --------------------------------------------- ./bin/runLightSalome.csh ./bin/runLightSalome.sh --------------------------------------------- generating Makefiles and configure files --------------------------------------------- ln: `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/./salome_adm': cannot overwrite directory configure: creating ./config.status config.status: error: cannot find input file: ./salome_adm/unix/SALOMEconfig.h.in !!! Please attach the following file when seeking support: !!! /var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/config.log * * ERROR: sci-misc/salome-gui-3.2.6 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 3404: Called econf 'src_compile' 'src_compile' '--prefix=/opt/salome-3.2.6/GUI' '--datadir=/opt/salome-3.2.6/GUI/share/salome' '--docdir=/opt/salome-3.2.6/GUI/doc/salome' '--infodir=/opt/salome-3.2.6/GUI/share/info' '--libdir=/opt/salome-3.2.6/GUI/lib/salome' '--disable-debug' '--enable-production' '--without-cppunit' '--with-opengl' '--without-openpbs' '--disable-salomeObject' '--disable-vtkViewer' '--disable-occViewer' '--disable-supervGraphViewer' '--disable-plot2dViewer' '--enable-glViewer' * ebuild.sh, line 513: 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-misc/salome-gui-3.2.6/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sci-misc/salome-gui-3.2.6/temp/environment'. * This ebuild is from an overlay: '/usr/local/portage/' * with /var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/config.log [...] configure:15510: checking for Kernel... configure:15528: result: for ${KERNEL_ROOT_DIR}: /opt/salome-3.2.6/KERNEL configure:15586: result: Using Kernel module distribution in /opt/salome-3.2.6/K ERNEL configure:15611: result: for Kernel: yes configure:15624: checking for cppunit... configure:15634: result: "select no as path to CPPUNIT" configure:15744: result: no configure:15746: WARNING: cppunit not found configure:16227: creating ./config.status ## ---------------------- ## ## Running config.status. ## ## ---------------------- ## This file was extended by config.status, which was generated by GNU Autoconf 2.61. Invocation command line was CONFIG_FILES = CONFIG_HEADERS = CONFIG_LINKS = CONFIG_COMMANDS = $ ./config.status on ticapix config.status:822: error: cannot find input file: ./salome_adm/unix/SALOMEconfig .h.in ## ---------------- ## ## Cache variables. ## ## ---------------- ## [...] I took a look inside the directories and it's right that ln can't link directories. Strange error.
> I have always treated opencascade as a set of library, therefore I had chosen > sci-libs. Sebastien chose sci-misc. I don't really know why... > So, in your humble opinion, should it be in sci-libs or in sci-misc? > > Daniel > If I understand the function of opencascade as a piece of software correctly it is a library and not a standalone program,
> Dewald, as you can see, there a few minor questions left. > Can you help us regarding OpenPBS and MPI? > > Daniel Hi Daniel, Presently my amd64 4200+ box is available for compiling testing purposes. Unfortunately I am no programmer, just a mech eng who wants to use and understand FOSS tools. At the moment I don't have time to tinker with code, I am currently writing up my masters and the deadlines looms. However, I am more than willing to donate some cpu time for compiling purposes while I type away on my masters! (Having things in an overlay would make things easier for that too!) Dewald
Created attachment 145883 [details, diff] salome-kernel-3.2.6-Batch_Couple.patch: Allow salome-kernel to be built with gcc-4.2.0 This is the patch proposed by Pierre. Salome-kernel compiles fine with it on x86 gcc-3.4.6 and Pierre needed it to get salome-kernel built on x86 gcc-4.2.0 Jon, Francois, Dewald, does it work on your systems? Daniel
Created attachment 145885 [details] salome-kernel: Added Pierre's patch (support of gcc-4.2.0) Hello, This ebuild includes three changes: a) Include Pierre's patch (compiles on gcc-4.2.0) b) replace: dodir /etc/env.d insinto /etc/env.d doins 90${P} by: doenvd 90${P} c) Removed the boost warning (not relevant anymore) Slowly but surely b) and c) will have to be applied to all the ebuilds. Daniel
Salut Pierre, I could not reproduce this, neither with: sci-misc/salome-gui-3.2.6 USE="corba doc glviewer occviewer opengl openpbs plot2dviewer pyconsole salomeobject supervgraphviewer vtkviewer -debug -mpi" nor with USE="-openpbs -salomeobject -vtkviewer -occviewer -supervgraphviewer -plot2dviewer" emerge salome-gui > I took the last ebuild for salome-gui but I get this 'simple' error: > ln: > `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/./salome_adm': > cannot overwrite directory > configure: creating ./config.status > config.status: error: cannot find input file: > ./salome_adm/unix/SALOMEconfig.h.in > I took a look inside the directories and it's right that ln can't link > directories. > > Strange error. No, it's not such a strange error. As a matter of fact, it is the kind of issue we had to fix all over the different modules of salome. Just take a look at salome-gui-3.2.6.patch and see for yourself. It might turn out that your case has triggered one of these links that are supposed to be replaced by copies. Daniel
Created attachment 145887 [details] salome-gui: Minor cleanup Minor cleanup in the spirit of what has been done with salome-kernel
(In reply to comment #294) > Created an attachment (id=145883) [edit] > salome-kernel-3.2.6-Batch_Couple.patch: Allow salome-kernel to be built with > gcc-4.2.0 > > This is the patch proposed by Pierre. > Salome-kernel compiles fine with it on x86 gcc-3.4.6 and Pierre needed it to > get salome-kernel built on x86 gcc-4.2.0 > > Jon, Francois, Dewald, does it work on your systems? > > Daniel > On my machine the salome-kernel compile fails: emerge -vp salome-kernel yields: sci-misc/salome-kernel-3.2.6 USE="X corba opengl -debug -doc -mpi -openpbs" my emerge --info yields:Portage 2.1.4.4 (default-linux/amd64/2007.0, gcc-4.2.3, glibc-2.7-r1, 2.6.24-gentoo-r2 x86_64) ================================================================= System uname: 2.6.24-gentoo-r2 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ Timestamp of tree: Wed, 12 Mar 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.4.3-r4, 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.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="-O2 -march=athlon64 -fomit-frame-pointer -pipe -mmmx -msse -msse2 -msse3 -m3dnow" 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/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/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -march=athlon64 -fomit-frame-pointer -pipe -mmmx -msse -msse2 -msse3 -m3dnow" DISTDIR="/usr/portage/distfiles" FEATURES="ccache distlocks metadata-transfer sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="ftp://ftp.is.co.za/linux/distributions/gentoo http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LINGUAS="en_GB en af en_ZA" MAKEOPTS="-j5" 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/sunrise /usr/portage/local/layman/science /usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow 3dnowext 7zip X a52 aac aalib acl alsa amd64 apm audiofile avi bash-completion berkdb bluetooth bzip2 cdparanoia cdr clamav cli clisp cracklib crypt cups curl cxx dbus dga divx4linux dri dts dv dvd dvdr dvdread encode f90 ffmpeg flac fortran ftp g77 gcj gdbm gif gimpprint glitz gnome gpm gtk gtk2 iconv ieee1394 imagemagick isdnlog java jpeg kde kdeenablefinal lapack local lzo mad madwifi midi mmx mmxext mng mozilla mp3 mpeg mplayer mudflap mysql mythtv ncurses nls nocd nptl nptlonly nsplugin ogg oggvorbis opengl openmp optimize oss pam pcre pda pdf perl png pppd python qt qt3support qt4 quicktime readline reflection ruby sdl session sms spell spl sse sse2 ssl svg symlink tcl tcltk tcpd tetex threads tiff tk truetype unicode usb v4l v4l2 vcd vorbis wmf xine xinemara xinerama xorg xrandr xv xvid zlib" ALSA_CARDS="snd-usb-audio" 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="kbd mouse joystick keyboard" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en_GB en af en_ZA" USERLAND="GNU" VIDEO_CARDS="apm v4l vga nvidia vesa vmware nv" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS The relevant emerge error part: n -fpermissive -O -Wno-deprecated -Wparentheses -Wreturn-type -Wunused -pthread -MT libSalomeGenericObj_la-SALOME_GenericObj_i.lo -MD -MP -MF .deps/libSalomeGenericObj_la-SALOME_GenericObj_i.Tpo -c SALOME_GenericObj_i.cc -fPIC -DPIC -o .libs/libSalomeGenericObj_la-SALOME_GenericObj_i.o SALOME_GenericObj_i.cc: In constructor 'SALOME::GenericObj_i::GenericObj_i(PortableServer::POA*)': SALOME_GenericObj_i.cc:45: error: '_default_POA' is not a member of 'PortableServer::RefCountServantBase' make[2]: *** [libSalomeGenericObj_la-SALOME_GenericObj_i.lo] Error 1 make[2]: Leaving directory `/var/tmp/portage/sci-misc/salome-kernel-3.2.6/work/src3.2.6/KERNEL_SRC_3.2.6/src/GenericObj' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/sci-misc/salome-kernel-3.2.6/work/src3.2.6/KERNEL_SRC_3.2.6/src' make: *** [all-recursive] Error 1
(In reply to comment #296) > Salut Pierre, > > I could not reproduce this, neither with: > > sci-misc/salome-gui-3.2.6 USE="corba doc glviewer occviewer opengl openpbs > plot2dviewer pyconsole salomeobject supervgraphviewer vtkviewer -debug -mpi" > > nor with > USE="-openpbs -salomeobject -vtkviewer -occviewer -supervgraphviewer > -plot2dviewer" emerge salome-gui > I put some debug info. The problem is line 16079 file src3.2.6/GUI_SRC_3.2.6/configure: ln -fs ${KERNEL_ROOT_DIR}/salome_adm ${ROOT_SRCDIR}/. the values are: ${KERNEL_ROOT_DIR}/salome_adm = /opt/salome-3.2.6/KERNEL/salome_adm ${ROOT_SRCDIR}/. = /var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/. so even if I do a simple hack by inserting this line before the ln rm -r -f /var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/salome_adm I get sandbox access violation since opt/salome-3.2.6/KERNEL/salome_adm is outside the work directory. I didn't find where the var KERNEL_ROOT_DIR is set. -- pierre
(In reply to comment #299) > (In reply to comment #296) > > Salut Pierre, > > > > I could not reproduce this, neither with: > > > > sci-misc/salome-gui-3.2.6 USE="corba doc glviewer occviewer opengl openpbs > > plot2dviewer pyconsole salomeobject supervgraphviewer vtkviewer -debug -mpi" > > > > nor with > > USE="-openpbs -salomeobject -vtkviewer -occviewer -supervgraphviewer > > -plot2dviewer" emerge salome-gui > > > > I put some debug info. > The problem is line 16079 file src3.2.6/GUI_SRC_3.2.6/configure: > ln -fs ${KERNEL_ROOT_DIR}/salome_adm ${ROOT_SRCDIR}/. > > the values are: > ${KERNEL_ROOT_DIR}/salome_adm = /opt/salome-3.2.6/KERNEL/salome_adm > ${ROOT_SRCDIR}/. = > /var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/. > > so even if I do a simple hack by inserting this line before the ln > rm -r -f > /var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/salome_adm > > I get sandbox access violation since opt/salome-3.2.6/KERNEL/salome_adm is > outside the work directory. > > I didn't find where the var KERNEL_ROOT_DIR is set. > Can I have the config.log from someone where salome-gui com(In reply to comment #299) > (In reply to comment #296) > > Salut Pierre, > > > > I could not reproduce this, neither with: > > > > sci-misc/salome-gui-3.2.6 USE="corba doc glviewer occviewer opengl openpbs > > plot2dviewer pyconsole salomeobject supervgraphviewer vtkviewer -debug -mpi" > > > > nor with > > USE="-openpbs -salomeobject -vtkviewer -occviewer -supervgraphviewer > > -plot2dviewer" emerge salome-gui > > > > I put some debug info. > The problem is line 16079 file src3.2.6/GUI_SRC_3.2.6/configure: > ln -fs ${KERNEL_ROOT_DIR}/salome_adm ${ROOT_SRCDIR}/. > > the values are: > ${KERNEL_ROOT_DIR}/salome_adm = /opt/salome-3.2.6/KERNEL/salome_adm > ${ROOT_SRCDIR}/. = > /var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/. > > so even if I do a simple hack by inserting this line before the ln > rm -r -f > /var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/salome_adm > > I get sandbox access violation since opt/salome-3.2.6/KERNEL/salome_adm is > outside the work directory. > > I didn't find where the var KERNEL_ROOT_DIR is set. > Can someone post the config.log after a successful ./configure for samlome-gui ? More precisely, I'm looking for the value of KERNEL_ROOT_DIR /var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/config.log
Hello, > I didn't find where the var KERNEL_ROOT_DIR is set. It depends on where you are... ;) It is defined first in the ebuild in itself: MODULE_NAME="KERNEL" MY_S="${WORKDIR}/src${PV}/${MODULE_NAME}_SRC_${PV}" INSTALL_DIR="/opt/salome-${PV}/${MODULE_NAME}" KERNEL_ROOT_DIR="/opt/salome-${PV}/${MODULE_NAME}" export OPENPBS="/usr" And when the package has been built, it is stored in /etc/env.d/90salome-kernel-3.2.6: KERNEL_ROOT_DIR=/opt/salome-3.2.6/KERNEL LDPATH=/opt/salome-3.2.6/KERNEL/lib/salome PATH=/opt/salome-3.2.6/KERNEL/bin/salome PYTHONPATH=/opt/salome-3.2.6/KERNEL/lib/python2.4/site-packages/salome Daniel
Pierre, > > I could not reproduce this, neither with: > > > > sci-misc/salome-gui-3.2.6 USE="corba doc glviewer occviewer opengl openpbs > > plot2dviewer pyconsole salomeobject supervgraphviewer vtkviewer -debug -mpi" > > > > nor with > > USE="-openpbs -salomeobject -vtkviewer -occviewer -supervgraphviewer > > -plot2dviewer" emerge salome-gui > > > > I put some debug info. > The problem is line 16079 file src3.2.6/GUI_SRC_3.2.6/configure: > ln -fs ${KERNEL_ROOT_DIR}/salome_adm ${ROOT_SRCDIR}/. > > the values are: > ${KERNEL_ROOT_DIR}/salome_adm = /opt/salome-3.2.6/KERNEL/salome_adm > ${ROOT_SRCDIR}/. = > /var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/. > > so even if I do a simple hack by inserting this line before the ln > rm -r -f > /var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/salome_adm > > I get sandbox access violation since opt/salome-3.2.6/KERNEL/salome_adm is > outside the work directory. Don't remove _anything_ there... The other modules will need it. The interesting question is why do you have this problem when we do not... salome-gui-3.2.6.patch is supposed to take care of that (the part dealing with build_configure) Are you sure the patch is applied? Daniel
(In reply to comment #298) Dewald, Which Python is triggered? > dev-lang/python: 2.4.3-r4, 2.5.1-r5 Jon made a patch. It does not work for us but it works for him. We suspect it has something to do with Python 2.4 vs. 2.5. If you uncomment the patch in the ebuild, what happens? Daniel
(In reply to comment #299) Hello again, Now a 2 cents comment. Did you check that KERNEL_ROOT_DIR was really available in your terminal after salome-kernel was built? If you type env | grep KERNEL, do you see it? env-update and source /etc/profile in the case it is not. Daniel
(In reply to comment #304) > (In reply to comment #299) > > Hello again, > > Now a 2 cents comment. > Did you check that KERNEL_ROOT_DIR was really available in your terminal after > salome-kernel was built? > > If you type env | grep KERNEL, do you see it? > env-update and source /etc/profile in the case it is not. > > Daniel > (In reply to comment #304) > (In reply to comment #299) > > Hello again, > > Now a 2 cents comment. > Did you check that KERNEL_ROOT_DIR was really available in your terminal after > salome-kernel was built? > > If you type env | grep KERNEL, do you see it? > env-update and source /etc/profile in the case it is not. > > Daniel > It would be helpful if you can post the result of the last command of this command-line script ## are my outputs # go inside ebuild dir cd /usr/local/portage/sci-misc/salome-gui # check that env vars are correct env | grep KERNEL ##KERNEL_ROOT_DIR=/opt/salome-3.2.6/KERNEL ##PYTHONPATH=/usr/lib/portage/pym:/opt/salome-3.2.6/KERNEL/lib/python2.4/site-packages/salome # clean portage tmp dir ebuild salome-gui-3.2.6.ebuild clean # unpack ebuild salome-gui-3.2.6.ebuild unpack ##[...] ## * Applying salome-gui-3.2.6.patch ... [ ok ] ## * Applying salome-gui-3.2.6_sip-4.1.7.patch ... [ ok ] ## * Applying salome-gui-3.2.6_qwt-4.patch ... [ ok ] ## * vtk version 5 detected ## * Applying salome-gui-vtk-5.0.patch ... [ ok ] ##Creating new file 'configure.in' ... done ##Creating 'configure' script ... /usr/share/aclocal/nspr.m4:8: warning: underquoted definition of AM_PATH_NSPR ##/usr/share/aclocal/nspr.m4:8: run info '(automake)Extending aclocal' ##/usr/share/aclocal/nspr.m4:8: or see http://sources.redhat.com/automake/automake.html#Extending-aclocal ##done ##>>> Source unpacked. # go to the portage tmp dir cd /var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/ # check that we have the same line head -n 16079 configure | tail -n 1 ##ln -fs ${KERNEL_ROOT_DIR}/salome_adm ${ROOT_SRCDIR}/. # add an echo before the ln command sed -i '/ln -fs ${KERNEL_ROOT_DIR}\/salome_adm ${ROOT_SRCDIR}\/./i\ echo "${KERNEL_ROOT_DIR}\/salome_adm ${ROOT_SRCDIR}\/."' configure # add an exit 1 to stop the emerge sed -i '/ln -fs ${KERNEL_ROOT_DIR}\/salome_adm ${ROOT_SRCDIR}\/./a\ exit 1' configure # check modification head -n 16081 configure | tail -n 3 ## echo "${KERNEL_ROOT_DIR}/salome_adm ${ROOT_SRCDIR}/." ##ln -fs ${KERNEL_ROOT_DIR}/salome_adm ${ROOT_SRCDIR}/. ## exit 1 # go back the the ebuild dir cd - # try compiling ebuild salome-gui-3.2.6.ebuild compile # go back getting the result cd /var/tmp/portage/sci-misc/salome-gui-3.2.6/temp/ # wanted info tail -n 20 build.log thanks
(In reply to comment #305) > tail -n 20 build.log tail -n 25 build.log
(In reply to comment #305) > It would be helpful if you can post the result of the last command of this > command-line script > > ## are my outputs > > # go inside ebuild dir > cd /usr/local/portage/sci-misc/salome-gui > > # check that env vars are correct > env | grep KERNEL > ##KERNEL_ROOT_DIR=/opt/salome-3.2.6/KERNEL > ##PYTHONPATH=/usr/lib/portage/pym:/opt/salome-3.2.6/KERNEL/lib/python2.4/site-packages/salome # env | grep KERNEL KERNEL_ROOT_DIR=/opt/salome-3.2.6/KERNEL PYTHONPATH=/usr/lib/portage/pym:/opt/salome-3.2.6/COMPONENT/lib/python2.4/site-packages/salome:/opt/salome-3.2.6/GEOM/lib/python2.4/site-packages/salome:/opt/salome-3.2.6/GUI/lib/python2.4/site-packages/salome:/opt/salome-3.2.6/KERNEL/lib/python2.4/site-packages/salome:/opt/salome-3.2.6/MED/lib/python2.4/site-packages/salome:/opt/salome-3.2.6/PYCALCULATOR/lib/python2.4/site-packages/salome:/opt/salome-3.2.6/SMESH/lib/python2.4/site-packages/salome:/opt/salome-3.2.6/SUPERV/lib/python2.4/site-packages/salome:/opt/salome-3.2.6/VISU/lib/python2.4/site-packages/salome ROOTPATH=/usr/kde/3.5/sbin:/usr/kde/3.5/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/athena/bin:/usr/i686-pc-linux-gnu/gcc-bin/3.4.6:/opt/blackdown-jdk-1.4.2.03/bin:/opt/blackdown-jdk-1.4.2.03/jre/bin:/usr/qt/3/bin:/opt/opencascade-6.2/ros/Linux/bin/:/usr/i686-pc-linux-gnu/gnat-gcc-bin/4.1:/usr/libexec/gnat-gcc/i686-pc-linux-gnu/4.1:/opt/firebird/bin:/usr/games/bin:/usr/share/omniORB/bin/scripts:/opt/salome-3.2.6/COMPONENT/bin/salome:/opt/salome-3.2.6/GEOM/bin/salome:/opt/salome-3.2.6/GUI/bin/salome:/opt/salome-3.2.6/KERNEL/bin/salome:/opt/salome-3.2.6/MED/bin/salome:/opt/salome-3.2.6/PYCALCULATOR/bin/salome:/opt/salome-3.2.6/SMESH/bin/salome:/opt/salome-3.2.6/SUPERV/bin/salome:/opt/salome-3.2.6/VISU/bin/salome > # clean portage tmp dir > ebuild salome-gui-3.2.6.ebuild clean > > # unpack > ebuild salome-gui-3.2.6.ebuild unpack > ##[...] > ## * Applying salome-gui-3.2.6.patch ... [ > ok ] > ## * Applying salome-gui-3.2.6_sip-4.1.7.patch ... [ > ok ] > ## * Applying salome-gui-3.2.6_qwt-4.patch ... [ > ok ] > ## * vtk version 5 detected > ## * Applying salome-gui-vtk-5.0.patch ... [ > ok ] > ##Creating new file 'configure.in' ... done > ##Creating 'configure' script ... /usr/share/aclocal/nspr.m4:8: warning: > underquoted definition of AM_PATH_NSPR > ##/usr/share/aclocal/nspr.m4:8: run info '(automake)Extending aclocal' > ##/usr/share/aclocal/nspr.m4:8: or see > http://sources.redhat.com/automake/automake.html#Extending-aclocal > ##done > ##>>> Source unpacked. > > # go to the portage tmp dir > cd /var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/ > > # check that we have the same line > head -n 16079 configure | tail -n 1 > ##ln -fs ${KERNEL_ROOT_DIR}/salome_adm ${ROOT_SRCDIR}/. # head -n 16079 configure | tail -n 1 cp -prf ${KERNEL_ROOT_DIR}/salome_adm ${ROOT_SRCDIR}/. Here we have something different... Are you sure you are using the right patch? That's what I mentionned in my previous message, the patch takes care of that. # ls -ltra total 28 -rw-r--r-- 1 root root 244 2008-01-02 10:05 digest-salome-gui-3.2.6 -rw-r--r-- 1 root root 8618 2008-01-03 10:39 salome-gui-vtk-5.0.patch -rw-r--r-- 1 root root 3012 2008-01-03 12:53 salome-gui-3.2.6.patch -rw-r--r-- 1 root root 785 2008-01-04 10:20 salome-gui-3.2.6_sip-4.1.7.patch drwxr-xr-x 2 root root 264 2008-02-20 10:46 . -rw-r--r-- 1 root root 1853 2008-02-20 14:05 salome-gui-3.2.6_qwt-4.patch drwxr-xr-x 3 root root 136 2008-03-12 12:46 .. Daniel
(In reply to comment #303) > (In reply to comment #298) > > Dewald, > > Which Python is triggered? > > > dev-lang/python: 2.4.3-r4, 2.5.1-r5 > > Jon made a patch. It does not work for us but it works for him. We suspect it > has something to do with Python 2.4 vs. 2.5. If you uncomment the patch in the > ebuild, what happens? > > Daniel > Daniel I get the same error with both versions of python, I manually changed the symlinks from 2.5 to 2.4, same emerge error. Dewald
> > (In reply to comment #298) > > > > Dewald, > > > > Which Python is triggered? > > > > > dev-lang/python: 2.4.3-r4, 2.5.1-r5 > > > > Jon made a patch. It does not work for us but it works for him. We suspect it > > has something to do with Python 2.4 vs. 2.5. If you uncomment the patch in the > > ebuild, what happens? > > > > Daniel Daniel I uncommented the patch, but with the same result though. Dewald
Hello Dewald Please, can you tell us which version of omniorb are you using ? It seems there is some problem with version 4.1.* source : http://www.mail-archive.com/debian-science@lists.debian.org/msg01763.html I checked it and I have the 4.0.5 and it works. (In reply to comment #309) > > > (In reply to comment #298) > > > > > > Dewald, > > > > > > Which Python is triggered? > > > > > > > dev-lang/python: 2.4.3-r4, 2.5.1-r5 > > > > > > Jon made a patch. It does not work for us but it works for him. We suspect it > > > has something to do with Python 2.4 vs. 2.5. If you uncomment the patch in the > > > ebuild, what happens? > > > > > > Daniel > > Daniel > > I uncommented the patch, but with the same result though. > > Dewald >
> > > Which Python is triggered? > > > > > > > dev-lang/python: 2.4.3-r4, 2.5.1-r5 > > > > > > Jon made a patch. It does not work for us but it works for him. We suspect it > > > has something to do with Python 2.4 vs. 2.5. If you uncomment the patch in the > > > ebuild, what happens? > > > > > > Daniel > > Daniel > > I uncommented the patch, but with the same result though. > > Dewald > Daniel Python 2.5 is definitely an issue. Changing the symlinks to 2.4 does activate the 2.4 python, I suggest we add an einfo notice to change the symlinks if the build fails or perhaps if python 2.5 is detected. Omniorb newer than 4.0.5 definitely breaks, I think omniorbpy needs a downgrade to 2.5 as well, sort of necessary if you mask omniorb newer than 4.0.5. I now have a salome-kernel compile that went through! I suggest we mask the problematic omniorb* versions, see my attachment. Dewald
Created attachment 146138 [details, diff] Omniorg* version patch Downgrade omniorg* to usable versions.
Created attachment 146414 [details] Force user to compile vtk with python USE flag The build of salome-gui fails if vtk is not compiled with the python support. I've just added a few lines to check it. I've also noticed some issues with MPI support compiling salome-component although i've removed the mpi USE flag. When you try to disable MPI support (USE="-mpi"), the configure script is executed with '--without-mpich' and it does not disable mpi support. It has to be replaced by '--without-mpi', and I think the same problem occurs for all salome ebuilds. I think that mpi dependency should be virtual/mpi instead of sys-cluster/mpich2.
(In reply to comment #313) > Created an attachment (id=146414) [edit] > Force user to compile vtk with python USE flag > > The build of salome-gui fails if vtk is not compiled with the python support. > I've just added a few lines to check it. > I tried compiling salome-gui with the latest ebuild after recompiling vtk with python support, I still get the same error as ticapix, I only used the opengl and corba use flags: generating Makefiles and configure files --------------------------------------------- ln: `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/./salome_adm': cannot overwrite directory configure: creating ./config.status config.status: error: cannot find input file: ./salome_adm/unix/SALOMEconfig.h.in !!! Please attach the following file when seeking support: !!! /var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/config.log Dewald
Hi! > I tried compiling salome-gui with the latest ebuild after recompiling vtk with > python support, I still get the same error as ticapix, I only used the opengl > and corba use flags: Pierre had downloaded an old patch. Check that you are using the latest one. Daniel
(In reply to comment #307) Dewald, Here is the signature of the patches you should use: > Are you sure you are using the right patch? That's what I mentionned in my > previous message, the patch takes care of that. > > # ls -ltra > total 28 > -rw-r--r-- 1 root root 244 2008-01-02 10:05 digest-salome-gui-3.2.6 > -rw-r--r-- 1 root root 8618 2008-01-03 10:39 salome-gui-vtk-5.0.patch > -rw-r--r-- 1 root root 3012 2008-01-03 12:53 salome-gui-3.2.6.patch > -rw-r--r-- 1 root root 785 2008-01-04 10:20 salome-gui-3.2.6_sip-4.1.7.patch > drwxr-xr-x 2 root root 264 2008-02-20 10:46 . > -rw-r--r-- 1 root root 1853 2008-02-20 14:05 salome-gui-3.2.6_qwt-4.patch > drwxr-xr-x 3 root root 136 2008-03-12 12:46 .. Daniel
(In reply to comment #316) I sorted the old patch issues out and got salome-gui compiling past the previously mentioned issue. Then I ran into a qwt not found issue, I now have both qwt 4 and 5 installed. Atm from the config.log qwt 4 gets pulled in but the emerge fails with: ALOME_PYQT_Module.cxx:1226: warning: deprecated conversion from string constant to 'char*' SALOME_PYQT_Module.cxx: In member function 'void SALOME_PYQT_Module::prefChanged(const QString&, const QString&)': SALOME_PYQT_Module.cxx:1245: warning: deprecated conversion from string constant to 'char*' SALOME_PYQT_Module.cxx:1250: warning: deprecated conversion from string constant to 'char*' SALOME_PYQT_Module.cxx:1250: warning: deprecated conversion from string constant to 'char*' make[4]: *** [SALOME_PYQT_Module.lo] Error 1 make[4]: Leaving directory `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/src/SALOME_PYQT/SALOME_PYQT_GUI' make[3]: *** [lib_SALOME_PYQT_GUI] Error 2 make[3]: Leaving directory `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/src/SALOME_PYQT' make[2]: *** [lib_SALOME_PYQT] Error 2 make[2]: Leaving directory `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/src' make[1]: *** [lib_src] Error 2 make[1]: Leaving directory `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6' make: *** [all] Error 2 * * ERROR: sci-misc/salome-gui-3.2.6 failed. Suspecting a pqqt or pyqt4 issue, I have the latest versions installed. Dewald
Hello, > Then I ran into a qwt not found issue, I now have both qwt 4 and 5 installed. That's normal. qwt4 is the one needed. It does not work with qwt5. I don't know if you read it but a few weeks ago, we had to find a way to automatically deal with this issue, that is to say: to trigger qwt4 and to use it instead of qwt5. This being said, I suppose you are using the latest ebuild, patches. > Atm from the config.log qwt 4 gets pulled in but the emerge fails with: > ALOME_PYQT_Module.cxx:1226: warning: deprecated conversion from string constant > to 'char*' > SALOME_PYQT_Module.cxx: In member function 'void > SALOME_PYQT_Module::prefChanged(const QString&, const QString&)': > SALOME_PYQT_Module.cxx:1245: warning: deprecated conversion from string > constant to 'char*' > SALOME_PYQT_Module.cxx:1250: warning: deprecated conversion from string > constant to 'char*' > SALOME_PYQT_Module.cxx:1250: warning: deprecated conversion from string > constant to 'char*' > make[4]: *** [SALOME_PYQT_Module.lo] Error 1 > make[4]: Leaving directory > `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/src/SALOME_PYQT/SALOME_PYQT_GUI' > make[3]: *** [lib_SALOME_PYQT_GUI] Error 2 > make[3]: Leaving directory > `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/src/SALOME_PYQT' > make[2]: *** [lib_SALOME_PYQT] Error 2 > make[2]: Leaving directory > `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/src' > make[1]: *** [lib_src] Error 2 > make[1]: Leaving directory > `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6' > make: *** [all] Error 2 > * > * ERROR: sci-misc/salome-gui-3.2.6 failed. I have never had such an error message. On my system I have: dev-lang/python-2.3.6-r4 dev-lang/python-2.4.4-r9 dev-python/PyQt-3.17.4 dev-python/PyQt4-4.3.3 dev-python/sip-4.7.3 dev-lang/swig-1.3.31 > Suspecting a pqqt or pyqt4 issue, I have the latest versions installed. What does the GUI configuration says about qwt? (You know, when it lists what is available on your system, at the beginning) Daniel
(In reply to comment #318) > > > Suspecting a pqqt or pyqt4 issue, I have the latest versions installed. > > What does the GUI configuration says about qwt? (You know, when it lists what > is available on your system, at the beginning) > > Daniel > I fixed my problem salome-gui, got tid of python 2.5 on my system and recompiled the depencies with python 2.4, salome-gui built 100% With salome-med I end up with the following error: MED_V2_2_Wrapper.cxx: In member function 'virtual void MED::V2_2::TVWrapper::GetNodeInfo(MED::TNodeInfo&, MED::TErr*)': MED_V2_2_Wrapper.cxx:647: error: cannot convert 'long int*' to 'med_int*' in initialization MED_V2_2_Wrapper.cxx: In member function 'void MED::V2_2::TVWrapper::SetNodeInfo(const MED::TNodeInfo&, MED::V2_2::EModeAcces, MED::TErr*)': MED_V2_2_Wrapper.cxx:685: error: cannot convert 'long int*' to 'med_int*' in initialization MED_V2_2_Wrapper.cxx: In member function 'virtual void MED::V2_2::TVWrapper::GetCellInfo(MED::TCellInfo&, MED::TErr*)': MED_V2_2_Wrapper.cxx:1155: error: cannot convert 'long int*' to 'med_int*' in initialization MED_V2_2_Wrapper.cxx: In member function 'void MED::V2_2::TVWrapper::SetCellInfo(const MED::TCellInfo&, MED::V2_2::EModeAcces, MED::TErr*)': MED_V2_2_Wrapper.cxx:1194: error: cannot convert 'long int*' to 'med_int*' in initialization MED_V2_2_Wrapper.cxx: In member function 'virtual boost::tuples::tuple<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, long int, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> MED::V2_2::TVWrapper::GetProfilePreInfo(MED::TInt, MED::TErr*)': MED_V2_2_Wrapper.cxx:1429: error: cannot convert 'MED::TInt*' to 'med_int*' for argument '4' to 'med_err MEDprofilInfo(med_idt, int, char*, med_int*)' MED_V2_2_Wrapper.cxx: In member function 'virtual void MED::V2_2::TVWrapper::GetProfileInfo(MED::TInt, MED::TProfileInfo&, MED::TErr*)': MED_V2_2_Wrapper.cxx:1453: error: cannot convert 'long int*' to 'med_int*' for argument '2' to 'med_err MEDprofilLire(med_idt, med_int*, char*)' MED_V2_2_Wrapper.cxx: In member function 'void MED::V2_2::TVWrapper::SetGrilleInfo(const MED::TGrilleInfo&, MED::V2_2::EModeAcces, MED::TErr*)': MED_V2_2_Wrapper.cxx:2009: error: cannot convert 'long int*' to 'med_int*' for argument '4' to 'med_err MEDstructureCoordEcr(med_idt, char*, med_int, med_int*)' MED_V2_2_Wrapper.cxx: At global scope: MED_V2_2_Wrapper.cxx:45: warning: 'MYDEBUG' defined but not used make[4]: *** [MED_V2_2_Wrapper.lo] Error 1 make[4]: Leaving directory `/var/tmp/portage/sci-misc/salome-med-3.2.6/work/src3.2.6/MED_SRC_3.2.6/src/MEDWrapper/V2_2 Dewald
Daniel, I worked on the light component. If it is possible to use a light gui without corba, I don't know how to do. The light component is just an example about how create a salome component without corba. It is not a gui without corba. For a gui without corba, I think we have to compile the gui compoenent without the corba flag. So, we must find how to compile it without it. Best regards. François
Created attachment 147142 [details, diff] patch to be able to compile gui component without corba flag
Created attachment 147146 [details] new salome-gui ebuild : take into account the configure.in.base patch
I can compile the gui component without corba. But if anyone has an idea about how launch salome... The script "runSalome" doesn't work...
Created attachment 148604 [details] salome-meta: Added a reference to this forum
Created attachment 148606 [details] salome-component: A few changes
Created attachment 148607 [details] salome-geom: A few changes
Created attachment 148609 [details] salome-gui: A few changes
Created attachment 148611 [details] salome-kernel: A few changes
Created attachment 148613 [details] salome-med: A few changes
Created attachment 148615 [details] salome-pycalculator: A few changes
Created attachment 148617 [details] salome-smesh: A few changes
Created attachment 148618 [details] salome-superv: A few changes
Created attachment 148619 [details] salome-visu: A few changes
Hello, I have reworked all the ebuilds we have made so far. What's new? - I cleaned up a bit the ebuilds. - I removed the old boost warning (not relevant anymore) - I changed a bit the dependency list to take care of the fact that: - Python 2.4 is the one to use (I don't know how to reinforce that though) - The choice of omniORB and omniorbpy is sensible. Therefore a few versions are allowed. - I added the VTK warning in every ebuild (VTK must be build with Python support). - I checked the dependency on diverse MPI implementation on all ebuilds. It varies from one to the other (some modules seem to have support for MPI and LAM, others don't...). MPICH seems to be the common factor. That's the one I chose. I agree with Etienne though. This is not really clean... - I use doenvd everywhere now, instead of the old complicated stuff... A few comments for reflection: - I have not tried yet to build kernel and gui without the Corba flag. What should be reflected over is that apparently, the other ebuilds use Corba as well, except that it does not seem to be optional. I find this strange. Francois, what do you think? BTW, do you succeed to start Salome without Corba? - I could not reproduce Dewald problem with salome-med. Is it still of actuality? Daniel
> - I could not reproduce Dewald problem with salome-med. Is it still of > actuality? > > Daniel Daniel yes it is unfortunately, I updated all my ebuilds, and re-emerged kernel gui and geom, I still have the same problem with med, superv built as well but the rest all need med although the ebuilds don't reflect that individually. I see that the debian science guys are also struggling with this monster: http://www.mail-archive.com/debian-science@lists.debian.org/msg01770.html There is some vague reference there to some med things, I have emailed Adam regarding this. I haven't tried the -corba route, I am willing if you guys think it is needed. Dewald Dewald
(In reply to comment #335) > Daniel yes it is unfortunately, I updated all my ebuilds, and re-emerged kernel > gui and geom, I still have the same problem with med, superv built as well but > the rest all need med although the ebuilds don't reflect that individually. Is it so? This needs to be added then to the list of dependency then (maybe I put it in the kernel dependency list, I don't remember). > I see that the debian science guys are also struggling with this monster: > http://www.mail-archive.com/debian-science@lists.debian.org/msg01770.html > There is some vague reference there to some med things, I have emailed Adam > regarding this. I haven't tried the -corba route, I am willing if you guys > think it is needed. I suppose you use the right patches and this ebuild: http://bugs.gentoo.org/show_bug.cgi?id=130502 Strange that you are having troubles. I do not have any here (x86) Daniel
Hello Daniel, > - I have not tried yet to build kernel and gui without the Corba flag. What > should be reflected over is that apparently, the other ebuilds use Corba as > well, except that it does not seem to be optional. I find this strange. > Francois, what do you think? I think salome was concepted to be used with corba. This explain why most of the components are using it. A version without corba is provided but I guess it is for "expert" only, who create their own component and just needs salome as a kernel. For normal user, I believe it is the standard salome with corba. > BTW, do you succeed to start Salome without Corba? No, I don't Best regards François
Daniel (In reply to comment #336) > Is it so? > This needs to be added then to the list of dependency then (maybe I put it in > the kernel dependency list, I don't remember). Here some confusion seems so have slipped in, if I emerge salome-pycalculator, then it fails needing some med things, the ebuild does not make salome-med a dependency: PYCALCULATOR_Gen.idl:31: MED.idl: No such file or directory SALOME_Component.idl:53: Warning: Identifier 'Component' clashes with CORBA 3 keyword 'component' SALOME_Component.idl:178: Warning: Identifier 'Component' clashes with CORBA 3 keyword 'component' PYCALCULATOR_Gen.idl:39: Error in look-up of 'SALOME_MED::FIELDDOUBLE': 'SALOME_MED' not found PYCALCULATOR_Gen.idl:39: Error in look-up of 'SALOME_MED::FIELDDOUBLE': 'SALOME_MED' not found PYCALCULATOR_Gen.idl:39: Error in look-up of 'SALOME_MED::FIELDDOUBLE': 'SALOME_MED' not found PYCALCULATOR_Gen.idl:40: Error in look-up of 'SALOME_MED::FIELDDOUBLE': 'SALOME_MED' not found PYCALCULATOR_Gen.idl:40: Error in look-up of 'SALOME_MED::FIELDDOUBLE': 'SALOME_MED' not found PYCALCULATOR_Gen.idl:41: Error in look-up of 'SALOME_MED::FIELDDOUBLE': 'SALOME_MED' not found PYCALCULATOR_Gen.idl:41: Error in look-up of 'SALOME_MED::FIELDDOUBLE': 'SALOME_MED' not found PYCALCULATOR_Gen.idl:42: Error in look-up of 'SALOME_MED::FIELDDOUBLE': 'SALOME_MED' not found omniidl: 8 errors and 2 warnings. omniidl: Error running preprocessor make[2]: *** [../lib/python2.4/site-packages/salome/PYCALCULATOR_Gen_idl.py] Error 1 make[2]: Leaving directory `/var/tmp/portage/sci-misc/salome-pycalculator-3.2.6/work/src3.2.6/PYCALCULATOR_SRC_3.2.6/idl' make[1]: *** [lib_idl] Error 2 make[1]: Leaving directory `/var/tmp/portage/sci-misc/salome-pycalculator-3.2.6/work/src3.2.6/PYCALCULATOR_SRC_3.2.6' make: *** [all] Error 2 Now I have med installed with the patches etc: sci-libs/med [2] Available versions: ~2.3.1 Installed versions: 2.3.1(20:19:23 04/10/08) Homepage: http://www.code-aster.org/outils/med/ Description: Modeling and Exchange of Data library My salome-med still fails with: MED_V2_2_Wrapper.cxx: In member function 'virtual void MED::V2_2::TVWrapper::GetNodeInfo(MED::TNodeInfo&, MED::TErr*)': MED_V2_2_Wrapper.cxx:647: error: cannot convert 'long int*' to 'med_int*' in initialization MED_V2_2_Wrapper.cxx: In member function 'void MED::V2_2::TVWrapper::SetNodeInfo(const MED::TNodeInfo&, MED::V2_2::EModeAcces, MED::TErr*)': MED_V2_2_Wrapper.cxx:685: error: cannot convert 'long int*' to 'med_int*' in initialization MED_V2_2_Wrapper.cxx: In member function 'virtual void MED::V2_2::TVWrapper::GetCellInfo(MED::TCellInfo&, MED::TErr*)': MED_V2_2_Wrapper.cxx:1155: error: cannot convert 'long int*' to 'med_int*' in initialization MED_V2_2_Wrapper.cxx: In member function 'void MED::V2_2::TVWrapper::SetCellInfo(const MED::TCellInfo&, MED::V2_2::EModeAcces, MED::TErr*)': MED_V2_2_Wrapper.cxx:1194: error: cannot convert 'long int*' to 'med_int*' in initialization MED_V2_2_Wrapper.cxx: In member function 'virtual boost::tuples::tuple<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, long int, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> MED::V2_2::TVWrapper::GetProfilePreInfo(MED::TInt, MED::TErr*)': MED_V2_2_Wrapper.cxx:1429: error: cannot convert 'MED::TInt*' to 'med_int*' for argument '4' to 'med_err MEDprofilInfo(med_idt, int, char*, med_int*)' MED_V2_2_Wrapper.cxx: In member function 'virtual void MED::V2_2::TVWrapper::GetProfileInfo(MED::TInt, MED::TProfileInfo&, MED::TErr*)': MED_V2_2_Wrapper.cxx:1453: error: cannot convert 'long int*' to 'med_int*' for argument '2' to 'med_err MEDprofilLire(med_idt, med_int*, char*)' MED_V2_2_Wrapper.cxx: In member function 'void MED::V2_2::TVWrapper::SetGrilleInfo(const MED::TGrilleInfo&, MED::V2_2::EModeAcces, MED::TErr*)': MED_V2_2_Wrapper.cxx:2009: error: cannot convert 'long int*' to 'med_int*' for argument '4' to 'med_err MEDstructureCoordEcr(med_idt, char*, med_int, med_int*)' MED_V2_2_Wrapper.cxx: At global scope: MED_V2_2_Wrapper.cxx:45: warning: 'MYDEBUG' defined but not used make[4]: *** [MED_V2_2_Wrapper.lo] Error 1 make[4]: Leaving directory `/var/tmp/portage/sci-misc/salome-med-3.2.6/work/src3.2.6/MED_SRC_3.2.6/src/MEDWrapper/V2_2' make[3]: *** [lib_V2_2] Error 2 make[3]: Leaving directory `/var/tmp/portage/sci-misc/salome-med-3.2.6/work/src3.2.6/MED_SRC_3.2.6/src/MEDWrapper' make[2]: *** [lib_MEDWrapper] Error 2 make[2]: Leaving directory `/var/tmp/portage/sci-misc/salome-med-3.2.6/work/src3.2.6/MED_SRC_3.2.6/src' make[1]: *** [lib_src] Error 2 make[1]: Leaving directory `/var/tmp/portage/sci-misc/salome-med-3.2.6/work/src3.2.6/MED_SRC_3.2.6' make: *** [all] Error 2 The cause of this still eludes me, I am wondering if this means that my system isn't seeing med? Is there anything I can do to test my med? My emerge --info: app-shells/bash: 3.2_p33 dev-java/java-config: 1.3.7, 2.1.5 dev-lang/python: 2.3.6-r4, 2.4.4-r9 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.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 Dewald
> > My emerge --info: > > app-shells/bash: 3.2_p33 > dev-java/java-config: 1.3.7, 2.1.5 > dev-lang/python: 2.3.6-r4, 2.4.4-r9 > 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.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 > > Dewald > Hello Dewald, I tried to reproduce your bug without success. I compile salome-med with gcc-4.1.2 and gcc-4.2.3 successfully. Can you compress your MED_SRC_3.2.6 folder after an error at compilation occurs and put it on a ftp, for exemple ? It allows us to watch exactly what happened... Best regards. François
Created attachment 150326 [details, diff] salome-med-3.2.6_gcc4-2.patch I had a similar problem as the above with salome-med not compiling properly under gcc4, my system is amd64 so I'm unsure if this is part of the problem I found that it was just a case of adding the right casting at the right places the attached patch should fix the problem
Hi Richard, > > I had a similar problem as the above with salome-med not compiling properly > under gcc4, my system is amd64 so I'm unsure if this is part of the problem > I found that it was just a case of adding the right casting at the right places > the attached patch should fix the problem > I suspect the problem is more complex. I check the definition of the "med_int" and found it is defined as an integer "int". So, convert an "int" to a "logn int" can be a source of problem. On a 32-bits architecture, "long int" is an alias of "int". But on 64bits architecture, when -m64 flag is used, "long int" is coded on 64 bits whereas "int" is coded on 32-bits. As the error occur when using pointer on these structure, it could be a source of bug. I use a 32-bits architecture but I will force the use of -m64 flag to see if it is the source of the problem... Dewald, Richard, can you try to compile without the -m64 flag ? You just have to comment the following line in the salome-med ebuild : "append-flag -m64"
> > Dewald, Richard, can you try to compile without the -m64 flag ? You just have > to comment the following line in the salome-med ebuild : "append-flag -m64" > To be sure to be in 32-bits and not in 64-bit, replace -m64 by -m32 instead commenting it. I'm trying to compile 64 bits programs, but gcc doesn't want to do it. It complains about a 64-bits support missing...
(In reply to comment #342) > > > > Dewald, Richard, can you try to compile without the -m64 flag ? You just have > > to comment the following line in the salome-med ebuild : "append-flag -m64" > > > To be sure to be in 32-bits and not in 64-bit, replace -m64 by -m32 instead > commenting it. I tried both suggestions, commenting the -m64 flag part doesn't help the -m64 flag still seems to get pulled in, changing it to -m32 results in lots of warnings on each and very compile line, eg "warning: Identifier 'Component' clashes with CORBA 3 keyword 'component'" I will give Richard's patch a try.
(In reply to comment #343) > I had a similar problem as the above with salome-med not compiling properly > under gcc4, my system is amd64 so I'm unsure if this is part of the problem > I found that it was just a case of adding the right casting at the right places > the attached patch should fix the problem > Thanks Richard, your patch works! Now to see what the rest of Salome does.
> Now to see what the rest of Salome does. salome-smesh fail with a fpic error: /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.3/../../../../x86_64-pc-linux-gnu/bin/ld: StdMeshers_Propagation.lo: relocation R_X86_64_PC32 against `(anonymous namespace)::PropagationMgr::GetSource(SMESH_subMesh*)' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.3/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status Adding -fpic after -m64 doesn't resolve the problem either, seems to me this little monster has as long way to go before it will be 64bit friendly. Dewald
François I understand what you mean looking at "med_int" within /usr/include/med.h this seems to depend on the size of a Fortran integer (if "long" should be used for 64bit or "int" should be used for for 32bit) this is checked / defined within config/med_check_typeof_medint.m4 in the med package at the moment on amd64 it's using "int" for "med_int" when I think it should be using "long" looking at src/MEDWrapper/Base/MED_Common.hxx there's a section of code that reads #if defined(SUN4SOL2) || defined(PCLINUX) || defined(PCLINUX64_32) || defined(OSF1_32) || defined(IRIX64_32) || defined(RS6000) || defined(HP9000) typedef int TInt; #endif #if defined(IRIX64) || defined(OSF1) || defined(PCLINUX64) typedef long TInt; #endif which is using "long" for "TInt" because amd64 = PCLINUX64 I think this is where there is a mismatch forcing "TInt" to a 32bit "int" doesn't really work and I'm more likely to believe that "med_int" should be "long" in the first place for 64bit for med-2.3.3 putting "--with-med_int=long" on the configure line seems to force "med_int" to "long" since salome-med doesn't like med-2.3.3 I had to create a small patch to add in the same feature to 2.3.1 with this feature added, salome-med now compiles without the salome-med-3.2.6_gcc4-2.patch before I start adding files to the other med bugzilla, can I just check does this sound okay? i'm not sure of a way of checking the default "int" sizes within "gfortran" but I think the auto-check code within med may be wrong which is causing the problem
it all seems to work okay, so I've added the amended ebuilds for med to the other bugzila entry for info I've managed to get all of salome to compile / work under amd64, but only with the -mpi use flag disabled salome-gui needs a lot of stuff turned on before the other salome packages will compile (they complain about a full gui otherwise) so perhaps this should be turned on by default within the package also I've recently been looking into the depends for code aster, but I'm only partly the way there I hope to get an overlay setup via layman at some point some of the depends are not setup quite right so it's important to emerge the packages in order using salome-meta this is what I'm using for the keywords / use files at the moment ***************************************** /etc/portage/package.keywords/cad-general ***************************************** # salome # only seems to work without mpi =sci-libs/med-2.3.1 #=sci-libs/med-2.3.3 =dev-tcltk/tix-8.4.2-r1 =sci-libs/opencascade-6.2-r5 =sci-libs/vtk-5.0.4 =sci-libs/hdf5-1.6.5-r1 =sci-misc/salome-component-3.2.6 =sci-misc/salome-geom-3.2.6 =sci-misc/salome-gui-3.2.6 =sci-misc/salome-kernel-3.2.6 =sci-misc/salome-med-3.2.6 =sci-misc/salome-meta-3.2.6 =sci-misc/salome-pycalculator-3.2.6 =sci-misc/salome-smesh-3.2.6 =sci-misc/salome-superv-3.2.6 =sci-misc/salome-visu-3.2.6 # Code Aster =sci-libs/scotch-4.0.1 #=sci-libs/scotch-5.0.5 #=sci-libs/metis-edf-4.0.1 TODO =x11-libs/xbae-4.60.4 =sci-visualization/grace-5.1.21-r1 =net-misc/omniORB-4.0.7 # Netgen - doesn't work under amd64 =sci-misc/netgen-4.4-r1 # Others =media-gfx/aoi-2.5 =media-gfx/blender-2.45 # brlcad =sci-misc/brlcad-7.12.0 # misc depends =media-video/ffmpeg-0.4.9_p20070616-r2 ************************************ /etc/portage/package.use/cad-general ************************************ #sci-libs/opencascade wok draw-harness sci-libs/hdf5 -cxx -fortran -mpi sci-misc/salome-component -mpi openpbs sci-misc/salome-geom -mpi openpbs sci-misc/salome-gui -mpi openpbs corba pyconsole glviewer plot2dviewer supervgraphviewer occviewer salomeobject vtkviewer sci-misc/salome-kernel -mpi openpbs corba sci-misc/salome-med -mpi openpbs sci-misc/salome-meta -mpi openpbs sci-misc/salome-pycalculator -mpi openpbs sci-misc/salome-smesh -mpi openpbs sci-misc/salome-superv -mpi openpbs sci-misc/salome-visu -mpi openpbs
Created attachment 151031 [details] salome-component-3.2.6-r1.ebuild fix of depends, a few warnings added
Created attachment 151032 [details] salome-geom-3.2.6-r1.ebuild fix of depends, a few warnings added
Created attachment 151034 [details] salome-gui-3.2.6-r1.ebuild fix of depends, a few warnings added
Created attachment 151036 [details] salome-kernel-3.2.6-r1.ebuild fix of depends, a few warnings added
Created attachment 151038 [details] salome-med-3.2.6-r1.ebuild fix of depends, a few warnings added
Created attachment 151039 [details] salome-meta-3.2.6-r1.ebuild fix of depends, a few warnings added
Created attachment 151040 [details] salome-pycalculator-3.2.6-r1.ebuild fix of depends, a few warnings added
Created attachment 151042 [details] salome-smesh-3.2.6-r1.ebuild fix of depends, a few warnings added
Created attachment 151044 [details] salome-superv-3.2.6-r1.ebuild fix of depends, a few warnings added
Created attachment 151045 [details] salome-visu-3.2.6-r1.ebuild fix of depends, a few warnings added
(In reply to comment #350) Using the latest and greatest ebuilds I still end up with one niggle when trying to build salome-gui: make[3]: Leaving directory `/var/tmp/portage/sci-misc/salome-gui-3.2.6-r1/work/src3.2.6/GUI_SRC_3.2.6/src/ResExporter' + for d in Qtx Style DDS QDS SUIT STD CAF CAM SUITApp LogWindow ObjBrowser Prs OBJECT GLViewer VTKViewer SVTK OCCViewer SOCC PyInterp PythonConsole Plot2d SPlot2d SUPERVGraph LightApp ResExporter RegistryDisplay TOOLSGUI Event Session SalomeApp SALOME_SWIG SALOME_PY SALOME_PYQT + cd RegistryDisplay + make depend make[3]: Entering directory `/var/tmp/portage/sci-misc/salome-gui-3.2.6-r1/work/src3.2.6/GUI_SRC_3.2.6/src/RegistryDisplay' make[3]: *** No rule to make target `.depend', needed by `depend'. Stop. make[3]: Leaving directory `/var/tmp/portage/sci-misc/salome-gui-3.2.6-r1/work/src3.2.6/GUI_SRC_3.2.6/src/RegistryDisplay' + exit 1 make[2]: *** [depend] Error 1 make[2]: Leaving directory `/var/tmp/portage/sci-misc/salome-gui-3.2.6-r1/work/src3.2.6/GUI_SRC_3.2.6/src' Anyone know what is the cause of this? Dewald
Richard, Thanks for your changes in the ebuild. I noticed that the dependency on mpi has been changed. Did you see what I mentionned a few messages ago? What do you think? > - I checked the dependency on diverse MPI implementation on all ebuilds. It > varies from one to the other (some modules seem to have support for MPI and > LAM, others don't...). MPICH seems to be the common factor. That's the one I > chose. I agree with Etienne though. This is not really clean... Daniel
Hi! > Created an attachment (id=151036) [edit] > salome-kernel-3.2.6-r1.ebuild > > fix of depends, a few warnings added In the final elog, no need to specify the whole path to runSalome.sh The path is automagically added by the 90salome-kernel file in /etc/env.d The only things needed are env-update && source /etc/profile Daniel
I had trouble getting mpich to compile for some reason so I changed the mpi depend to a virtual/mpi, which should include mpich, or lam-mpi (which is what I'm using at the moment) it seems to compile / work okay with no problems, but I didn't look into the mpi sections of the code specifically, so there could be problems there I'm not aware of (it seems to work) I also added some depends between the different salome packages I noticed that if hdf5 has mpi enabled when being built this interferes with the build of salome-kernel, so I added in a warning for this (perhaps this is related to the above) for salome-gui I tried to add in some use flag checks, but I think more still need to be added (the safest bet is just to enable everything for now, except for debug) for the path to runSalome.sh, perhaps this should be einfo instead of elog I just added this in as it wasn't obvious as to how to quickly get Salome up and running I might try to see if I can get it to add a menu item / shortcut link for X I've recently got netgen working on amd64, and I've been working on some ebuilds for elmer-fem which seem to work, so I'm going to try and see if I can setup an ebuild for the Salome netgen plugin > Using the latest and greatest ebuilds I still end up with one niggle when > trying to build salome-gui: I've not seen this myself But all I can suggest is unmerge all the salome packages, switch on all the use flags for the salome packages (except for debug) (especially for gui) then emerge one at a time, followed by an env-update && source /etc/profile in-between each emerge
Hi Richard, > I had trouble getting mpich to compile for some reason So the problem was mpich2 on your system. Not the selection I made regarding the implementation of MPI in Salome. Is that so? > so I changed the mpi depend to a virtual/mpi, which should include mpich, or > lam-mpi (which is what I'm using at the moment) The problem is the following. When you look at the configure options for the Salome modules, you realise that some support LAM and MPICH, others do only support MPICH. There is no constant. It just varies from one module to the other (according to ./configure). So, once I checked _every single_ module, I realised that they has one implementation in common, that was MPICH. Knowing that the virtual/mpi stuff is a moving target, I decided to avoid that and let this to the gentoo guy. However, I also decided to make reference to the one I knew was supported by all the modules: MPICH. Therefore I am a bit reluctant to have this virtual/mpi stuff. Because I am afraid that in the long run, someone will say "It does not work with the MPI on my machine".... The MPI turning to be something that the salome modules _do not_ have in common. > it seems to compile / work okay with no problems, but I didn't look into the > mpi sections of the code specifically, so there could be problems there I'm not > aware of (it seems to work) Do you use MPI or do you just have one MPI implementation installed on your box? Are you sure it works? If it really does so, then my previous argument falls down cause, I do not use MPI. I had this setup to be sure it would not be forgotten. > I also added some depends between the different salome packages Thanks for that. > I noticed that if hdf5 has mpi enabled when being built > this interferes with the build of salome-kernel, so I added in a warning for > this (perhaps this is related to the above) You mean your problems with mpich? > for salome-gui I tried to add in some use flag checks, but I think more still > need to be added > (the safest bet is just to enable everything for now, except for debug) That's what I have always been doing. I am happy that you discovered and sorted out some issues. > for the path to runSalome.sh, perhaps this should be einfo instead of elog > I just added this in as it wasn't obvious as to how to quickly get Salome up > and running You can make a reference to the name of the program but _not_ to the complete path regarding where it is installed. The env.d variables are there to take care of the path. The only thing that should me mentionned is the need to run env-update and source, to get the variables set properly in the terminal. > I might try to see if I can get it to add a menu item / shortcut link for X _That_ would be the best! :) > I've recently got netgen working on amd64, and I've been working on some > ebuilds for elmer-fem which seem to work, so I'm going to try and see if I can > setup an ebuild for the Salome netgen plugin Which netgen? 4.4? Are you aware of the ebuild I created for it? http://bugs.gentoo.org/show_bug.cgi?id=155424 The guys at gentoo asked me to clean up the ebuild I created before they would make it official. I had a minor issue with it that I could not solve. Did you try the ebuild? Did you see my report? > > Using the latest and greatest ebuilds I still end up with one niggle when > > trying to build salome-gui: > I've not seen this myself > But all I can suggest is unmerge all the salome packages, switch on all the use > flags for the salome packages (except for debug) (especially for gui) > then emerge one at a time, followed by an > env-update && source /etc/profile > in-between each emerge That's basically how I proceeded. Each module comes with its own set of environment variables, so I suppose the terminal variables need to be updated accordingly every time a module is built. This is not very neat but I don't know how to make this happen automagically. There is also an issue with the corba flag (read the thread for a complete explanation). Daniel
Richard, One more common about MPI > > I had trouble getting mpich to compile for some reason > > So the problem was mpich2 on your system. Not the selection I made regarding > the implementation of MPI in Salome. Is that so? > > > > so I changed the mpi depend to a virtual/mpi, which should include mpich, or > > lam-mpi (which is what I'm using at the moment) MPICH is also clearly specified with the econf line. This virtual stuff would require to identify which MPI is really used and to modify the econf accordingly dynamically. We would finally realise that this would lead nowhere because LAP-MPI is not always accepted as a configure option... Daniel
I'll have to assume your right on the mpi point above I was having trouble re-compiling vtk / fftw with mpich2 but adding =sys-cluster/mpich2-1.0.6 to package.keywords seems to have fixed the problem for amd64 I'll re-adjust the depends to be mpich specific also I think I'll re-check some of the flags being passed to the configure script for each of the packages For info I think I've finally managed to get the netgen plugin to work as well so I'll post an ebuild for this one at the same time, once I've finished with some cleanups
Hi Richard, > I'll have to assume your right on the mpi point above > I was having trouble re-compiling vtk / fftw with mpich2 > but adding =sys-cluster/mpich2-1.0.6 to package.keywords seems to have fixed > the problem for amd64 Happy to hear that the problem with mpich2 on your side is solved. > I'll re-adjust the depends to be mpich specific I'm interested to hear about the results of your tests with mpich2. > also I think I'll re-check some of the flags being passed to the configure > script for each of the packages Yes please. Thank you! I might indeed have missed a few things. No one is perfect... ;) > For info I think I've finally managed to get the netgen plugin to work as well > so I'll post an ebuild for this one at the same time, once I've finished with > some cleanups Great! Thanks for the good work. Daniel
Created attachment 152339 [details] /salome-kernel/files/icon/salome-kernel-icon.png icon for the menu entry
Created attachment 152341 [details] /salome-kernel/files/icon/salome-kernel.desktop desktop icon entry
Created attachment 152343 [details, diff] /salome-kernel/files/salome-kernel-3.2.6-mpich2.patch there was a bug within salome_adm/unix/config_files/check_mpich.m4 which was affecting the detection of mpich for salome-component so I've added the above patch
Created attachment 152345 [details] salome-component-3.2.6-r2.ebuild salome component: amended depends back to mpich2 amended other config flags: opengl mpich openpbs spotted a potential problem if mpich is compiled with the cxx use flag added a fix for this
Created attachment 152347 [details] salome-geom-3.2.6-r2.ebuild salome geom: amended depends back to mpich2 removed openpbs flag (it's not used in the config script) amended other config flags: opengl mpich
Created attachment 152349 [details] salome-gui-3.2.6-r2.ebuild salome-gui: amended depends back to mpich2 removed openpbs flag (it's not used in the config script) amended other config flags: opengl mpich
Created attachment 152351 [details] salome-kernel-3.2.6-r2.ebuild salome-kernel: amended depends back to mpich2 I've also amended some of the flags passed to configure, in some cases specifying --without-<package> triggers the same result as --with-<package> so to disable you have to omit the flag altogether I'm not sure where the problem is but I suspect it's within one of the .m4 scripts within salome-kernel (all the other packages seem to use these from the installed salome-kernel package under /opt) I've tried to alter the ebuilds to compensate since I couldn't locate the underlying problem added an icon / menu entry under Graphics, remember to restart X after emerging if X is running as the updated env variables need to be updated before this will work
Created attachment 152353 [details] salome-med-3.2.6-r2.ebuild salome med: amended depends back to mpich2 amended other config flags: opengl mpich openpbs
Created attachment 152355 [details] salome-pycalculator-3.2.6-r2.ebuild salome-pycalculator amended depends back to mpich2 removed openpbs / opengl flag (it's not used in the config script) amended other config flags: mpich
Created attachment 152357 [details] salome-smesh-3.2.6-r2.ebuild salome-smesh amended depends back to mpich2 removed openpbs flag (it's not used in the config script) amended other config flags: opengl mpich
Created attachment 152359 [details] salome-superv-3.2.6-r2.ebuild salome-superv amended depends back to mpich2 removed openpbs flag (it's not used in the config script) amended other config flags: opengl mpich
Created attachment 152361 [details] salome-visu-3.2.6-r2.ebuild salome-visu amended depends back to mpich2 removed openpbs flag (it's not used in the config script) amended other config flags: opengl
Created attachment 152363 [details, diff] /salome-ngplugin/files/salome-ngplugin-3.2.6.patch
Created attachment 152365 [details, diff] /salome-ngplugin/files/salome-ngplugin-3.2.6-nginclude.patch
Created attachment 152369 [details] salome-ngplugin-3.2.6-r2.ebuild This is an ebuild for the netgen plugin for salome-smesh I've been interested in getting this working, as I'm trying to follow the elmer fem tutorial on the linux cae webpage http://www.caelinux.org/wiki/index.php/Doc:CAETutorials This is still a bit experimental but I think it works okay with the right version of netgen (see the other bugzilla entry) you shouldn't need to recompile smesh for this to work (I've added in smesh as a depend) but remember to do env-update && source /etc/profile after emerging to get this to show up in the menu To test run /opt/salome-3.2.6/KERNEL/bin/salome/runSalome select "MESH" from the dropdown box select "Mesh->Create Mesh" menu item Under the Alogrithm drop down box there should now be Hexahedron Netgen 1D-2D-3D <- Tetrahedron (Netgen) <- 3D extrusion Projection 3D Radial Prism 3D for info, For some reason at the configure stage the detection of netgen fails due to a linkage problem in the test but this linkage problem doesn't show up during the real compile so it doesn't stop it from compiling later on in the actual build I've not been able to figure out a fix for it, but it seems to still work okay without a problem it seems to extract all the object files from the netgen libs and then create it's own libs based on these objects I'm not sure what sort of netgen support is included in salome 2008 (3.2.9) as only the bins not the sources are available at the moment
Created attachment 152371 [details] salome-ngplugin-3.2.6-r2.ebuild slight error, corrected
I'm not sure if there's a bug setup for code-aster yet but for info I've created a new bug for scotch which I think is one of the depends (it's included in the code aster src file) also I've just put up a load of other ebuilds for elmer fem
(In reply to comment #372) Richard I have a problem with the ebuild on amd64, if you look under /opt/salome/KERNEL you will find two libraries: lib and lib64. lib should not be there, I suppose everything should be put under lib64 but I do not succeed with that. As a result, runSalome does not start, complaining about a module that cannot be found (I search in lib64 and the module is in lib) Configure parser: Warning : could not find user configuration file Searching for a free port for naming service: 2810 2811 2812 - OK Lancement du Naming Service runNS.sh > /tmp/logs/ted/salomeNS.log 2>&1 Searching Naming Service found in 0.0 seconds Searching /Registry in Naming Service + found in 0.5 seconds Traceback (most recent call last): File "/opt/salome-3.2.6/KERNEL/bin/salome/runSalome.py", line 802, in useSalome clt = startSalome(args, modules_list, modules_root_dir) File "/opt/salome-3.2.6/KERNEL/bin/salome/runSalome.py", line 676, in startSalome import SALOME_ModuleCatalog ImportError: No module named SALOME_ModuleCatalog Any idea about how to solve this cleanly? I tried to get some inspiration from the pycalculator module. I did not get far... :( Daniel > Created an attachment (id=152351) [edit] > salome-kernel-3.2.6-r2.ebuild > > salome-kernel: > amended depends back to mpich2 > I've also amended some of the flags passed to configure, > in some cases specifying --without-<package> triggers the same result as > --with-<package> > so to disable you have to omit the flag altogether > I'm not sure where the problem is but I suspect it's within one of the .m4 > scripts within salome-kernel > (all the other packages seem to use these from the installed salome-kernel > package under /opt) > I've tried to alter the ebuilds to compensate since I couldn't locate the > underlying problem > added an icon / menu entry under Graphics, remember to restart X after emerging > if X is running > as the updated env variables need to be updated before this will work >
Created attachment 152979 [details] salome-kernel. There is an issue with Python file location on amd64
thanks for spotting this I think the kernel module is the only one affected for the lib path the others appear to install everything to lib64 (normally lib already symlinks to lib64 under /usr but we seem to be installing under /opt for salome) the funny thing is, I've been using salome under amd64 and, runSalome appeared to work okay before the change without giving an error :) for info the netgen plugin still doesn't work fully (I'm unsure if this is just unique to amd64 due to long integers) I'm still getting null reference errors when computing the mesh, so I'm trying to debug the code
Hi! > thanks for spotting this My pleasure... (So to say... ;) ) > I think the kernel module is the only one affected for the lib path > the others appear to install everything to lib64 Good to hear. The PYTHONPATH are still wrong. In most cases they refer hardcoded to lib, not lib64 (amd64) / lib (x86) > (normally lib already symlinks to lib64 under /usr but we seem to be installing > under /opt for salome) > > the funny thing is, I've been using salome under amd64 and, runSalome appeared > to work okay before the change without giving an error :) It's because of the PYTHONPATH. I could not start runSalome without having strange messages. I checked the KERNEL directory and discovered that I had two libs (lib and lib64). I came to the conclusion that this was the source of the problem and decided to move everything to lib64 (as it should be). We can consider a simlink as the one found in /, this is a simple thing that can be fixed afterwards. I don't succeed to get everything under lib64. I suppose a patch somewhere is needed to correct the problem but I don't know where and how... :( I suspect aclocal.m4 but that's a wild guess... > for info the netgen plugin still doesn't work fully (I'm unsure if this is just > unique to amd64 due to long integers) > I'm still getting null reference errors when computing the mesh, so I'm trying > to debug the code OK... I see that you are also having some fun on your side... ;) Daniel
Created attachment 153067 [details] salome-kernel-3.2.6-r2.ebuild this should result in all the libs being put into the correct lib directory (lib64 under amd64), just a case of specifying pythondir during the install stage on a separate issue I've noticed after running "ps -A" instances of python, omniNames, SALOME_Containe being left over once the application has quit left running in the background
Hi! Thanks for the help. > Created an attachment (id=153067) [edit] > salome-kernel-3.2.6-r2.ebuild > > this should result in all the libs being put into the correct lib directory > (lib64 under amd64), just a case of specifying pythondir during the install > stage > > on a separate issue I've noticed after running "ps -A" instances of > python, omniNames, SALOME_Containe being left over once the application has > quit left running in the background Same problem here (x86, amd64). I have no idea where it comes from. Daniel
I have an other problem: KERNEL and GUI being the only one installed, I get: Searching for a free port for naming service: 2810 - OK Lancement du Naming Service runNS.sh > /tmp/logs/ted/salomeNS.log 2>&1 Searching Naming Service found in 0.0 seconds Searching /Containers/morghaan/FactoryServerPy in Naming Service +++ found in 1.5 seconds Searching /Containers/morghaan/SuperVisionContainer in Naming Service + found in 0.5 seconds Searching /Kernel/Session in Naming Service ++++++Traceback (most recent call last): File "/opt/salome-3.2.6/KERNEL/bin/salome/runSalome.py", line 802, in useSalome clt = startSalome(args, modules_list, modules_root_dir) File "/opt/salome-3.2.6/KERNEL/bin/salome/runSalome.py", line 756, in startSalome session=clt.waitNSPID("/Kernel/Session",mySessionServ.PID,SALOME.Session) File "/opt/salome-3.2.6/KERNEL/bin/salome/orbmodule.py", line 173, in waitNSPID raise "Impossible de trouver %s" % theName Impossible de trouver /Kernel/Session --- erreur au lancement Salome --- It says that it cannot find /Kernel/Session Any idea of where this could come from? (amd64 here, never seen that on x86) Daniel
Hi! I just commited kernel, gui, med and component to the Gentoo science overlay. I am planning to commit the other ones within a few days. Hopefully this will increase the user base and the feedbacks. ;) Daniel
(In reply to comment #390) > Hi! > > I just commited kernel, gui, med and component to the Gentoo science overlay. I > am planning to commit the other ones within a few days. > Hopefully this will increase the user base and the feedbacks. ;) > > > Daniel > Looking forward to using the overlay and not having to do this manually anymore! Will make my life a lot easier! Dewald
Hi! Using the science overlay is indeed much easier than copying from bugzilla. I tried to emerge the overlay version of salome-kernel,gui,med, component and found the following: #emerge salome-gui Calculating dependencies... done! >>> Verifying ebuild Manifests... !!! A file listed in the Manifest could not be found: /usr/portage/local/layman/science/sci-misc/salome-gui/files/icon/salome-gui-icon.png Is this icon in the wrong place or missing? Bart
(In reply to comment #392) > Hi! > > Using the science overlay is indeed much easier than copying from bugzilla. > I tried to emerge the overlay version of salome-kernel,gui,med, component and > found the following: > > > #emerge salome-gui > Calculating dependencies... done! > >>> Verifying ebuild Manifests... > !!! A file listed in the Manifest could not be found: > /usr/portage/local/layman/science/sci-misc/salome-gui/files/icon/salome-gui-icon.png > > Is this icon in the wrong place or missing? Hi! It's a minor mistake I made. I did not find the time to correct it. Just regenerate the file in salome-gui by using 'ebuild salome-gui-3.2.6.ebuild digest'. Daniel
Created attachment 154323 [details, diff] patch for compilation with gcc-4.3.0
Created attachment 154325 [details, diff] patch for compilation with gcc-4.3.0
Created attachment 154327 [details, diff] patch for compilation with gcc-4.3.0
Created attachment 154329 [details, diff] patch for compilation with gcc-4.3.0
Created attachment 154331 [details, diff] patch for compilation with gcc-4.3.0
Created attachment 154333 [details, diff] patch for compilation with gcc-4.3.0
Created attachment 154335 [details, diff] patch for compilation with gcc-4.3.0 There's still a linking error on Amd 64 /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: StdMeshers_Propagation.lo: relocation R_X86_64_PC32 against `(anonymous namespace)::PropagationMgr::GetSource(SMESH_subMesh*)' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status
Comment on attachment 154327 [details, diff] patch for compilation with gcc-4.3.0 Configuring fails when trying to emerge salome-kernel with USE=mpi, mpich2-1.0.3 is installed. Do I need a newer Version of mpich2 or mor USEFLFAGS (current setting : sys-cluster/mpich2-1.0.3 USE="crypt threads -cxx -debug -doc -mpe") --------------------------------------------- testing mpi --------------------------------------------- checking mpi.h usability... yes checking mpi.h presence... yes checking for mpi.h... yes checking for elan_init in -lelan... no checking for MPI_Init in -lmpi... no checking for MPI_Publish_name in -lmpi... no --------------------------------------------- testing mpich --------------------------------------------- checking for mpi.h... (cached) yes checking for MPI_Init in -lmpich... no checking for MPI_Publish_name in -lmpich... no [..] --- products requested by user mpi : no
(In reply to comment #399) Hi! > patch for compilation with gcc-4.3.0 Thank you very much for the good work and the patches. I am planning to put them in the overlay ASAP. I have a question though regarding these patches. Are they specific gcc-4 or are they specific >=gcc-4.3.0? Daniel
(In reply to comment #401) > (From update of attachment 154327 [details, diff] [edit]) > Configuring fails when trying to emerge salome-kernel with USE=mpi, > mpich2-1.0.3 is installed. Do I need a newer Version of mpich2 or mor USEFLFAGS > (current setting : sys-cluster/mpich2-1.0.3 USE="crypt threads -cxx -debug > -doc -mpe") I will check this on my machine at home and I'll get back to you. MPI support is a rich topic in itself... ;) Orginally just mpich2 was selected by the ebuild. When Richard reworked the ebuild, he added some support to mpi as well. I spoke with Sebastien from Gentoo and he said that what Gentoo is targetting in the long run is OpenMPI. The question now is how Salome interacts with OpenMPI and how to make the switch (if it is possible at all...) Daniel
> I have a question though regarding these patches. > Are they specific gcc-4 or are they specific >=gcc-4.3.0? > > Daniel > They are gcc-4.3 specific, with <=gcc-4.2.* it should work without the patches.
Created attachment 158563 [details, diff] Updated patch
Bart, The new patch is now on the overlay. Thanks for the good work! ;) Daniel
Hello, great work @ all, for doing this ebuilds! But, as I suggested in comment #24, could you please change the line: SRC_URI="salome-3.2.6.tar.gz" to SRC_URI="http://files.opencascade.com/Salome${PV}/src${PV}.tar.gz" For those who want to direct download the sources, without logging in to the salome homepage, just use: wget http://files.opencascade.com/Salome3.2.6/src3.2.6.tar.gz I think, you're using this one, or not? Thanks, a lot!
Created attachment 161347 [details, diff] Solve relocation error by inlining This patch solves the following error: /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.3/../../../../x86_64-pc-linux-gnu/bin/ld: StdMeshers_Propagation.lo: relocation R_X86_64_PC32 against `(anonymous namespace)::PropagationMgr::GetSource(SMESH_subMesh*)' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.3/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status Now it's possible to compile salome-smesh on x86_64.
Thanks go to Debian which showed that the GetPropagationSource function was causing the Problem (they simply removed it, it seems to be unused anyway) http://lyre.mit.edu/~powell/salome/salome_3.2.6-3_amd64.changes and some unknown mailing list which suggested that inlining can be used to work around relocation errors.
After all inlining should be the same as removing if the function is used nowhere. Have to test if inlining solves the problem when the funtion is actually used.
I'm trying to build salome-kernel. I get errors similar to the swig_wrap errors in comment #203: ---------------------- x86_64-pc-linux-gnu-g++ "-DPACKAGE_NAME=\"Salome2 Project\"" -DPACKAGE_TARNAME=\"salome\" -DPACKAGE_VERSION=\"3.2.6\" "-DPACKAGE_STRING=\"Salome2 Project 3.2.6\"" -DPACKAGE_BUGREPORT=\"gboulant@CS\" -DPACKAGE=\"salome\" -DVERSION=\"3.2.6\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBDL=1 -DHAVE_LIBRT=1 -DHAVE_LIBM=1 -DHAVE_NAMESPACES= -DHAVE_PTHREAD=1 -DRM=\"/bin/rm\" -DSH=\"/bin/sh\" -DCP=\"/bin/cp\" -DRSH=\"/usr/bin/rsh\" -DRCP=\"/usr/bin/rcp\" -DSSH=\"/usr/bin/ssh\" -DSCP=\"/usr/bin/scp\" -I. -I/usr/include/python2.5 -I. -I./../Batch -m64 -D_OCC64 -march=opteron -O2 -pipe -m64 -ffriend-injection -fpermissive -O -Wno-deprecated -Wparentheses -Wreturn-type -Wunused -pthread -MT _libBatch_Swig_la-swig_wrap.lo -MD -MP -MF .deps/_libBatch_Swig_la-swig_wrap.Tpo -c swig_wrap.cpp -fPIC -DPIC -o .libs/_libBatch_Swig_la-swig_wrap.o swig_wrap.cpp: In function 'int SWIG_Python_ConvertPtr(PyObject*, void**, swig_type_info*, int)': swig_wrap.cpp:1177: warning: invalid conversion from 'const char*' to 'char*' swig_wrap.cpp: In function 'PyObject* _wrap_new_Job__SWIG_1(PyObject*, PyObject*)': swig_wrap.cpp:1478: error: cannot convert 'int*' to 'Py_ssize_t*' for argument '2' to 'int PyDict_Next(PyObject*, Py_ssize_t*, PyObject**, PyObject**)' swig_wrap.cpp: In function 'PyObject* _wrap_new_Job__SWIG_2(PyObject*, PyObject*)': swig_wrap.cpp:1536: error: cannot convert 'int*' to 'Py_ssize_t*' for argument '2' to 'int PyDict_Next(PyObject*, Py_ssize_t*, PyObject**, PyObject**)' swig_wrap.cpp: In function 'PyObject* _wrap_new_Job__SWIG_3(PyObject*, PyObject*)': swig_wrap.cpp:1588: error: cannot convert 'int*' to 'Py_ssize_t*' for argument '2' to 'int PyDict_Next(PyObject*, Py_ssize_t*, PyObject**, PyObject**)' swig_wrap.cpp:1616: error: cannot convert 'int*' to 'Py_ssize_t*' for argument '2' to 'int PyDict_Next(PyObject*, Py_ssize_t*, PyObject**, PyObject**)' swig_wrap.cpp: In function 'PyObject* _wrap_Job_setParametre(PyObject*, PyObject*)': swig_wrap.cpp:1813: error: cannot convert 'int*' to 'Py_ssize_t*' for argument '2' to 'int PyDict_Next(PyObject*, Py_ssize_t*, PyObject**, PyObject**)' swig_wrap.cpp: In function 'PyObject* _wrap_Job_setEnvironnement(PyObject*, PyObject*)': swig_wrap.cpp:1916: error: cannot convert 'int*' to 'Py_ssize_t*' for argument '2' to 'int PyDict_Next(PyObject*, Py_ssize_t*, PyObject**, PyObject**)' swig_wrap.cpp: In function 'PyObject* _wrap_JobId_alterJob__SWIG_0(PyObject*, PyObject*)': swig_wrap.cpp:2363: error: cannot convert 'int*' to 'Py_ssize_t*' for argument '2' to 'int PyDict_Next(PyObject*, Py_ssize_t*, PyObject**, PyObject**)' swig_wrap.cpp:2391: error: cannot convert 'int*' to 'Py_ssize_t*' for argument '2' to 'int PyDict_Next(PyObject*, Py_ssize_t*, PyObject**, PyObject**)' swig_wrap.cpp: In function 'PyObject* _wrap_JobId_alterJob__SWIG_1(PyObject*, PyObject*)': swig_wrap.cpp:2443: error: cannot convert 'int*' to 'Py_ssize_t*' for argument '2' to 'int PyDict_Next(PyObject*, Py_ssize_t*, PyObject**, PyObject**)' swig_wrap.cpp: In function 'PyObject* _wrap_JobId_alterJob__SWIG_2(PyObject*, PyObject*)': swig_wrap.cpp:2504: error: cannot convert 'int*' to 'Py_ssize_t*' for argument '2' to 'int PyDict_Next(PyObject*, Py_ssize_t*, PyObject**, PyObject**)' swig_wrap.cpp: In function 'PyObject* _wrap_JobId_setParametre(PyObject*, PyObject*)': swig_wrap.cpp:2660: error: cannot convert 'int*' to 'Py_ssize_t*' for argument '2' to 'int PyDict_Next(PyObject*, Py_ssize_t*, PyObject**, PyObject**)' swig_wrap.cpp: In function 'PyObject* _wrap_JobId_setEnvironnement(PyObject*, PyObject*)': swig_wrap.cpp:2721: error: cannot convert 'int*' to 'Py_ssize_t*' for argument '2' to 'int PyDict_Next(PyObject*, Py_ssize_t*, PyObject**, PyObject**)' swig_wrap.cpp: In function 'PyObject* _wrap_BatchManager_alterJob__SWIG_0(PyObject*, PyObject*)': swig_wrap.cpp:3449: error: cannot convert 'int*' to 'Py_ssize_t*' for argument '2' to 'int PyDict_Next(PyObject*, Py_ssize_t*, PyObject**, PyObject**)' swig_wrap.cpp:3477: error: cannot convert 'int*' to 'Py_ssize_t*' for argument '2' to 'int PyDict_Next(PyObject*, Py_ssize_t*, PyObject**, PyObject**)' swig_wrap.cpp: In function 'PyObject* _wrap_BatchManager_alterJob__SWIG_1(PyObject*, PyObject*)': swig_wrap.cpp:3539: error: cannot convert 'int*' to 'Py_ssize_t*' for argument '2' to 'int PyDict_Next(PyObject*, Py_ssize_t*, PyObject**, PyObject**)' swig_wrap.cpp: In function 'PyObject* _wrap_BatchManager_alterJob__SWIG_2(PyObject*, PyObject*)': swig_wrap.cpp:3610: error: cannot convert 'int*' to 'Py_ssize_t*' for argument '2' to 'int PyDict_Next(PyObject*, Py_ssize_t*, PyObject**, PyObject**)' swig_wrap.cpp: In function 'void SWIG_Python_FixMethods(PyMethodDef*, swig_const_info*, swig_type_info**, swig_type_info**)': swig_wrap.cpp:4505: warning: invalid conversion from 'const char*' to 'char*' swig_wrap.cpp: At global scope: swig_wrap.cpp:231: warning: 'swig_type_info* SWIG_TypeDynamicCast(swig_type_info*, void**)' defined but not used swig_wrap.cpp:419: warning: 'const char* SWIG_UnpackDataName(const char*, void*, size_t, const char*)' defined but not used swig_wrap.cpp:499: warning: 'void SWIG_PropagateClientData(swig_type_info*)' defined but not used swig_wrap.cpp:1198: warning: 'void* SWIG_Python_MustGetPtr(PyObject*, swig_type_info*, int, int)' defined but not used swig_wrap.cpp:1212: warning: 'int SWIG_Python_ConvertPacked(PyObject*, void*, size_t, swig_type_info*, int)' defined but not used swig_wrap.cpp:4439: warning: 'void SWIG_Python_addvarlink(PyObject*, char*, PyObject* (*)(), int (*)(PyObject*))' defined but not used make[3]: *** [_libBatch_Swig_la-swig_wrap.lo] Error 1 make[3]: Leaving directory `/var/tmp/portage/sci-misc/salome-kernel-3.2.6/work/src3.2.6/KERNEL_SRC_3.2.6/src/Batch_SWIG' make[2]: *** [all] Error 2 make[2]: Leaving directory `/var/tmp/portage/sci-misc/salome-kernel-3.2.6/work/src3.2.6/KERNEL_SRC_3.2.6/src/Batch_SWIG' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/sci-misc/salome-kernel-3.2.6/work/src3.2.6/KERNEL_SRC_3.2.6/src' make: *** [all-recursive] Error 1 * * ERROR: sci-misc/salome-kernel-3.2.6 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 3521: Called die * The specific snippet of code: * emake || die "compilation failed" * The die message: * compilation failed --------------------- My emerge --info : Portage 2.1.4.4 (default-linux/amd64/2007.0/desktop, gcc-4.1.2, glibc-2.6.1-r0, 2.6.24-gentoo-r3 x86_64) ================================================================= System uname: 2.6.24-gentoo-r3 x86_64 Dual-Core AMD Opteron(tm) Processor 2216 Timestamp of tree: Wed, 13 Aug 2008 19:45:01 +0000 app-shells/bash: 3.2_p33 dev-java/java-config: 1.3.7, 2.1.6 dev-lang/python: 2.4.4-r14, 2.5.2-r7 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-r2 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-r3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=opteron -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-march=opteron -O2 -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" LINGUAS="en" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_EXTRA_OPTS="--delete-after --timeout=500" 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/local/portage/layman/science /usr/local/portage/layman/sunrise /usr/local/portage /usr/local/portage/Gentoo-sage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="3dnow X Xaw3d aac aalib acl acpi alsa amd64 apache2 audiofile bash-completion berkdb bzip2 cairo cdr cli cracklib crypt cups dbus dri dvd dvdr dvdread emboss encode esd evo exif fam firefox flac fortran gdbm gif gnome gphoto2 gpm gstreamer gtk hal iconv ieee1394 imlib ipv6 isdnlog java jpeg kerberos ldap lesstif lm_sensors mad midi mikmod mmx motif mozilla mp3 mpeg mudflap ncurses nls nptl nptlonly nsplugin ogg opengl openmp oss pam pcre pdf perl png pppd python qt3 qt3support qt4 quicktime radius readline reflection sdl session spell spl sse sse2 ssl svg tcl tcpd tiff tk truetype unicode usb vorbis xml xorg xv 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 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" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en" USERLAND="GNU" VIDEO_CARDS="nvidia fbdev vesa vga nv" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS ------------------------ As you can see I have both python 2.4 and 2.5 installed, but all the python symlinks point to python 2.5. So, are the errors python version related? I do need python 2.5.
Sorry guys. I hadn't read far enough. I uncommented the line in the ebuild that applied the pyobject patch for Python 2.5, created a new Manifest and salome-kernel did build as did salome-gui.
(In reply to comment #412) > Sorry guys. I hadn't read far enough. I uncommented the line in the ebuild that > applied the pyobject patch for Python 2.5, created a new Manifest and > salome-kernel did build as did salome-gui. Hi! Good to hear. Thanks for the feedbacks! Daniel
Created attachment 163275 [details] salome-kernel-3.2.6.ebuild This ebuild is based on that one from the science overlay. - It has no more a fetch restriction. - Changed some hard coded versions to ${PV}. - If python-2.5 is installed, the ${P}-pyobject.patch is applied
(In reply to comment #414) > Created an attachment (id=163275) [edit] > salome-kernel-3.2.6.ebuild > > This ebuild is based on that one from the science overlay. > > - It has no more a fetch restriction. > - Changed some hard coded versions to ${PV}. > - If python-2.5 is installed, the ${P}-pyobject.patch is applied Thanks Oliver, Did you change the one on the repository as well? Daniel
(In reply to comment #415) > Thanks Oliver, > > Did you change the one on the repository as well? > > Daniel Hi Daniel, I have no write access to the science overlay, so I am not able to do the changes. Can you do the changes on the science overlay? May you also remove the fetch restrictions from the other salome ebuilds? Oliver
(In reply to comment #416) > Hi Daniel, > > I have no write access to the science overlay, so I am not able to do the > changes. Can you do the changes on the science overlay? > > May you also remove the fetch restrictions from the other salome ebuilds? I'll try to find some time to do that during the week-end. OK? ;) Daniel
Hi ! I coming back ;-) I can see a lot of work have been done ! Great ! I'have done some work and patches, and now, I can use : - omniorb 4.1.2 - python 2.5 - omniorbpy 3 There is just a bug in omniORB 4.1.0 and salome doesn't launch. But the bug is fixed in 4.1.2 (I don't know for 4.1.1) I will post them in few minutes. To use them, it is necessary to modify dependencies in ebuild and specify only omniORB and omniorbpy without version. If you can test it, to solve possible issue for other architecture and/or configuration. Thanks !
Created attachment 163841 [details, diff] patch for KERNEL component to use omniORB 4.1.x
Created attachment 163842 [details, diff] patch for SUPERV component to use omniORB 4.1.x
(In reply to comment #417) > (In reply to comment #416) > > > Hi Daniel, > > > > I have no write access to the science overlay, so I am not able to do the > > changes. Can you do the changes on the science overlay? > > > > May you also remove the fetch restrictions from the other salome ebuilds? > > I'll try to find some time to do that during the week-end. OK? ;) > > Daniel > I've removed the package fetch restrictions from all salome-* ebuilds in the science overlay. Furthermore I've fixed all repoman errors and warnings. Thus I suggest that further salome-* ebuilds are based from that in the science overlay. Thanks. Oliver
Created attachment 164412 [details, diff] pyobject patch for amd64 On amd64 with python 2.5 there errors remaining when using the pyobject patch.
(In reply to comment #422) > Created an attachment (id=164412) [edit] > pyobject patch for amd64 > > On amd64 with python 2.5 there errors remaining when using the pyobject patch. > I've tried to compile on amd64 salome-gui and salome-kernel with the last patches (salome-kernel-3.2.6-pyobject.patch and salome-kernel-3.2.6-omniorb_4.1.patch). salome-kernel compiled fine, but with salome-gui I got this error: SALOME_PYQT_Module.cxx: In member function 'void SALOME_PYQT_Module::init(CAM_Application*)': SALOME_PYQT_Module.cxx:768: error: cannot convert 'int*' to 'Py_ssize_t*' for argument '2' to 'int PyDict_Next(PyObject*, Py_ssize_t*, PyObject**, PyObject**)' make[4]: *** [SALOME_PYQT_Module.lo] Error 1 make[4]: Leaving directory `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/src/SALOME_PYQT/SALOME_PYQT_GUI' make[3]: *** [lib_SALOME_PYQT_GUI] Error 2 make[3]: Leaving directory `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/src/SALOME_PYQT' make[2]: *** [lib_SALOME_PYQT] Error 2 make[2]: Leaving directory `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6/src' make[1]: *** [lib_src] Error 2 make[1]: Leaving directory `/var/tmp/portage/sci-misc/salome-gui-3.2.6/work/src3.2.6/GUI_SRC_3.2.6' make: *** [all] Error 2 I think, this is an python2.5 problem. I've also installed: - omniorbpy-3.0 - omniORB-4.1.2
> SALOME_PYQT_Module.cxx: In member function 'void > SALOME_PYQT_Module::init(CAM_Application*)': > SALOME_PYQT_Module.cxx:768: error: cannot convert 'int*' to 'Py_ssize_t*' for > argument '2' to 'int PyDict_Next(PyObject*, Py_ssize_t*, PyObject**, > PyObject**)' Can you modify the "GUI_SRC_3.2.6/src/SALOME_PYQT/SALOME_PYQT_GUI/SALOME_PYQT_Module.cxx" file at the line 767, and replace "int pos = 0;" by "Py_ssize_t pos = 0;" ? And then, try to recompile. I cannot test this because I'm on a x86 machine and don't have any problem. Best regards. François
(In reply to comment #424) > Can you modify the > "GUI_SRC_3.2.6/src/SALOME_PYQT/SALOME_PYQT_GUI/SALOME_PYQT_Module.cxx" file > at the line 767, and replace "int pos = 0;" by "Py_ssize_t pos = 0;" ? And > then, try to recompile. > > Best regards. > > François > Thank you very much. That solved the problem! But now I got an error while compiling salome-med: x86_64-pc-linux-gnu-g++ -m64 -D_OCC64 -mtune=nocona -O2 -pipe -ffriend-injection -fpermissive -m64 -O -Wno-deprecated -Wparentheses -Wreturn-type -Wunused -pthread -DOMNIORB_VERSION=4 -D__x86__ -D__linux__ -DCOMP_CORBA_DOUBLE -DCOMP_CORBA_LONG -DHAVE_SOCKET -I../../../include/salome -I. -I. -I/usr/include -I/usr/include/omniORB4 -I/usr/include/COS -I/usr/include -DPCLINUX64 -c MED_Wrapper.cxx -fPIC -DPIC MED_Wrapper.cxx: In constructor 'MED::TLockProxy::TLockProxy(MED::TWrapper*)': MED_Wrapper.cxx:26: error: 'boost::detail::thread' has not been declared MED_Wrapper.cxx:26: error: expected primary-expression before '>' token MED_Wrapper.cxx:26: error: '::lock' has not been declared MED_Wrapper.cxx: In destructor 'MED::TLockProxy::~TLockProxy()': MED_Wrapper.cxx:34: error: 'boost::detail::thread' has not been declared MED_Wrapper.cxx:34: error: expected primary-expression before '>' token MED_Wrapper.cxx:34: error: '::unlock' has not been declared MED_Wrapper.cxx: At global scope: MED_Wrapper.cxx:16: warning: 'MYDEBUG' defined but not used MED_Wrapper.cxx:17: warning: 'MYVALUEDEBUG' defined but not used make[4]: *** [MED_Wrapper.lo] Error 1 make[4]: Leaving directory `/var/tmp/portage/sci-misc/salome-med-3.2.6/work/src3.2.6/MED_SRC_3.2.6/src/MEDWrapper/Base' make[3]: *** [lib_Base] Error 2 make[3]: Leaving directory `/var/tmp/portage/sci-misc/salome-med-3.2.6/work/src3.2.6/MED_SRC_3.2.6/src/MEDWrapper' make[2]: *** [lib_MEDWrapper] Error 2 make[2]: Leaving directory `/var/tmp/portage/sci-misc/salome-med-3.2.6/work/src3.2.6/MED_SRC_3.2.6/src' make[1]: *** [lib_src] Error 2 make[1]: Leaving directory `/var/tmp/portage/sci-misc/salome-med-3.2.6/work/src3.2.6/MED_SRC_3.2.6' make: *** [all] Error 2 I've installed boost-1.35.0-r2.
I've added the last patches to the ebuilds in the science overlay. Furthermore, I've reworked the USE-Flags in the salome-kernel and salome-gui ebuilds, because most of them does not seamed to be optional. I am not sure, if we now need >=net-misc/omniORB-4.1.2 in the ebuilds, regarding comment 415. Please check the new ebuilds and comment any problem or error.
> x86_64-pc-linux-gnu-g++ -m64 -D_OCC64 -mtune=nocona -O2 -pipe > -ffriend-injection -fpermissive -m64 -O -Wno-deprecated -Wparentheses > -Wreturn-type -Wunused -pthread -DOMNIORB_VERSION=4 -D__x86__ -D__linux__ > -DCOMP_CORBA_DOUBLE -DCOMP_CORBA_LONG -DHAVE_SOCKET -I../../../include/salome > -I. -I. -I/usr/include -I/usr/include/omniORB4 -I/usr/include/COS > -I/usr/include -DPCLINUX64 -c MED_Wrapper.cxx -fPIC -DPIC > MED_Wrapper.cxx: In constructor 'MED::TLockProxy::TLockProxy(MED::TWrapper*)': > MED_Wrapper.cxx:26: error: 'boost::detail::thread' has not been declared > MED_Wrapper.cxx:26: error: expected primary-expression before '>' token > MED_Wrapper.cxx:26: error: '::lock' has not been declared > MED_Wrapper.cxx: In destructor 'MED::TLockProxy::~TLockProxy()': > MED_Wrapper.cxx:34: error: 'boost::detail::thread' has not been declared > MED_Wrapper.cxx:34: error: expected primary-expression before '>' token > MED_Wrapper.cxx:34: error: '::unlock' has not been declared > MED_Wrapper.cxx: At global scope: > MED_Wrapper.cxx:16: warning: 'MYDEBUG' defined but not used > MED_Wrapper.cxx:17: warning: 'MYVALUEDEBUG' defined but not used > make[4]: *** [MED_Wrapper.lo] Error 1 > make[4]: Leaving directory > > I've installed boost-1.35.0-r2. > Seems to be boost related. Can you install a previous stable version and compile again ? On my computer, I have boost-1.34.1-r2. I will install your version and try to compile salome-med
> I've installed boost-1.35.0-r2. I confirm the bug for boost-1.35.0-r2.
(In reply to comment #428) > > I've installed boost-1.35.0-r2. > I confirm the bug for boost-1.35.0-r2. > This error is normal. Below is an extract of the change log for boost 1.35 boost::detail::thread::lock_ops has been removed. Code that relies on the lock_ops implementation detail will no longer work, as this has been removed, as it is no longer necessary now that mutex types now have public lock() and unlock() member functions. http://www.boost.org/users/news/version_1_35_0
Created attachment 164611 [details, diff] fix a bug with boost-1.35 for salome-med
(In reply to comment #430) > Created an attachment (id=164611) [edit] > fix a bug with boost-1.35 for salome-med > Thanks for the patch. I've tested salome-med and boost-1.35.0 with this patch and it works. I've committed all changes to the science overlay. Furthermore I've set the dependencies to >omniORB=4.1.2 If somebody can run salome with another version of omniORB, please let me know how.
> If somebody can run salome with another version of omniORB, please let me know > how. > I could run salome with omniORB 4.0.5 and omniorbpy 2.5. No particular things to do. Just compile omniORB, omniorby and then salome. I known salome doesn't run with omniORB 4.1.0 due to a bug in this version.
(In reply to comment #432) > I could run salome with omniORB 4.0.5 and omniorbpy 2.5. No particular things > to do. Just compile omniORB, omniorby and then salome. > > I known salome doesn't run with omniORB 4.1.0 due to a bug in this version. > If I'm using omniORB 4.0.5 and omniorbpy 2.5 on my amd64 machine (have not tested it on x86) I get the following errors when I want to start salome: ~ $ runSalome Searching for a free port for naming service: 2810 2811 2812 2813 2814 2815 - OK Lancement du Naming Service runNS.sh > /tmp/logs/myname/salomeNS.log 2>&1 Searching Naming Service + found in 0.1 seconds omniORB: Assertion failed. This indicates a bug in the application using omniORB, or maybe in omniORB itself. file: pyExceptions.cc line: 417 info: PyClass_Check(excclass) omniORB: To endpoint: giop:tcp:192.168.1.1:2815. Send GIOP 1.0 MessageError because a protocol error has been detected. Connection is closed. Searching /Containers/hostname/FactoryServerPy in Naming Service +omniORB: Assertion failed. This indicates a bug in the application using omniORB, or maybe in omniORB itself. file: pyExceptions.cc line: 417 info: PyClass_Check(excclass) omniORB: To endpoint: giop:tcp:192.168.1.1:2815. Send GIOP 1.0 MessageError because a protocol error has been detected. Connection is closed.
(In reply to comment #433) > (In reply to comment #432) > > I could run salome with omniORB 4.0.5 and omniorbpy 2.5. No particular things > > to do. Just compile omniORB, omniorby and then salome. > > > > I known salome doesn't run with omniORB 4.1.0 due to a bug in this version. > > > If I'm using omniORB 4.0.5 and omniorbpy 2.5 on my amd64 machine (have not > tested it on x86) I get the following errors when I want to start salome: > > ~ $ runSalome > Searching for a free port for naming service: 2810 2811 2812 2813 2814 2815 - > OK > Lancement du Naming Service runNS.sh > /tmp/logs/myname/salomeNS.log 2>&1 > Searching Naming Service + found in 0.1 seconds > omniORB: Assertion failed. This indicates a bug in the application using > omniORB, or maybe in omniORB itself. > file: pyExceptions.cc > line: 417 > info: PyClass_Check(excclass) > omniORB: To endpoint: giop:tcp:192.168.1.1:2815. Send GIOP 1.0 MessageError > because a protocol error has been detected. Connection is closed. > Searching /Containers/hostname/FactoryServerPy in Naming Service +omniORB: > Assertion failed. This indicates a bug in the application using > omniORB, or maybe in omniORB itself. > file: pyExceptions.cc > line: 417 > info: PyClass_Check(excclass) > omniORB: To endpoint: giop:tcp:192.168.1.1:2815. Send GIOP 1.0 MessageError > because a protocol error has been detected. Connection is closed. > I get this error with omniorb-4.1.0 on x86. But everything is ok with omniorb 4.0.5 on x86
Created attachment 168552 [details, diff] Patch for compilation with hdf5-1.6.7
Created attachment 168560 [details, diff] Patch for compilation with qt-3.3.8b This patch fixes the issue addressed here: http://www.mail-archive.com/pyqt@riverbankcomputing.com/msg13403.html Solution stolen from the debian patch (salome_3.2.6-7.diff.gz) found here: http://lyre.mit.edu/~powell/salome/
Created attachment 168624 [details, diff] Patch for compilation with vtk-5.2 on amd64 On amd64 systems vtkIdType is 32bit in vtk-5.0.4 but 64bit in vtk-5.2.0-r1. On x86 Systems this patch should be unnecessary.
Created attachment 168626 [details] ebuild for vtk-5.2 This adds the appropriate include directory (/usr/include/vtk-5.2) if >=vtk-5.2 is installed
Created attachment 168724 [details, diff] Patch for compilation with vtk-5.2
Created attachment 168726 [details] ebuild for vtk-5.2
Created attachment 168734 [details, diff] Patch for compilation with vtk-5.2
Created attachment 168736 [details] ebuild for vtk-5.2
Hi everybody! Bart's changes are now in the overlay. Thank you Bart for your patches and your efforts. Daniel
Hi! I am trying to rebuild salome now from scratch and I get the following error with salome-kernel: i686-pc-linux-gnu-g++ "-DPACKAGE_NAME=\"Salome2 Project\"" -DPACKAGE_TARNAME=\"salome\" -DPACKAGE_VERSION=\"3.2.6\" "-DPACKAGE_STRING=\"Salome2 Project 3.2.6\"" -DPACKAGE_BUGREPORT=\"gboulant@CS\" -DPACKAGE=\"salome\" -DVERSION=\"3.2.6\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBDL=1 -DHAVE_LIBRT=1 -DHAVE_LIBM=1 -DHAVE_NAMESPACES= -DHAVE_PTHREAD=1 -D__x86__=1 -D__linux__=1 -D__OSVERSION__=1 -DOMNIORB=1 -DCORBA_HAVE_POA=1 -DCORBA_ORB_INIT_HAVE_3_ARGS=1 -DCORBA_ORB_INIT_THIRD_ARG=\"omniORB\" -DRM=\"/bin/rm\" -DSH=\"/bin/sh\" -DCP=\"/bin/cp\" -DRSH=\"/usr/bin/rsh\" -DRCP=\"/usr/bin/rcp\" -DSSH=\"/usr/bin/ssh\" -DSCP=\"/usr/bin/scp\" -I. -I/usr/include/python2.5 -DHAVE_CONFIG_H -I./../Notification -I./../Basics -I./../SALOMELocalTrace -DOMNIORB_VERSION=4 -D__x86__ -D__linux__ -DCOMP_CORBA_DOUBLE -DCOMP_CORBA_LONG -I/usr/include -I/usr/include/omniORB4 -I/usr/include/COS -DHAVE_SOCKET -march=pentium4 -O2 -pipe -fomit-frame-pointer -O -Wno-deprecated -Wparentheses -Wreturn-type -Wunused -pthread -MT _libNOTIFICATION_la-swig_wrap.lo -MD -MP -MF .deps/_libNOTIFICATION_la-swig_wrap.Tpo -c swig_wrap.cpp -fPIC -DPIC -o .libs/_libNOTIFICATION_la-swig_wrap.o mv -f .deps/_libNOTIFICATION_la-NOTIFICATION_Swig.Tpo .deps/_libNOTIFICATION_la-NOTIFICATION_Swig.Plo swig_wrap.cpp: In function `int SWIG_Python_ConvertPtr(PyObject*, void**, swig_type_info*, int)': swig_wrap.cpp:1177: error: invalid conversion from `const char*' to `char*' swig_wrap.cpp: In function `void SWIG_Python_FixMethods(PyMethodDef*, swig_const_info*, swig_type_info**, swig_type_info**)': swig_wrap.cpp:2026: error: invalid conversion from `const char*' to `char*' swig_wrap.cpp: At global scope: swig_wrap.cpp:231: warning: 'swig_type_info* SWIG_TypeDynamicCast(swig_type_info*, void**)' defined but not used swig_wrap.cpp:419: warning: 'const char* SWIG_UnpackDataName(const char*, void*, size_t, const char*)' defined but not used swig_wrap.cpp:499: warning: 'void SWIG_PropagateClientData(swig_type_info*)' defined but not used swig_wrap.cpp:1198: warning: 'void* SWIG_Python_MustGetPtr(PyObject*, swig_type_info*, int, int)' defined but not used swig_wrap.cpp:1212: warning: 'int SWIG_Python_ConvertPacked(PyObject*, void*, size_t, swig_type_info*, int)' defined but not used swig_wrap.cpp:1437: warning: 'int SWIG_CheckLongInRange(long int, long int, long int, const char*)' defined but not used swig_wrap.cpp:1960: warning: 'void SWIG_Python_addvarlink(PyObject*, char*, PyObject*(*)(), int (*)(PyObject*))' defined but not used make[3]: *** [_libNOTIFICATION_la-swig_wrap.lo] Error 1 make[3]: Leaving directory `/var/tmp/portage/sci-misc/salome-kernel-3.2.6/work/src3.2.6/KERNEL_SRC_3.2.6/src/NOTIFICATION_SWIG' make[2]: *** [all] Error 2 make[2]: Leaving directory `/var/tmp/portage/sci-misc/salome-kernel-3.2.6/work/src3.2.6/KERNEL_SRC_3.2.6/src/NOTIFICATION_SWIG' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/sci-misc/salome-kernel-3.2.6/work/src3.2.6/KERNEL_SRC_3.2.6/src' make: *** [all-recursive] Error 1 It's an x86 box with gcc-3.4.6, omniORB-4.1.2, omniorbpy-3.0 and swig-1.3.36 Daniel
Hello again, I forgot to mention. I use Puthon 2.5 and the python patch is applied: >>> Unpacking src3.2.6.tar.gz to /var/tmp/portage/sci-misc/salome-kernel-3.2.6/work * Applying salome-kernel-3.2.6_openpbs.patch ... [ ok ] * Applying salome-kernel-3.2.6-Batch_Couple.patch ... [ ok ] * Applying salome-kernel-3.2.6-omniorb_4.1.patch ... [ ok ] * Applying salome-kernel-3.2.6-pyobject.patch ... [ ok ] * Applying salome-kernel-3.2.6-mpich2.patch ...
Hi guys I am happy to report that Salome now compiles runs on my machine! Python 2.5 and all! Thank you for everybody's effort! Here is my relevant emerge --info: Portage 2.2_rc12 (default-linux/amd64/2007.0, gcc-4.2.4, glibc-2.8_p20080602-r0, 2.6.26-gentoo-r1 x86_64) ================================================================= System uname: Linux-2.6.26-gentoo-r1-x86_64-AMD_Athlon-tm-_64_X2_Dual_Core_Processor_4400+-with-glibc2.2.5 Timestamp of tree: Thu, 30 Oct 2008 01:45:01 +0000 ccache version 2.4 [enabled] app-shells/bash: 3.2_p39 dev-java/java-config: 1.3.7, 2.1.6-r1 dev-lang/python: 2.4.4-r14, 2.5.2-r8 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r7 dev-util/cmake: 2.6.1 sys-apps/baselayout: 2.0.0 sys-apps/openrc: 0.2.5 sys-apps/sandbox: 1.2.18.1-r3 sys-devel/autoconf: 2.13, 2.62-r1 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1-r1 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 2.2.4 virtual/os-headers: 2.6.26 ACCEPT_KEYWORDS="amd64 ~amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=athlon64 -fomit-frame-pointer -pipe -mmmx -msse -msse2 -msse3 -m3dnow" CHOST="x86_64-pc-linux-gnu" Python 2.5 is currently set! Dewald
I install all packages salome-* except salome-visu. Salome-visu blocked in VISU_MergeFilter: ----------------------------------------------------------------- /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header. Please consider using one of the 32 headers found in section 17.4.1.2 of the C++ standard. Examples include substituting the <X> header for the <X.h> header for C++ includes, or <iostream> instead of the deprecated header <iostream.h>. To disable this warning use -Wno-deprecated. VISU_MergeFilter.cxx: In function 'void<unnamed>::DeepCopyField(vtkDataSetAttributes*, const char*, vtkDataSetAttributes*, const<unnamed>::TSortedArray&, const<unnamed>::TId2IdMap&)': VISU_MergeFilter.cxx:412: error: cannot convert 'int (vtkFieldData::*)(vtkAbstractArray*)' to 'int (vtkDataSetAttributes::*)(vtkDataArray*)' for argument '3' to 'vtkDataArray*<unnamed>::DeepCopyArray(vtkDataArray*, vtkDataSetAttributes*, int (vtkDataSetAttributes::*)(vtkDataArray*), const<unnamed>::TSortedArray&, const<unnamed>::TId2IdMap&)' VISU_MergeFilter.cxx: In function 'void<unnamed>::CopyField(vtkDataSetAttributes*, const char*, vtkDataSetAttributes*, vtkIdType)': VISU_MergeFilter.cxx:427: error: cannot convert 'int (vtkFieldData::*)(vtkAbstractArray*)' to 'int (vtkDataSetAttributes::*)(vtkDataArray*)' for argument '3' to 'void<unnamed>::CopyArray(vtkDataArray*, vtkDataSetAttributes*, int (vtkDataSetAttributes::*)(vtkDataArray*), vtkIdType)' make[3]: *** [VISU_MergeFilter.lo] Erreur 1 make[3]: quittant le répertoire « /var/tmp/portage/sci-misc/salome-visu-3.2.6/work/src3.2.6/VISU_SRC_3.2.6/src/CONVERTOR » make[2]: *** [lib_CONVERTOR] Erreur 2 make[2]: quittant le répertoire « /var/tmp/portage/sci-misc/salome-visu-3.2.6/work/src3.2.6/VISU_SRC_3.2.6/src » make[1]: *** [lib_src] Erreur 2 make[1]: quittant le répertoire « /var/tmp/portage/sci-misc/salome-visu-3.2.6/work/src3.2.6/VISU_SRC_3.2.6 » make: *** [all] Erreur 2 ----------------------------------------------------------------- I use python 2.5, omniorbpy 3 et omniORB 4.1.2. But, I have the same problem with omniorbpy 3.3 et omniORB 4.1.3. Any idea on this one? Herve Darce ----------------------------------------------------------------- ----------------------------------------------------------------- emerge --info Portage 2.1.4.5 (default/linux/x86/2008.0/desktop, gcc-4.1.2, glibc-2.6.1-r0, 2.6.25-gentoo-r9 i686) ================================================================= System uname: 2.6.25-gentoo-r9 i686 Intel(R) Pentium(R) M processor 1.73GHz Timestamp of tree: Sat, 29 Nov 2008 20:45:01 +0000 ccache version 2.4 [disabled] app-shells/bash: 3.2_p33 dev-java/java-config: 1.3.7, 2.1.6 dev-lang/python: 2.4.4-r14, 2.5.2-r7 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r7 dev-util/cmake: 2.4.6-r1 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r2 sys-devel/automake: 1.4_p6, 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1-r1 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=i686 -pipe" CHOST="i686-pc-linux-gnu"
I resolved my problem. I use vtk-5.0 instead of vtk-5.2. There is a bug with vtk-5.2. python 2.5.2 omniorbpy 3.3 omniORB 4.1.3 vtk 5.0.4 Herve Darce ----------------------------------------------------------------- ----------------------------------------------------------------- emerge --info Portage 2.1.4.5 (default/linux/x86/2008.0/desktop, gcc-4.1.2, glibc-2.6.1-r0, 2.6.25-gentoo-r9 i686) ================================================================= System uname: 2.6.25-gentoo-r9 i686 Intel(R) Pentium(R) M processor 1.73GHz Timestamp of tree: Sat, 29 Nov 2008 20:45:01 +0000 ccache version 2.4 [disabled] app-shells/bash: 3.2_p33 dev-java/java-config: 1.3.7, 2.1.6 dev-lang/python: 2.4.4-r14, 2.5.2-r7 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r7 dev-util/cmake: 2.4.6-r1 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r2 sys-devel/automake: 1.4_p6, 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1-r1 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=i686 -pipe" CHOST="i686-pc-linux-gnu"
(In reply to comment #448) > I resolved my problem. I use vtk-5.0 instead of vtk-5.2. There is a bug with > vtk-5.2. > > python 2.5.2 > omniorbpy 3.3 > omniORB 4.1.3 > vtk 5.0.4 > > Herve Darce > > ----------------------------------------------------------------- > ----------------------------------------------------------------- > emerge --info > Portage 2.1.4.5 (default/linux/x86/2008.0/desktop, gcc-4.1.2, glibc-2.6.1-r0, > 2.6.25-gentoo-r9 i686) > ================================================================= > System uname: 2.6.25-gentoo-r9 i686 Intel(R) Pentium(R) M processor 1.73GHz > Timestamp of tree: Sat, 29 Nov 2008 20:45:01 +0000 > ccache version 2.4 [disabled] > app-shells/bash: 3.2_p33 > dev-java/java-config: 1.3.7, 2.1.6 > dev-lang/python: 2.4.4-r14, 2.5.2-r7 > dev-python/pycrypto: 2.0.1-r6 > dev-util/ccache: 2.4-r7 > dev-util/cmake: 2.4.6-r1 > sys-apps/baselayout: 1.12.11.1 > sys-apps/sandbox: 1.2.18.1-r2 > sys-devel/autoconf: 2.13, 2.61-r2 > sys-devel/automake: 1.4_p6, 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1-r1 > sys-devel/binutils: 2.18-r3 > sys-devel/gcc-config: 1.4.0-r4 > sys-devel/libtool: 1.5.26 > virtual/os-headers: 2.6.23-r3 > ACCEPT_KEYWORDS="x86" > CBUILD="i686-pc-linux-gnu" > CFLAGS="-O2 -march=i686 -pipe" > CHOST="i686-pc-linux-gnu" > You're right salome-visu still needs a patch for vtk-5.2 because vtk-5.2 introduced a new Array superclass, vtkAbstractArray and changed int AddArray(vtkDataArray *array); to int AddArray(vtkAbstractArray *array);
Created attachment 178432 [details] Preliminary ebuild - doesn't work Finally a new Version of salome has been released: http://www.salome-platform.org/download/dl414/ This a first try of an ebuild, which compiles but fails to install: /usr/bin/install -c -m 644 'LocalTraceBufferPool.hxx' '/home/tmp/portage/sci-misc/salome-kernel-4.1.4/image///opt/salome-4.1.4/KERNEL/include/salome/LocalTraceBufferPool.hxx' /usr/bin/install -c -m 644 'BaseTraceCollector.hxx' '/home/tmp/portage/sci-misc/salome-kernel-4.1.4/image///opt/salome-4.1.4/KERNEL/include/salome/BaseTraceCollector.hxx' /usr/bin/install -c -m 644 'SALOME_LocalTrace.hxx' '/home/tmp/portage/sci-misc/salome-kernel-4.1.4/image///opt/salome-4.1.4/KERNEL/include/salome/SALOME_LocalTrace.hxx' libtool: install: error: cannot install `libSALOMELocalTrace.la' to a directory not ending in /opt/salome-4.1.4/KERNEL/lib/salome make[3]: *** [install-libLTLIBRARIES] Fehler 1 make[3]: Leaving directory `/home/tmp/portage/sci-misc/salome-kernel-4.1.4/work/src4.1.4/KERNEL_SRC_4.1.4/src/SALOMELocalTrace' make[2]: *** [install-am] Fehler 2 make[2]: Leaving directory `/home/tmp/portage/sci-misc/salome-kernel-4.1.4/work/src4.1.4/KERNEL_SRC_4.1.4/src/SALOMELocalTrace' make[1]: *** [install-recursive] Fehler 1 make[1]: Leaving directory `/home/tmp/portage/sci-misc/salome-kernel-4.1.4/work/src4.1.4/KERNEL_SRC_4.1.4/src' make: *** [install-recursive] Fehler 1 * * ERROR: sci-misc/salome-kernel-4.1.4 failed. * Call stack: * ebuild.sh, line 49: Called src_install * environment, line 3590: Called die * The specific snippet of code: * emake prefix="${D}/${INSTALL_DIR}" docdir="${D}/${INSTALL_DIR}/share/doc/salome" infodir="${D}/${INSTALL_DIR}/share/info" datadir="${D}/${INSTALL_DIR}/share/salome" libdir="${D}/${INSTALL_DIR}/$(get_libdir)/salome" pythondir="${D}/${INSTALL_DIR}/$(get_libdir)/python${PYVER}/site-packages" install || die "emake install failed"; * The die message: * emake install failed * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/home/tmp/portage/sci-misc/salome-kernel-4.1.4/temp/build.log'. * The ebuild environment file is located at '/home/tmp/portage/sci-misc/salome-kernel-4.1.4/temp/environment'. * >>> Failed to emerge sci-misc/salome-kernel-4.1.4, Log file:
Created attachment 178434 [details] Patch for Python 2.5
The install error seems to occure because the lib -> lib64 symlink is missing in the image directory: $ ls ./portage/sci-misc/salome-kernel-4.1.4/image/opt/salome-4.1.4/KERNEL/ $ idl include lib64 salome_adm
Bart, From what I read, salome 4.1.4 requires opencascade 6.3. I have tried to update the 6.2 ebuild (see http://bugs.gentoo.org/show_bug.cgi?id=118656) but I have installation path / sandbox issues. Daniel
At least the KERNEL Module seems to compile fine with opencascade 6.2. Regarding the install error I saw the following in the build.log ./configure --prefix=/usr --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --prefix=/opt/salome-4.1.4/KERNEL --docdir=/opt/salome-4.1.4/KERNEL/share/doc/salome --infodir=/opt/salome-4.1.4/KERNEL/share/info --datadir=/opt/salome-4.1.4/KERNEL/share/salome --libdir=/opt/salome-4.1.4/KERNEL/lib64/salome --with-python-site=/opt/salome-4.1.4/KERNEL/lib64/python2.5/site-packages/salome --with-python-site-exec=/opt/salome-4.1.4/KERNEL/lib64/python2.5/site-packages/salome --enable-corba-gen --with-tcl=/usr/lib64/ --with-tk=/usr/lib64/ --disable-debug --enable-production --without-cppunit --with-opengl=/usr --build=x86_64-pc-linux-gnu --prefix and other Options are used twice which probably leads to confusion.
(In reply to comment #454) Regarding the specification of the prefix and other paths, these had been a major difficulty (read sandbox violation) when we created the ebuilds for Salome 3.2.6. What you see in the log might indeed be a source of confusion. However, it was already like this for 3.2.6. OpenCascade 6.3 is causing me headaches for the same kind of reasons (when 6.2 did not...). So, I wonder. Something seems to be a little bit different, but what? Daniel > At least the KERNEL Module seems to compile fine with opencascade 6.2. > > Regarding the install error I saw the following in the build.log > > ./configure --prefix=/usr --host=x86_64-pc-linux-gnu --mandir=/usr/share/man > --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc > --localstatedir=/var/lib --prefix=/opt/salome-4.1.4/KERNEL > --docdir=/opt/salome-4.1.4/KERNEL/share/doc/salome > --infodir=/opt/salome-4.1.4/KERNEL/share/info > --datadir=/opt/salome-4.1.4/KERNEL/share/salome > --libdir=/opt/salome-4.1.4/KERNEL/lib64/salome > --with-python-site=/opt/salome-4.1.4/KERNEL/lib64/python2.5/site-packages/salome > --with-python-site-exec=/opt/salome-4.1.4/KERNEL/lib64/python2.5/site-packages/salome > --enable-corba-gen --with-tcl=/usr/lib64/ --with-tk=/usr/lib64/ --disable-debug > --enable-production --without-cppunit --with-opengl=/usr > --build=x86_64-pc-linux-gnu > --prefix and other Options are used twice which probably leads to confusion. >
The configure script doesn't respect the --libdir Parameter, if one configures with ./configure --libdir=/opt/salome-4.1.4/KERNEL/lib64/salome libdir is set to libdir = $(prefix)/lib/salome in most Makefiles, with the exception of ./salome_adm/Makefile ./src/DSC/Makefile ./src/Makefile
Created attachment 178739 [details] Next try This ebuild installs the salome libs to /opt/salome-4.1.4/KERNEL/lib/salome and the python file to /opt/salome-4.1.4/KERNEL/lib64/python2.5. I removed the opengl USE flag as --with-opengl isn't use by the KERNEL anymore.
Created attachment 179160 [details, diff] Patch for compilation with gcc-4.3
Created attachment 179161 [details, diff] Patch for Python 2.5
Created attachment 179162 [details] At least it works ... This ebuild has the same "feature" as the kernel ebuild: The salome libs go to /opt/salome-4.1.4/GUI/lib, the python files to /opt/salome-4.1.4/GUI/lib64 salome.
Created attachment 179237 [details] Proposed ebuild Installation works with the same lib/lib64 issue as above.
Created attachment 179627 [details] Ebuild fixed a qwt problem and remove a few unknown configure options
Created attachment 179628 [details, diff] patch for qwt4 With this patch (which is basically the same as the 3.2.6 patch) the Gui starts. It's still not working but that is probably because other salome modules are still missing.
Tried an install w/ vtk-5.0. The salome-gui-vtk-5.0.patch needs to be renamed to salome-gui-3.2.6-vtk-5.0.patch
Created attachment 183321 [details, diff] patch for boost 1.35
Created attachment 183323 [details] Patch for compilation with gcc-4.3
Created attachment 183324 [details, diff] Patch for compilation with hdf5-1.6.7
Created attachment 183325 [details, diff] some med fixes
Created attachment 183327 [details, diff] typecasting madness, probably only required on amd64
Created attachment 183329 [details] Proposed ebuild Now that opencascade-6.3 installs, salome-4.1.4 should be work without further problems. The dependencies of the ebuilds still need to be adjusted to opencascade-6.3.
Created attachment 183347 [details, diff] Patch for compilation with gcc-4.3
Created attachment 183348 [details] ebuild for patch above
Hello, there's a small error in the salome-gui ebuild. The ebuild is looking for 'salome-gui-3.2.6-vtk-5.0.patch' file as the provided file is named 'salome-gui-vtk-5.0.patch' Etienne.
Hello, I've got problems in compiling salome-smesh-3.2.6 from the science overlay with gcc-4.3.2-r3 on amd64. The output is: make[3]: Entering directory `/var/tmp/portage/sci-misc/salome-smesh-3.2.6/work/src3.2.6/SMESH_SRC_3.2.6/src/SMESH_I' /usr/bin/omniidl -bcxx -nf -I/usr/idl -I../../idl -I../../idl/salome -I/opt/salome-3.2.6/KERNEL/idl/salome -I/opt/salome-3.2.6/GEOM/idl/salome -I/opt/salome-3.2.6/MED/idl/salome -nf -I/usr/idl /opt/salome-3.2.6/KERNEL/idl/salome/SALOMEDS.idl omniidl: Could not import back-end 'cxx' omniidl: Maybe you need to use the -p option? omniidl: (The error was 'No module named cxx') I don't think it is an option to find this error, because a new set of ebuilds were published here. Is somebody of the contributers able to push all these new ebuilds to the science overlay?
(In reply to comment #474) > Hello, > > I've got problems in compiling salome-smesh-3.2.6 from the science overlay with > gcc-4.3.2-r3 on amd64. The output is: > > make[3]: Entering directory > `/var/tmp/portage/sci-misc/salome-smesh-3.2.6/work/src3.2.6/SMESH_SRC_3.2.6/src/SMESH_I' > /usr/bin/omniidl -bcxx -nf -I/usr/idl -I../../idl -I../../idl/salome > -I/opt/salome-3.2.6/KERNEL/idl/salome -I/opt/salome-3.2.6/GEOM/idl/salome > -I/opt/salome-3.2.6/MED/idl/salome > -nf -I/usr/idl /opt/salome-3.2.6/KERNEL/idl/salome/SALOMEDS.idl > omniidl: Could not import back-end 'cxx' > omniidl: Maybe you need to use the -p option? > omniidl: (The error was 'No module named cxx') > > I don't think it is an option to find this error, because a new set of ebuilds > were published here. Is somebody of the contributers able to push all these new > ebuilds to the science overlay? > Seems to be an omniORB problem. Did you upgrade your gcc recently? Did you already run revdep-rebuild? Try re-emerging omniORB.
(In reply to comment #475) > Seems to be an omniORB problem. Did you upgrade your gcc recently? Did you > already run revdep-rebuild? Try re-emerging omniORB. Yes I have updated to the new stable gcc and have also done an revdep-rebuild. The problem was solved by a manual reinstall of omniORB and afterwards doing again revdep-rebuild. Thank you very much.
(In reply to comment #474) > Hello, > > I've got problems in compiling salome-smesh-3.2.6 from the science overlay with > gcc-4.3.2-r3 on amd64. The output is: > > make[3]: Entering directory > `/var/tmp/portage/sci-misc/salome-smesh-3.2.6/work/src3.2.6/SMESH_SRC_3.2.6/src/SMESH_I' > /usr/bin/omniidl -bcxx -nf -I/usr/idl -I../../idl -I../../idl/salome > -I/opt/salome-3.2.6/KERNEL/idl/salome -I/opt/salome-3.2.6/GEOM/idl/salome > -I/opt/salome-3.2.6/MED/idl/salome > -nf -I/usr/idl /opt/salome-3.2.6/KERNEL/idl/salome/SALOMEDS.idl > omniidl: Could not import back-end 'cxx' > omniidl: Maybe you need to use the -p option? > omniidl: (The error was 'No module named cxx') > > I don't think it is an option to find this error, because a new set of ebuilds > were published here. Is somebody of the contributers able to push all these new > ebuilds to the science overlay? > Had the same problem emerging salome-kernel 4.1.4. But after a python-update ++ and emerge omniORB omniorbpy the problem is solved (on my amd64 for salome-kernel). The salome-gui package is (as mentioned above) incompatible with the vtk-5.2; does someone own a patch for this? Are there ebuilds for the remaining salome packages?
Created attachment 189058 [details, diff] Patch for QWT_INCLUDES compilation error QWT_INCLUDES lack the "-I", leading to compilation errors
Created attachment 189059 [details, diff] Patch for linking library TOOLSDS
Created attachment 189061 [details, diff] Patch for location of libraries missing
I have just uploaded several patches I needed to compile salome 3.2.6 with gcc-4.3.3.
(In reply to comment #0) > SALOME is a free software that provides a generic platform for Pre and > Post-Processing for numerical simulation. It is based on an open and flexible > architecture made of reusable components available as free software. > It is open-source (LGPL), and you can download both the sourcecode and the > executables from this site. > > Salome Platform: > > * Supports interoperability between CAD modeling and computation software > (CAD-CAE link) > * Makes easier the integration of new components on heterogeneous systems > for numerical computation > * Sets the priority to multi-physics coupling between computation software > * Provides a generic user interface, user-friendly and efficient, which > helps to reduce the costs and delays of carrying out the studies > * Reduces training time to the specific time for learning the software > solution which has been based on this platform > * All functionalities are accessible through the programmatic integrated > Python console > (In reply to comment #481) > I have just uploaded several patches I needed to compile salome 3.2.6 with > gcc-4.3.3. >
Hello, it seems that med-2.3.1 does not exist anymore >>> Emerging (1 of 15) sci-libs/med-2.3.1 from science 000022 >>> Downloading 'ftp://ftp.unina.it/pub/linux/distributions/gentoo/distfiles/med-2.3.1.tar.gz' 000023 --2009-06-08 22:28:40-- ftp://ftp.unina.it/pub/linux/distributions/gentoo/distfiles/med-2.3.1.tar.gz 000024 => `/usr/portage/distfiles/med-2.3.1.tar.gz' 000025 Auflsen des Hostnamen ftp.unina.it.... 192.132.34.17 000026 Verbindungsaufbau zu ftp.unina.it|192.132.34.17|:21... verbunden. 000027 Anmelden als anonymous ... Angemeldet! 000028 ==> SYST ... fertig. ==> PWD ... fertig. 000029 ==> TYPE I ... fertig. ==> CWD /pub/linux/distributions/gentoo/distfiles ... fertig. 000030 ==> SIZE med-2.3.1.tar.gz ... fertig. 000031 ==> PASV ... fertig. ==> RETR med-2.3.1.tar.gz ... 000032 Die Datei med-2.3.1.tar.gz gibt es nicht. 000033 000034 >>> Downloading 'http://131.188.12.212/pub/mirrors/gentoo/distfiles/med-2.3.1.tar.gz' 000035 --2009-06-08 22:28:41-- http://131.188.12.212/pub/mirrors/gentoo/distfiles/med-2.3.1.tar.gz 000036 Verbindungsaufbau zu 131.188.12.212:80... verbunden. 000037 HTTP Anforderung gesendet, warte auf Antwort... 404 Not Found 000038 2009-06-08 22:28:41 FEHLER 404: Not Found. 000039 000040 >>> Downloading 'ftp://ftp.uni-erlangen.de/pub/mirrors/gentoo/distfiles/med-2.3.1.tar.gz' 000041 --2009-06-08 22:28:41-- ftp://ftp.uni-erlangen.de/pub/mirrors/gentoo/distfiles/med-2.3.1.tar.gz 000042 => `/usr/portage/distfiles/med-2.3.1.tar.gz' 000043 Auflsen des Hostnamen ftp.uni-erlangen.de.... 131.188.12.212, 2001:638:a00:143::3 000044 Verbindungsaufbau zu ftp.uni-erlangen.de|131.188.12.212|:21... verbunden. 000045 Anmelden als anonymous ... Angemeldet! 000046 ==> SYST ... fertig. ==> PWD ... fertig. 000047 ==> TYPE I ... fertig. ==> CWD /pub/mirrors/gentoo/distfiles ... fertig. 000048 ==> SIZE med-2.3.1.tar.gz ... fertig. 000049 ==> PASV ... fertig. ==> RETR med-2.3.1.tar.gz ... 000050 Die Datei med-2.3.1.tar.gz gibt es nicht. 000051 000052 >>> Downloading 'http://www.code-aster.org/V2/UPLOAD/DOC/Telechargement/med-2.3.1.tar.gz' 000053 --2009-06-08 22:28:43-- http://www.code-aster.org/V2/UPLOAD/DOC/Telechargement/med-2.3.1.tar.gz 000054 Auflsen des Hostnamen www.code-aster.org.... 192.196.91.17 000055 Verbindungsaufbau zu www.code-aster.org|192.196.91.17|:80... verbunden. 000056 HTTP Anforderung gesendet, warte auf Antwort... 404 Not Found 000057 2009-06-08 22:28:43 FEHLER 404: Not Found. 000058 000059 !!! Couldn't download 'med-2.3.1.tar.gz'. Aborting. 000060 * Fetch failed for 'sci-libs/med-2.3.1', Log file: 000061 * '/var/tmp/portage/sci-libs/med-2.3.1/temp/build.log' 000062 000063 >>> Failed to emerge sci-libs/med-2.3.1, Log file: 000064 000065 >>> '/var/tmp/portage/sci-libs/med-2.3.1/temp/build.log' 000066 000067 * Messages for package sci-libs/med-2.3.1: 000068 000069 * Fetch failed for 'sci-libs/med-2.3.1', Log file: 000070 * '/var/tmp/portage/sci-libs/med-2.3.1/temp/build.log' Thanks Roland
Just curious as to whether the salome-gui-3.2.6_qwt-4.patch still does what it's supposed to do. I did a fresh install of salome-smesh which pulled in the kernel, gui, med and geom with no apparent problems. A revdep-rebuild -i -p yielded: * Configuring search environment for revdep-rebuild * Checking reverse dependencies * Packages containing binaries and libraries broken by a package update * will be emerged. * Collecting system binaries and libraries * Generated new 1_files.rr * Collecting complete LD_LIBRARY_PATH * Generated new 2_ldpath.rr * Checking dynamic linking consistency [ 8% ] * broken /opt/salome-3.2.6/GUI/lib64/salome/libPlot2d.la (requires -l:libqwt.so.4) * broken /opt/salome-3.2.6/GUI/lib64/salome/libSPlot2d.la (requires -l:libqwt.so.4) * broken /opt/salome-3.2.6/GUI/lib64/salome/libSVTK.la (requires -l:libqwt.so.4) [ 12% ] * broken /opt/salome-3.2.6/SMESH/lib64/salome/libStdMeshersGUI.la (requires -l:libqwt.so.4) [ 100% ] * Generated new 3_broken.rr * Assigning files to packages * /opt/salome-3.2.6/GUI/lib64/salome/libPlot2d.la -> sci-misc/salome-gui * /opt/salome-3.2.6/GUI/lib64/salome/libSPlot2d.la -> sci-misc/salome-gui * /opt/salome-3.2.6/GUI/lib64/salome/libSVTK.la -> sci-misc/salome-gui * /opt/salome-3.2.6/SMESH/lib64/salome/libStdMeshersGUI.la -> sci-misc/salome-smesh * Generated new 4_raw.rr and 4_owners.rr * Cleaning list of packages to rebuild * Generated new 4_pkgs.rr * Assigning packages to ebuilds * Generated new 4_ebuilds.rr * Evaluating package order * Generated new 5_order.rr * All prepared. Starting rebuild emerge --oneshot --pretend sci-misc/salome-gui:0 sci-misc/salome-smesh:0 Running revdep-rebuild without the -p resolves nothing. The libtool library files all contain -l:libqwt.so.4 which seems to be the problem. The qwt libraries are installed, locate libqwt.so.4 gives: /usr/lib64/libqwt.so.4 /usr/lib64/libqwt.so.4.2 /usr/lib64/libqwt.so.4.2.0 and they do appear to be properly linked. Is revdep-rebuild correctly reporting things?
Created attachment 200799 [details] New Release The Sourcecode for the Salome 5.1.2 has to be extracted from the Salome 5.1.2 Installer Instructions: Download an InstallWizard*.tar.gz from http://www.salome-platform.org/download/dl512/ (you have to register to download) Theoretically it would be possible to use http://files.opencascade.com/Salome/Salome5.1.2/src5.1.2.tar.gz but you'd have to download the Installer anyway because of the new version of opencascade required unpack the InstallWizard*tar.gz and you'll find the sources in /InstallWizard*/Products/SOURCES copy KERNELsourcesV5.1.2 to DISTDIR
Created attachment 200800 [details] patch which fixes the lib/lib64 Directories on amd64
Created attachment 200802 [details] New Release The Sourcecode for the Salome 5.1.2 has to be extracted from the Salome 5.1.2 Installer Instructions: Download an InstallWizard*.tar.gz from http://www.salome-platform.org/download/dl512/ (you have to register to download) Theoretically it would be possible to use http://files.opencascade.com/Salome/Salome5.1.2/src5.1.2.tar.gz but you'd have to download the Installer anyway because of the new version of opencascade required unpack the InstallWizard*tar.gz and you'll find the sources in /InstallWizard*/Products/SOURCES copy GUIsourcesV5.1.2 to DISTDIR
Created attachment 200803 [details] patch for location of qt4 libraries
Created attachment 200805 [details] New Release The Sourcecode for the Salome 5.1.2 has to be extracted from the Salome 5.1.2 Installer Instructions: Download an InstallWizard*.tar.gz from http://www.salome-platform.org/download/dl512/ (you have to register to download) Theoretically it would be possible to use http://files.opencascade.com/Salome/Salome5.1.2/src5.1.2.tar.gz but you'd have to download the Installer anyway because of the new version of opencascade required unpack the InstallWizard*tar.gz and you'll find the sources in /InstallWizard*/Products/SOURCES copy GEOMsourcesV5.1.2 to DISTDIR
Created attachment 200807 [details] patch for location of qt4 libraries
Created attachment 200809 [details] New Release The Sourcecode for the Salome 5.1.2 has to be extracted from the Salome 5.1.2 Installer Instructions: Download an InstallWizard*.tar.gz from http://www.salome-platform.org/download/dl512/ (you have to register to download) Theoretically it would be possible to use http://files.opencascade.com/Salome/Salome5.1.2/src5.1.2.tar.gz but you'd have to download the Installer anyway because of the new version of opencascade required unpack the InstallWizard*tar.gz and you'll find the sources in /InstallWizard*/Products/SOURCES copy COMPONENTsourcesV5.1.2 to DISTDIR
Created attachment 200811 [details] New Release The Sourcecode for the Salome 5.1.2 has to be extracted from the Salome 5.1.2 Installer Instructions: Download an InstallWizard*.tar.gz from http://www.salome-platform.org/download/dl512/ (you have to register to download) Theoretically it would be possible to use http://files.opencascade.com/Salome/Salome5.1.2/src5.1.2.tar.gz but you'd have to download the Installer anyway because of the new version of opencascade required unpack the InstallWizard*tar.gz and you'll find the sources in /InstallWizard*/Products/SOURCES copy MEDsourcesV5.1.2 to DISTDIR Warning: This also requires sci-libs/med-2.3.5
Created attachment 200812 [details, diff] patch for location of qt4 libraries
Created attachment 200813 [details, diff] some patch
Created attachment 200815 [details, diff] ugly patch
Created attachment 200816 [details] New Release The Sourcecode for the Salome 5.1.2 has to be extracted from the Salome 5.1.2 Installer Instructions: Download an InstallWizard*.tar.gz from http://www.salome-platform.org/download/dl512/ (you have to register to download) Theoretically it would be possible to use http://files.opencascade.com/Salome/Salome5.1.2/src5.1.2.tar.gz but you'd have to download the Installer anyway because of the new version of opencascade required unpack the InstallWizard*tar.gz and you'll find the sources in /InstallWizard*/Products/SOURCES copy PYCALCULATORsourcesV5.1.2 to DISTDIR
Created attachment 200818 [details] New Release The Sourcecode for the Salome 5.1.2 has to be extracted from the Salome 5.1.2 Installer Instructions: Download an InstallWizard*.tar.gz from http://www.salome-platform.org/download/dl512/ (you have to register to download) Theoretically it would be possible to use http://files.opencascade.com/Salome/Salome5.1.2/src5.1.2.tar.gz but you'd have to download the Installer anyway because of the new version of opencascade required unpack the InstallWizard*tar.gz and you'll find the sources in /InstallWizard*/Products/SOURCES copy SMESHsourcesV5.1.2 to DISTDIR
Created attachment 200820 [details] New Release
(In reply to comment #498) > Created an attachment (id=200820) [edit] > New Release > The Sourcecode for the Salome 5.1.2 has to be extracted from the Salome 5.1.2 Installer Instructions: Download an InstallWizard*.tar.gz from http://www.salome-platform.org/download/dl512/ (you have to register to download) Theoretically it would be possible to use http://files.opencascade.com/Salome/Salome5.1.2/src5.1.2.tar.gz but you'd have to download the Installer anyway because of the new version of opencascade required unpack the InstallWizard*tar.gz and you'll find the sources in /InstallWizard*/Products/SOURCES copy VISUsourcesV5.1.2 to DISTDIR
Created attachment 200821 [details] New Release - this is a replacement for the superv module The Sourcecode for the Salome 5.1.2 has to be extracted from the Salome 5.1.2 Installer Instructions: Download an InstallWizard*.tar.gz from http://www.salome-platform.org/download/dl512/ (you have to register to download) Theoretically it would be possible to use http://files.opencascade.com/Salome/Salome5.1.2/src5.1.2.tar.gz but you'd have to download the Installer anyway because of the new version of opencascade required unpack the InstallWizard*tar.gz and you'll find the sources in /InstallWizard*/Products/SOURCES copy YACSsourcesV5.1.2 to DISTDIR
Created attachment 200823 [details, diff] patch which fixes the lib/lib64 Directories on amd64
Created attachment 200825 [details, diff] patch for location of python libraries
The new Salome version requires Opencascade 6.3 Service Pack 6: http://bugs.gentoo.org/118656
Good news, Salome 5.1.2 seems to work with boost-1.39.0.
(In reply to comment #492) > Created an attachment (id=200811) [edit] > New Release > > The Sourcecode for the Salome 5.1.2 has to be extracted from > the Salome 5.1.2 Installer > Instructions: > Download an InstallWizard*.tar.gz from > http://www.salome-platform.org/download/dl512/ > (you have to register to download) > Theoretically it would be possible to use > http://files.opencascade.com/Salome/Salome5.1.2/src5.1.2.tar.gz > but you'd have to download the Installer anyway because of the new version of > opencascade required > unpack the InstallWizard*tar.gz and you'll find the sources in > /InstallWizard*/Products/SOURCES > copy MEDsourcesV5.1.2 to DISTDIR > > Warning: This also requires sci-libs/med-2.3.5 > The sources for sci-libs/med-2.3.5 can be downloaded from: http://files.opencascade.com/Salome/Salome5.1.2/med-fichier_2.3.5.tar.gz The InstallWizards from: http://files.opencascade.com/Salome/Salome5.1.2/InstallWizard_5.1.2_Debian_4.0.tar.gz If you want another InstallWizard just use the links of the md5sum's without the ".md5" extensions.
(In reply to comment #485) > Created an attachment (id=200799) [edit] > New Release > > The Sourcecode for the Salome 5.1.2 has to be extracted from > the Salome 5.1.2 Installer > Instructions: > Download an InstallWizard*.tar.gz from > http://www.salome-platform.org/download/dl512/ > (you have to register to download) > Theoretically it would be possible to use > http://files.opencascade.com/Salome/Salome5.1.2/src5.1.2.tar.gz > but you'd have to download the Installer anyway because of the new version of > opencascade required > unpack the InstallWizard*tar.gz and you'll find the sources in > /InstallWizard*/Products/SOURCES > copy KERNELsourcesV5.1.2 to DISTDIR > Hello Bert, thank you for preparing the ebuilds and patches for salome-5.1.2. Can you please push these ebuilds also to the science overlay? At the moment salome-3.2.6 is in the overlay and regarding to comment #484, it fails to build from sources. Thank you very much, Oliver
> thank you for preparing the ebuilds and patches for salome-5.1.2. Can you > please push these ebuilds also to the science overlay? Sorry, but I don't have write access to the science overlay.
To get write access to the science overlay, please contact Sébastien Fabbro <bicatali@gentoo.org>, he will probably be very happy to help you with this matter. Daniel
(In reply to comment #507) > Sorry, but I don't have write access to the science overlay. > Just ask on the IRC channel #gentoo-science, if you can get write access to the git, because you want to update the salome ebuilds. There is also a thread on the science mailing list, how to work with the git overlay ("overlay move to git"): http://news.gmane.org/gmane.linux.gentoo.science/ Furthermore you can also, refer to: http://git.overlays.gentoo.org/ and/or to the old TRAC pages at: http://overlays.gentoo.org/proj/science/wiki/en At the moment, there is no quick HOWTO get write access to the science overlay.
Hello, @Bert: I'm trying to test the different salome versions before pushing them to the science overlay. For salome 3.2.6, salome-gui-3.2.6-r1 is searching for salome-gui-3.2.6_pyobject.patch which is not uploaded here. Do you still have it? I've not finished to test salome4 and salome5 ebuilds, but the meta ebuilds are missing. It would be great if you can join the IRC channel to talk about OCC and salome ebuilds. Regards, Etienne.
Created attachment 204604 [details] Missing patch
Created attachment 204699 [details] non working patch
Created attachment 204980 [details] patch which allows compilation
Created attachment 205339 [details] patch which allows compilation with >=vtk-5.2 This patch just replaces RenderTranslucentGeometry by RenderVolumetricGeometry (no use is made of RenderTranlucentPolygonalGeometry or HasTranslucentPolygonalGeometry)
Bert: Could you please come in to the gentoo-science and gentoo-overlays channels on irc.freenode.org and talk to me (weaver)? I will assist you in getting overlay access, if you have not already been in touch with bicatali. Thanks for contributing.
(In reply to comment #514) > Created an attachment (id=205339) [details] > patch which allows compilation with >=vtk-5.2 > > This patch just replaces RenderTranslucentGeometry by RenderVolumetricGeometry > (no use is made of RenderTranlucentPolygonalGeometry or > HasTranslucentPolygonalGeometry) > hi, i'm and openSUSE packager and i'm using your patch.. i'm afraid it's not complete. compilation now succeded but linking fail, i already try to remove the as-needed option, but i get this: libtool: link: g++ -fomit-frame-pointer -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -D_DEBUG_ -g -pthread -Wl,-enable-new-dtags -o .libs/VISUConvertor VISUConvertor-VISUConvertor.o -L/usr/lib -L/usr/lib/vtk -L/usr/X11R6/lib -L/opt/OpenCASCADE//Linux/lib -L/opt/SALOME/lib/salome ./.libs/libVisuConvertor.so /opt/OpenCASCADE/lib/libTKMath.so /opt/SALOME/lib/salome/libMEDWrapper.so /opt/SALOME/lib/salome/libMEDWrapper_V2_2.so /usr/lib/libmed.so /usr/lib/libmedimportcxx.so -lgfortranbegin -lgfortran /opt/SALOME/lib/salome/libMEDWrapper_V2_1.so /opt/SALOME/lib/salome/libmed_V2_1.so -lhdf5 /opt/SALOME/lib/salome/libMEDWrapperBase.so -lboost_thread-mt /opt/SALOME/lib/salome/libVTKViewer.so -lvtkCommon -lvtkGraphics -lvtkImaging -lvtkFiltering -lvtkIO -lvtkRendering -lvtkHybrid -lvtkParallel -lvtkWidgets -lXt /opt/OpenCASCADE/lib/libTKernel.so /opt/SALOME/lib/salome/libsuit.so /opt/SALOME/lib/salome/libObjBrowser.so /opt/SALOME/lib/salome/libqtx.so /usr/lib/libQtXml.so /usr/lib/libQtOpenGL.so -lGLU -lGL /usr/lib/libQtGui.so -lpng /usr/lib/libfreetype.so -lSM -lICE -lXrender -lXrandr -lXfixes -lXcursor -lXinerama -lfontconfig -lXext -lX11 /usr/lib/libQtCore.so -lz -lgthread-2.0 -lrt -lglib-2.0 -lpthread -lnsl -lm -ldl -pthread -Wl,-rpath -Wl,/opt/SALOME/lib/salome ./.libs/libVisuConvertor.so: undefined reference to `vtkIntArray* VISU::GetIDMapper<VISU::TGetPointData>(VISU::TFieldList*, VISU::TGetPointData, char const*)' collect2: ld returned 1 exit status make[2]: *** [VISUConvertor] Error 1 make[2]: Leaving directory `/usr/src/packages/BUILD/VISU_SRC_5.1.2/src/CONVERTOR' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/packages/BUILD/VISU_SRC_5.1.2/src' make: *** [all-recursive] Error 1
Hello, I've just pushed salome-5.1.3 ebuilds in the science overlay. The upstream solved problems related to >vtk-5.0. I've tested them on x86 and amd64 and it seems to work fine (and really more robust than older salome versions). I have not tested MPI through Mpich2 implementation nor metis support for salome-med (collision with parmetis...), so these points have still to be tested. I haven't been able been able to find anything to compile it with PBS support, so I removed it, but I can be wrong, if someone can see something I've not noticed... I've removed most of parallel build restrictions (it's a pain to test all these ebuilds knowing that I have a quad-core...). I just add restrictions when I notice a problem related to parallel build. If you are faced to a compilation error, try to use -j1 (and please report it if it's effectively a parallel build problem). I've cleaned many things in these ebuilds, I hope I've not introduced too much errors. I'm pretty sure there are still missing or useless dependencies. I have also packaged other components such as light, pylight, multipr, are they really usefull, should I push them in the overlay? The most usefull component would be netgenplugin, but I think we need to package netgen-4.5 before. Enjoy ;) Etienne.
i've got problem compiling salome-med on amd64: libtool: compile: x86_64-pc-linux-gnu-g++ "-DPACKAGE_NAME=\"Salome2 Project MED module\"" -DPACKAGE_TARNAME=\"SalomeMED\" -DPACKAGE_VERSION=\"5.1.3\" "-DPACKAGE_STRING=\"Salome2 Project MED module 5.1.3\"" -DPACKAGE_BUGREPORT=\"webmaster.salome@opencascade.com\" -DPACKAGE=\"SalomeMED\" -DVERSION=\"5.1.3\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_LIBDL=1 -DHAVE_LIBRT=1 -DHAVE_LIBM=1 "-DHAVE_NAMESPACES=/**/" -DHAVE_PTHREAD=1 "-DF77_FUNC(name,NAME)=name ## _" "-DF77_FUNC_(name,NAME)=name ## _" -DSIZEOF_FORTRAN_INTEGER=4 -DSIZEOF_INT=4 "-DWITH_NUMPY=/**/" -D__OSVERSION__=2 "-DOMNIORB=/**/" "-DCORBA_HAVE_POA=/**/" "-DCORBA_ORB_INIT_HAVE_3_ARGS=/**/" "-DCORBA_ORB_INIT_THIRD_ARG=/**/" -DYYTEXT_POINTER=1 -I. -DPCLINUX64 -DH5_USE_16_API -I/usr/include -DH5_USE_16_API -ftemplate-depth-42 -I./../../INTERP_KERNEL -I./../../INTERP_KERNEL/Geometric2D -I./../../INTERP_KERNEL/Bases -I./../../MEDCoupling -I./../ -DHAVE_SOCKET -DHAVE_MPI2 -I/opt/salome-5.1.3/KERNEL/include/salome -include SALOMEconfig.h -D_OCC64 -O -Wparentheses -Wreturn-type -Wmissing-declarations -Wunused -pthread -MT libparamedmemmedloader_la-MEDLoader.lo -MD -MP -MF .deps/libparamedmemmedloader_la-MEDLoader.Tpo -c MEDLoader.cxx -fPIC -DPIC -o .libs/libparamedmemmedloader_la-MEDLoader.o MEDLoader.cxx: In function ‘std::string buildStringFromFortran(const char*, int)’: MEDLoader.cxx:120: warning: no previous declaration for ‘std::string buildStringFromFortran(const char*, int)’ MEDLoader.cxx: In function ‘std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > MEDLoader::getMeshNamesFid(med_idt)’: MEDLoader.cxx:136: warning: no previous declaration for ‘std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > MEDLoader::getMeshNamesFid(med_idt)’ MEDLoader.cxx: In function ‘std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > MEDLoader::GetMeshFamilyNames(const char*, const char*)’: MEDLoader.cxx:172: error: cannot convert ‘int*’ to ‘med_int*’ in initialization MEDLoader.cxx:173: error: cannot convert ‘int*’ to ‘med_int*’ in initialization and so on and so on. I really do not know where to start looking for the problem.
Created attachment 223869 [details] new ebuild
Created attachment 223871 [details, diff] partially solve med_int issues this patch partially solve the med_int problem for amd64 (x86 is not affected). But now it fails with a linking issue. I can't figure out why for the moment.
(In reply to comment #517) > Hello, > > I've just pushed salome-5.1.3 ebuilds in the science overlay. The upstream > solved problems related to >vtk-5.0. I've tested them on x86 and amd64 and it > seems to work fine (and really more robust than older salome versions). > > I have not tested MPI through Mpich2 implementation nor metis support for > salome-med (collision with parmetis...), so these points have still to be > tested. > > I haven't been able been able to find anything to compile it with PBS support, > so I removed it, but I can be wrong, if someone can see something I've not > noticed... > > I've removed most of parallel build restrictions (it's a pain to test all these > ebuilds knowing that I have a quad-core...). I just add restrictions when I > notice a problem related to parallel build. If you are faced to a compilation > error, try to use -j1 (and please report it if it's effectively a parallel > build problem). > > I've cleaned many things in these ebuilds, I hope I've not introduced too much > errors. I'm pretty sure there are still missing or useless dependencies. > > I have also packaged other components such as light, pylight, multipr, are they > really usefull, should I push them in the overlay? > > The most usefull component would be netgenplugin, but I think we need to > package netgen-4.5 before. > > Enjoy ;) > > Etienne. > Hello Etienne, Thank you for the good work. I do not really understand what you meant with OpenPBS. Could you please develop a bit. Daniel
(In reply to comment #521) > > Hello Etienne, > > Thank you for the good work. > I do not really understand what you meant with OpenPBS. Could you please > develop a bit. > > Daniel > Hi Daniel, in fact I can't find anything in m4 tools or configure script to check OpenPBS (or torque) features. Upstream seems to have removed --with-openpbs configure options. Some configure scripts try to check OpenPBS but immediately fail with a 'CHECK_OPENPBS not found' or something like this. Etienne.
Etienne, > I have also packaged other components such as light, pylight, multipr, are they > really usefull, should I push them in the overlay? I don't know if they are useful but if you produced the ebuilds, I don't see any reason for not putting them in the overlay. > The most usefull component would be netgenplugin, but I think we need to > package netgen-4.5 before. They are netgen packages in the overlay. Isn't it? I think they are now 4.9.x versions of Netgen. Daniel
(In reply to comment #523) > Etienne, > > The most usefull component would be netgenplugin, but I think we need to > > package netgen-4.5 before. > > They are netgen packages in the overlay. Isn't it? I think they are now 4.9.x > versions of Netgen. > > Daniel > In fact that's the point, it does not compile against netgen-4.9. It seems there have been many changes between netgen-4.5 and netgen-4.9. Etienne.
(In reply to comment #520) > Created an attachment (id=223871) [details] > partially solve med_int issues Thanks for patch! salome-med now compiles, but i can confirm there are now linking problems. When i compile salome-smesh i obtain: libtool: link: x86_64-pc-linux-gnu-g++ -I/opt/salome-5.1.3/KERNEL/include/salome -include SALOMEconfig.h -D_OCC64 -O -Wparentheses -Wreturn-type -Wmissing-declarations -Wunused -pthread -Wl,-O1 -Wl,-enable-new-dtags -o .libs/MED_Test MED_Test-MED_Test.o ./.libs/libMeshDriverMED.so -L/opt/salome-5.1.3/KERNEL/lib64/salome -L/opt/opencascade-6.3/ros/Linux/lib -L/opt/salome-5.1.3/MED/lib64/salome -L/usr/lib -L/lib64 -L/lib -L/usr/lib64 -L/var/tmp/portage/sci-libs/med-2.3.5/work/med-2.3.5/src /var/tmp/portage/sci-misc/salome-smesh-5.1.3/work/src5.1.3/SMESH_SRC_5.1.3/src/Driver/.libs/libMeshDriver.so ../Driver/.libs/libMeshDriver.so /var/tmp/portage/sci-misc/salome-smesh-5.1.3/work/src5.1.3/SMESH_SRC_5.1.3/src/SMESHDS/.libs/libSMESHDS.so /opt/opencascade-6.3/ros/lin/lib64/libTKTopAlgo.so /opt/opencascade-6.3/ros/lin/lib64/libTKGeomAlgo.so ../SMDS/.libs/libSMDS.so ../SMESHDS/.libs/libSMESHDS.so /var/tmp/portage/sci-misc/salome-smesh-5.1.3/work/src5.1.3/SMESH_SRC_5.1.3/src/SMDS/.libs/libSMDS.so /opt/opencascade-6.3/ros/lin/lib64/libTKBRep.so /opt/opencascade-6.3/ros/lin/lib64/libTKGeomBase.so /opt/opencascade-6.3/ros/lin/lib64/libTKG3d.so /opt/opencascade-6.3/ros/lin/lib64/libTKG2d.so /opt/opencascade-6.3/ros/lin/lib64/libTKMath.so /opt/opencascade-6.3/ros/lin/lib64/libTKernel.so /opt/salome-5.1.3/KERNEL/lib64/salome/libOpUtil.so /opt/salome-5.1.3/KERNEL/lib64/salome/libSalomeIDLKernel.so -lomniORB4 -lomniDynamic4 -lCOS4 -lCOSDynamic4 -lomnithread /opt/salome-5.1.3/KERNEL/lib64/salome/libSALOMELocalTrace.so /opt/salome-5.1.3/KERNEL/lib64/salome/libSALOMEBasics.so /opt/salome-5.1.3/MED/lib64/salome/libMEDWrapper.so /opt/salome-5.1.3/MED/lib64/salome/libMEDWrapper_V2_1.so /opt/salome-5.1.3/MED/lib64/salome/libmed_V2_1.so /opt/salome-5.1.3/MED/lib64/salome/libMEDWrapper_V2_2.so /usr/lib64/libmedimportcxx.so /usr/lib64/libmed.so -lifport -lifcore -limf -lsvml -lipgo -lirc -lpthread -lirc_s /usr/lib64/libhdf5.so -lz /opt/salome-5.1.3/MED/lib64/salome/libMEDWrapperBase.so -lboost_thread-mt -lrt -lnsl -lm -ldl -pthread -Wl,-rpath -Wl,/opt/salome-5.1.3/SMESH/lib64/salome -Wl,-rpath -Wl,/opt/opencascade-6.3/ros/lin/lib64 ./.libs/libMeshDriverMED.so: undefined reference to `void MED::GetVersionRelease<(MED::EVersion)0>(int&, int&, int&)' ./.libs/libMeshDriverMED.so: undefined reference to `MED::TPolygoneInfo::GetNbConn(int) const' ./.libs/libMeshDriverMED.so: undefined reference to `MED::TElemInfo::SetElemNum(int, int)' ./.libs/libMeshDriverMED.so: undefined reference to `MED::TWrapper::GetPFamilyInfo(MED::SharedPtr<MED::TMeshInfo> const&, int, int*)' ./.libs/libMeshDriverMED.so: undefined reference to `int MED::GetNOMLength<(MED::EVersion)1>()' ./.libs/libMeshDriverMED.so: undefined reference to `MED::TElemInfo::GetElemNum(int) const' ./.libs/libMeshDriverMED.so: undefined reference to `MED::TElemInfo::SetFamNum(int, int)' ./.libs/libMeshDriverMED.so: undefined reference to `MED::TNodeInfo::GetCoordSlice(int)' ./.libs/libMeshDriverMED.so: undefined reference to `int MED::GetNOMLength<(MED::EVersion)0>()' ./.libs/libMeshDriverMED.so: undefined reference to `MED::TPolyedreInfo::GetConnSliceArr(int)' ./.libs/libMeshDriverMED.so: undefined reference to `MED::TGrilleInfo::GetFamNum(int) const' ./.libs/libMeshDriverMED.so: undefined reference to `MED::TGrilleInfo::GetFamNumNode(int) const' ./.libs/libMeshDriverMED.so: undefined reference to `MED::TGrilleInfo::GetConn(int)' ./.libs/libMeshDriverMED.so: undefined reference to `MED::TPolygoneInfo::GetConnSlice(int)' ./.libs/libMeshDriverMED.so: undefined reference to `MED::TCoordHelper::GetCoord(MED::TCSlice<double>&, int)' ./.libs/libMeshDriverMED.so: undefined reference to `MED::TGrilleInfo::GetCoord(int)' ./.libs/libMeshDriverMED.so: undefined reference to `void MED::GetVersionRelease<(MED::EVersion)1>(int&, int&, int&)' ./.libs/libMeshDriverMED.so: undefined reference to `MED::TCellInfo::GetConnSlice(int)' ./.libs/libMeshDriverMED.so: undefined reference to `MED::TFamilyInfo::GetAttrVal(int) const' ./.libs/libMeshDriverMED.so: undefined reference to `MED::TPolyedreInfo::GetNbNodes(int) const' ./.libs/libMeshDriverMED.so: undefined reference to `MED::TElemInfo::GetFamNum(int) const' collect2: ld returned 1 exit status Thanks again! Marek
Etienne, > I've just pushed salome-5.1.3 ebuilds in the science overlay. The upstream > solved problems related to >vtk-5.0. I've tested them on x86 and amd64 and it > seems to work fine (and really more robust than older salome versions). > > I have not tested MPI through Mpich2 implementation nor metis support for > salome-med (collision with parmetis...), so these points have still to be > tested. I confirm. There is a collision between parmetis and metis (it reveals itself if one has openfoam installed, for instance). Wouldn't it be possible to have a virtual/metis mechanism? (see bug #310663) > I've cleaned many things in these ebuilds, I hope I've not introduced too much > errors. I'm pretty sure there are still missing or useless dependencies. I was under the impression that the dependency to OpenCascade was optional (correct me if I am wrong). Considering the time it takes to build OpenCascade that could be a good idea to check if Salome _really_ needs OCC or if the use of OpenCascade is optional. Daniel
Hi guys This is slightly OT but here goes. I have set up a separate root partition to install salome on. Now I know python 2.4 is recommended but switching to python 2.4 using eselect-python causes portage to stop functioning. I want to know how you guys get around this, I have both the current 2.4 and 2.6 version installed. Dewald
Hi, I can't build salome-gui. There is a problem with VTViewer. Salome's version is 5.1.3 Thanks herve darce emerge salome-meta ----- Dans le fichier inclus à partir de /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/backward/strstream:51, à partir de /usr/include/vtk-5.4/vtkIOStream.h:112, à partir de /usr/include/vtk-5.4/vtkSystemIncludes.h:40, à partir de VTKViewer.h:35, à partir de VTKViewer_Actor.h:31, à partir de VTKViewer_Actor.cxx:34: /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/backward/backward_warning.h:33:2: attention : #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated. VTKViewer_Actor.cxx:48:34: erreur: vtkPassThroughFilter.h : Aucun fichier ou dossier de ce type VTKViewer_Actor.cxx: In constructor ‘VTKViewer_Actor::VTKViewer_Actor()’: VTKViewer_Actor.cxx:85: erreur: incomplete type ‘vtkPassThroughFilter’ used in nested name specifier VTKViewer_Actor.cxx: In destructor ‘virtual VTKViewer_Actor::~VTKViewer_Actor()’: VTKViewer_Actor.cxx:102: erreur: invalid use of incomplete type ‘struct vtkPassThroughFilter’ VTKViewer_Actor.h:45: erreur: forward declaration of ‘struct vtkPassThroughFilter’ VTKViewer_Actor.cxx: In member function ‘void VTKViewer_Actor::InitPipeLine(vtkMapper*)’: VTKViewer_Actor.cxx:187: erreur: invalid use of incomplete type ‘struct vtkPassThroughFilter’ VTKViewer_Actor.h:45: erreur: forward declaration of ‘struct vtkPassThroughFilter’ VTKViewer_Actor.cxx:188: erreur: invalid use of incomplete type ‘struct vtkPassThroughFilter’ VTKViewer_Actor.h:45: erreur: forward declaration of ‘struct vtkPassThroughFilter’ VTKViewer_Actor.cxx:188: erreur: invalid use of incomplete type ‘struct vtkPassThroughFilter’ VTKViewer_Actor.h:45: erreur: forward declaration of ‘struct vtkPassThroughFilter’ VTKViewer_Actor.cxx:192: erreur: invalid use of incomplete type ‘struct vtkPassThroughFilter’ VTKViewer_Actor.h:45: erreur: forward declaration of ‘struct vtkPassThroughFilter’ VTKViewer_Actor.cxx:195: erreur: invalid use of incomplete type ‘struct vtkPassThroughFilter’ VTKViewer_Actor.h:45: erreur: forward declaration of ‘struct vtkPassThroughFilter’ VTKViewer_Actor.cxx:196: erreur: invalid use of incomplete type ‘struct vtkPassThroughFilter’ VTKViewer_Actor.h:45: erreur: forward declaration of ‘struct vtkPassThroughFilter’ VTKViewer_Actor.cxx:196: erreur: invalid use of incomplete type ‘struct vtkPassThroughFilter’ VTKViewer_Actor.h:45: erreur: forward declaration of ‘struct vtkPassThroughFilter’ VTKViewer_Actor.cxx:199: erreur: invalid use of incomplete type ‘struct vtkPassThroughFilter’ VTKViewer_Actor.h:45: erreur: forward declaration of ‘struct vtkPassThroughFilter’ VTKViewer_Actor.cxx:202: erreur: invalid use of incomplete type ‘struct vtkPassThroughFilter’ VTKViewer_Actor.h:45: erreur: forward declaration of ‘struct vtkPassThroughFilter’ VTKViewer_Actor.cxx:203: erreur: invalid use of incomplete type ‘struct vtkPassThroughFilter’ VTKViewer_Actor.h:45: erreur: forward declaration of ‘struct vtkPassThroughFilter’ VTKViewer_Actor.cxx:203: erreur: invalid use of incomplete type ‘struct vtkPassThroughFilter’ VTKViewer_Actor.h:45: erreur: forward declaration of ‘struct vtkPassThroughFilter’ VTKViewer_Actor.cxx:207: erreur: invalid use of incomplete type ‘struct vtkPassThroughFilter’ VTKViewer_Actor.h:45: erreur: forward declaration of ‘struct vtkPassThroughFilter’ VTKViewer_Actor.cxx:209: erreur: invalid use of incomplete type ‘struct vtkPassThroughFilter’ VTKViewer_Actor.h:45: erreur: forward declaration of ‘struct vtkPassThroughFilter’ VTKViewer_Actor.cxx: In member function ‘virtual vtkDataSet* VTKViewer_Actor::GetInput()’: VTKViewer_Actor.cxx:336: erreur: invalid use of incomplete type ‘struct vtkPassThroughFilter’ VTKViewer_Actor.h:45: erreur: forward declaration of ‘struct vtkPassThroughFilter’ VTKViewer_Actor.cxx: In member function ‘virtual long unsigned int VTKViewer_Actor::GetMTime()’: VTKViewer_Actor.cxx:349: erreur: invalid use of incomplete type ‘struct vtkPassThroughFilter’ VTKViewer_Actor.h:45: erreur: forward declaration of ‘struct vtkPassThroughFilter’ make[2]: *** [libVTKViewer_la-VTKViewer_Actor.lo] Erreur 1 make[2]: quittant le répertoire « /var/tmp/portage/sci-misc/salome-gui-5.1.3/work/src5.1.3/GUI_SRC_5.1.3/src/VTKViewer » make[1]: *** [all-recursive] Erreur 1 make[1]: quittant le répertoire « /var/tmp/portage/sci-misc/salome-gui-5.1.3/work/src5.1.3/GUI_SRC_5.1.3/src » make: *** [all-recursive] Erreur 1 ^[[31;01m*^[[0m ERROR: sci-misc/salome-gui-5.1.3 failed: ----- emerge --info ----- Portage 2.1.7.17 (default/linux/x86/10.0, gcc-4.3.4, glibc-2.10.1-r1, 2.6.31-xen-r5 i686) ================================================================= System uname: Linux-2.6.31-xen-r5-i686-Intel-R-_Core-TM-_i7_CPU_920_@_2.67GHz-with-gentoo-1.12.13 Timestamp of tree: Tue, 16 Mar 2010 06:30:23 +0000 distcc[13234] (dcc_mkdir) ERROR: mkdir '/home/hdlive/.distcc' failed: No such file or directory [disabled] ccache version 2.4 [disabled] app-shells/bash: 4.0_p35 dev-java/java-config: 2.1.10 dev-lang/python: 2.6.4-r1 dev-python/pycrypto: 2.1.0_beta1 dev-util/ccache: 2.4-r7 dev-util/cmake: 2.6.4-r3 sys-apps/baselayout: 1.12.13 sys-apps/sandbox: 1.6-r2 sys-devel/autoconf: 2.13, 2.63-r1 sys-devel/automake: 1.6.3-r1, 1.8.5-r4, 1.9.6-r3, 1.10.2 sys-devel/binutils: 2.18-r3 sys-devel/gcc: 4.3.4 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="x86" ACCEPT_LICENSE="* -@EULA" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=i686 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /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/sandbox.d /etc/splash /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -march=i686 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests distlocks fixpackages news parallel-fetch protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="fr_FR.UTF-8" LC_ALL="fr_FR.UTF-8" LDFLAGS="-Wl,-O1" LINGUAS="fr" 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/local/portage/layman/science" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="R X a52 aac acl alsa autoipd avahi bash-completion berkdb bindist bluetooth branding bzip2 cairo cdda cdf cdio cdparanoia cdr cdrom cli consolekit context cracklib crypt cxx dbus divx dri dv dvd dvdr dvdread dvi dvipdfm eds embedded emboss emf encode esd evo extra fat fbcon fbcondecor ffmpeg flac fortran gcj gd gdbm gif gimp gnome gnuplot gnutls gpm graphics graphviz gsl gstreamer gtk hal hash humanities ical iceweasel iconv ieee1394 imagemagick imap inkjar ipv6 isdnlog jabber java javascript jfs jpeg kde kpathsea lame latex ldap letex3 libnotify libsamplerate live livecd mad maildir mdnsresponder-compat midi mikmod modules mp2 mp3 mp4 mp4live mpeg mudflap musepack ncurses nemesi nls nptl nptlonly nsplugin ogg openal openbabel openexr opengl openmp pam pcre pdf perl plotutils png pop postscript pppd preview-latex pstricks publishers python qt3support qt4 quicktime readline reflection reiser4 reiserfs science sdl session simplexml sox spell spl sqlite ssl startup-notification stream svg svgz sysfs tcl tcpd tex4ht theora tiff tivo tk truetype unicode usb v4l v4l2 vidix vorbis webkit win32codecs wma wmf wxwidgets x264 x86 x86emu xanim xetex xfs xml xorg xulrunner xv xvid zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 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 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" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="fr" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="fbdev glint intel mach64 mga neomagic nv r128 radeon savage sis tdfx trident vesa via vmware voodoo" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS -----
Hello, I've pushed new ebuilds in the overlay, cleaned thanks to Oliver's remarks. I've patched salome-med for amd64 against the med_int typedef issue. There's only one issue remaining if salome-med is configured with metis and/or scotch USE flags. It ends with a linking issue that I can't understand. If someone can have a look at it.... One solution would be to flag this support in sci-libs/med, but it's not recommended for Code Aster users. @Dewald: in fact, the python-2.4 warning remains because it's written in the specs, but I think that most users are using python-2.5 and surely python-2.6 on Gentoo. I've only patched one function for python-2.6, and it *seems* to work fine. @Herve: sync your science overlay, I've solved this issue. In fact salome-gui requires sci-libs/vtk to be built with mpi support. Regards, Etienne.
Hello Etienne, Thank you. The problem is solved. Orthewise, I can't take mpi like global use because there is problem with hdf5. For hdf5, cxx use et mpi use are not compatibles. So I add in the /etc/portage/package.use this: cat /etc/portage/package.use ----- sci-libs/hdf5 -mpi ----- Thanks, Herve Darce
(In reply to comment #525) > (In reply to comment #520) > > Created an attachment (id=223871) [details] [details] > > partially solve med_int issues > > Thanks for patch! salome-med now compiles, but i can confirm there are now > linking problems. When i compile salome-smesh i obtain: In my case (amd64, gcc-4.3.4), I get: make[3]: Entering directory `/var/tmp/portage/sci-misc/salome-med-5.1.3/work/src5.1.3/MED_SRC_5.1.3/src/MEDWrapper/V2_2' /bin/sh ../../../libtool --tag=CXX --mode=compile x86_64-pc-linux-gnu-g++ -DPACKAGE_NAME=\"Salome2\ Project\ MED\ module\" -DPACKAGE_TARNAME=\"SalomeMED\" -DPACKAGE_VERSION=\"5.1.3\" -DPACKAGE_STRING=\"Salome2\ Project\ MED\ module\ 5.1.3\" -DPACKAGE_BUGREPORT=\"webmaster.salome@opencascade.com\" -DPACKAGE=\"SalomeMED\" -DVERSION=\"5.1.3\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_LIBDL=1 -DHAVE_LIBRT=1 -DHAVE_LIBM=1 -DHAVE_NAMESPACES=/\*\*/ -DHAVE_PTHREAD=1 -DF77_FUNC\(name,NAME\)=name\ ##\ _ -DF77_FUNC_\(name,NAME\)=name\ ##\ _ -DSIZEOF_FORTRAN_INTEGER=4 -DSIZEOF_INT=4 -DWITH_NUMPY=/\*\*/ -D__OSVERSION__=2 -DOMNIORB=/\*\*/ -DCORBA_HAVE_POA=/\*\*/ -DCORBA_ORB_INIT_HAVE_3_ARGS=/\*\*/ -DCORBA_ORB_INIT_THIRD_ARG=/\*\*/ -DYYTEXT_POINTER=1 -I. -DPCLINUX64 -DH5_USE_16_API -I/usr/include -I./../Base -I/opt/salome-5.1.3/KERNEL/include/salome -DHAVE_SOCKET -DHAVE_MPI2 -I/opt/salome-5.1.3/KERNEL/include/salome -include SALOMEconfig.h -D_OCC64 -march=athlon64 -O2 -pipe -DHAVE_F77INT64 -O -Wparentheses -Wreturn-type -Wmissing-declarations -Wunused -pthread -MT libMEDWrapper_V2_2_la-MED_V2_2_Wrapper.lo -MD -MP -MF .deps/libMEDWrapper_V2_2_la-MED_V2_2_Wrapper.Tpo -c -o libMEDWrapper_V2_2_la-MED_V2_2_Wrapper.lo `test -f 'MED_V2_2_Wrapper.cxx' || echo './'`MED_V2_2_Wrapper.cxx libtool: compile: x86_64-pc-linux-gnu-g++ "-DPACKAGE_NAME=\"Salome2 Project MED module\"" -DPACKAGE_TARNAME=\"SalomeMED\" -DPACKAGE_VERSION=\"5.1.3\" "-DPACKAGE_STRING=\"Salome2 Project MED module 5.1.3\"" -DPACKAGE_BUGREPORT=\"webmaster.salome@opencascade.com\" -DPACKAGE=\"SalomeMED\" -DVERSION=\"5.1.3\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_LIBDL=1 -DHAVE_LIBRT=1 -DHAVE_LIBM=1 "-DHAVE_NAMESPACES=/**/" -DHAVE_PTHREAD=1 "-DF77_FUNC(name,NAME)=name ## _" "-DF77_FUNC_(name,NAME)=name ## _" -DSIZEOF_FORTRAN_INTEGER=4 -DSIZEOF_INT=4 "-DWITH_NUMPY=/**/" -D__OSVERSION__=2 "-DOMNIORB=/**/" "-DCORBA_HAVE_POA=/**/" "-DCORBA_ORB_INIT_HAVE_3_ARGS=/**/" "-DCORBA_ORB_INIT_THIRD_ARG=/**/" -DYYTEXT_POINTER=1 -I. -DPCLINUX64 -DH5_USE_16_API -I/usr/include -I./../Base -I/opt/salome-5.1.3/KERNEL/include/salome -DHAVE_SOCKET -DHAVE_MPI2 -I/opt/salome-5.1.3/KERNEL/include/salome -include SALOMEconfig.h -D_OCC64 -march=athlon64 -O2 -pipe -DHAVE_F77INT64 -O -Wparentheses -Wreturn-type -Wmissing-declarations -Wunused -pthread -MT libMEDWrapper_V2_2_la-MED_V2_2_Wrapper.lo -MD -MP -MF .deps/libMEDWrapper_V2_2_la-MED_V2_2_Wrapper.Tpo -c MED_V2_2_Wrapper.cxx -fPIC -DPIC -o .libs/libMEDWrapper_V2_2_la-MED_V2_2_Wrapper.o MED_V2_2_Wrapper.cxx: In function ‘void MED::GetVersionRelease(MED::TInt&, MED::TInt&, MED::TInt&) [with MED::EVersion <anonymous> = eV2_2]’: MED_V2_2_Wrapper.cxx:98: error: cannot convert ‘MED::TInt*’ to ‘med_int*’ for argument ‘1’ to ‘void MEDversionDonner(med_int*, med_int*, med_int*)’ make[3]: *** [libMEDWrapper_V2_2_la-MED_V2_2_Wrapper.lo] Error 1 make[3]: Leaving directory `/var/tmp/portage/sci-misc/salome-med-5.1.3/work/src5.1.3/MED_SRC_5.1.3/src/MEDWrapper/V2_2' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/sci-misc/salome-med-5.1.3/work/src5.1.3/MED_SRC_5.1.3/src/MEDWrapper' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/sci-misc/salome-med-5.1.3/work/src5.1.3/MED_SRC_5.1.3/src' make: *** [all-recursive] Error 1 Daniel
Created attachment 232539 [details, diff] second patch for med_int problem
Ooops : sorry first bug report, I had the same problem than #531. To compile salome-med, I had to apply the patch I send in #532 emerge --info : Portage 2.1.8.3 (default/linux/amd64/10.0, gcc-4.4.3, glibc-2.11.1-r0, 2.6.33-gentoo-r2 x86_64) ================================================================= System uname: Linux-2.6.33-gentoo-r2-x86_64-Intel-R-_Pentium-R-_4_CPU_3.20GHz-with-gentoo-2.0.1 Timestamp of tree: Fri, 21 May 2010 04:00:01 +0000 app-shells/bash: 4.1_p7 dev-java/java-config: 2.1.11 dev-lang/python: 2.6.5-r2, 3.1.2-r3 dev-python/pycrypto: 2.1.0 dev-util/cmake: 2.8.1-r1 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.6.1-r1 sys-apps/sandbox: 2.2 sys-devel/autoconf: 2.13, 2.65 sys-devel/automake: 1.8.5-r4, 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.4.3-r2 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b virtual/os-headers: 2.6.33 ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=nocona -O2 -g3 -ggdb3 -pipe -ftracer -fsched2-use-traces" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /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" CPPFLAGS="-march=nocona -O2 -g3 -ggdb3 -pipe -ftracer -fsched2-use-traces" CXXFLAGS="-march=nocona -O2 -g3 -ggdb3 -pipe -ftracer -fsched2-use-traces" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests distlocks fixpackages news nostrip parallel-fetch protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="fr_FR.UTF-8" LDFLAGS="-Wl,-O1" LINGUAS="fr en ja" MAKEOPTS="-j3" 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="/var/lib/layman/science /var/lib/layman/java-overlay /var/lib/layman/python" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X aalib acl acpi alsa amd64 bash-completion bazaar berkdb bzip2 cairo cli consolekit cracklib cups cxx darcs dbus debug dri emerald exif flac fortran gdbm gimp git gnome gpm gtk iconv java java6 javascript jpeg jpeg2k libcaca mercurial mmx modules mp3 mpi mudflap multilib nautilus ncurses nls nptl nptlonly nsplugin nvidia objc objc++ objc-gc opengl openmp pam pcre perl png pppd profile python qt qt3support qt4 raw readline reflection romio session spl sqlite sse sse2 ssl subversion svg sysfs szip tcpd threads tiff trace unicode usb vorbis wxwidgets xorg xpm xvmc 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 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" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="fr en ja" RUBY_TARGETS="ruby18" SANE_BACKENDS="hp3500" USERLAND="GNU" VIDEO_CARDS="nvidia" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Created attachment 234261 [details, diff] same patch than salome-med-5.1.2-med_int_2.patch
I had the same problem than #516. The problem is about the "-O2" FLAGS. I remove it from CFLAGS and CXXFLAGS in /etc/make.conf and salome-visu compile well know. Very very strange.
(In reply to comment #531) > -DPIC -o .libs/libMEDWrapper_V2_2_la-MED_V2_2_Wrapper.o > MED_V2_2_Wrapper.cxx: In function ‘void MED::GetVersionRelease(MED::TInt&, > MED::TInt&, MED::TInt&) [with MED::EVersion <anonymous> = eV2_2]’: > MED_V2_2_Wrapper.cxx:98: error: cannot convert ‘MED::TInt*’ to > ‘med_int*’ for argument ‘1’ to ‘void MEDversionDonner(med_int*, > med_int*, med_int*)’ > make[3]: *** [libMEDWrapper_V2_2_la-MED_V2_2_Wrapper.lo] Error 1 > make[3]: Leaving directory > `/var/tmp/portage/sci-misc/salome-med-5.1.3/work/src5.1.3/MED_SRC_5.1.3/src/MEDWrapper/V2_2' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory Hi All, I'm still hitting the error shown above. (~4 months old by now.) I tried a couple of the patch suggestions and got past it to another error. Unfortunately, I couldn't get all the patches to play nicely. Is this reliably working for anybody out there? If so, could you post a summary of which patches to apply and in which order? If the fix could be pushed to the overlay, that would be wonderful. I'm not complaining here... I know these packages are a tough nut to crack. I've tried and can't do it myself. I just want to encourage you that there are users who appreciate your work. Thanks very much!
Hi, Did you try the patch I post few months ago (2010-06-06 01:15) : salome-med-5.1.3-med_int_add.patch (http://bugs.gentoo.org/attachment.cgi?id=234261) (In reply to comment #536)
version bump: 5.1.4 released 07/09/2010
(In reply to comment #538) > version bump: 5.1.4 released 07/09/2010 > There is a patch at bug 330303, which seem to bundle all changes which are required for this new release. Does anybody is able/willing/has-time to push these changes to the science overlay?
I pushed 5.1.4 to the science overlay, thanks to Michael. There are various problems accumulating now: -) .la files, --as-needed and friends need somebody to look at -) The ebuilds still claim that python-2.4 is suggested, can anybody check back on whether that still applies? -) The eautoreconf stages of various of these ebuilds show warnings, there seem to be version mismatches which can lead to tricky failures. So I cannot guarantee that this will work, or will continue to work. Feel free to pick it up if you like.
(In reply to comment #540) > I pushed 5.1.4 to the science overlay, thanks to Michael. There are various > problems accumulating now: Hello, there is at least one patch file missing in the new salome-5.1.4 ebuilds: >>> Preparing source in /var/tmp/portage/sci-misc/salome-kernel-5.1.4/work/src5.1.4/KERNEL_SRC_5.1.4 ... * Cannot find $EPATCH_SOURCE! Value for $EPATCH_SOURCE is: * * /usr/portage/local/layman/science/sci-misc/salome-kernel/files/salome-kernel-5.1.4-lib_location.patch * ( salome-kernel-5.1.4-lib_location.patch ) * ERROR: sci-misc/salome-kernel-5.1.4 failed: * Cannot find $EPATCH_SOURCE! * * Call stack: * ebuild.sh, line 54: Called src_prepare * environment, line 4634: Called epatch '/usr/portage/local/layman/science/sci-misc/salome-kernel/files/salome-kernel-5.1.4-lib_location.patch' * environment, line 1661: Called die * The specific snippet of code: * die "Cannot find \$EPATCH_SOURCE!";
True, amd64 patches slipped because I tested on x86. Should be fixed now, thanks.
(In reply to comment #542) > True, amd64 patches slipped because I tested on x86. Should be fixed now, > thanks. > salome-kernel-5.1.4 fails to build with mpi USE-flag enabled, because of some problems with HDF5, maybe also related to gcc-4.4? BTW: I need hdf5 with mpi enabled, because I need paraview in parallel. I can send the build.log if somebody is interested.
Created attachment 253803 [details] salome-med-5.1.4.ebuild The file salome-med-5.1.4.mpi.patch form salome-med-5.1.4.ebuild does not exists. Disabling it make possible to compile it with additional patch in my next attachament.
Created attachment 253805 [details, diff] salome-med-5.1.4-med_int.patch This file previously was a copy of salome-med-5.1.3-med_int.patch - which did make patching fail. This one work for me.
Created attachment 254743 [details] Salome 5.1.4 gui component
Created attachment 254751 [details] Salome 5.1.4 geom component
Created attachment 254755 [details] Salome 5.1.4 kernel component mpi fails compiling (and behavior is not well defined in configure upstream) Tpo -c -o SALOME_MPIContainer-SALOME_MPIContainer.o `test -f 'SALOME_MPIContainer.cxx' || echo './'`SALOME_MPIContainer.cxx libtool: compile: i686-pc-linux-gnu-g++ "-DPACKAGE_NAME=\"Salome2 Project\"" -DPACKAGE_TARNAME=\"SalomeKERNEL\" -DPACKAGE_VERSION=\"5.1.4\" "-DPACKAGE_STRING=\"Salome2 Project 5.1.4\"" -DPACKAGE_BUGREPORT=\"paul.rascle@edf.fr\" -DPACKAGE_URL=\"\" -DPACKAGE=\"SalomeKERNEL\" -DVERSION=\"5.1.4\" "-DHAVE_SALOME_CONFIG=/**/" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_LIBDL=1 -DHAVE_LIBRT=1 -DHAVE_LIBM=1 "-DHAVE_NAMESPACES=/**/" "-DF77_FUNC(name,NAME)=name ## _" "-DF77_FUNC_(name,NAME)=name ## _" -DSIZEOF_LONG=4 -DSIZEOF_INT=4 -DSIZEOF_FORTRAN_INTEGER=4 -DCAL_INT=int -DHAVE_PTHREAD=1 "-DWITH_NUMPY=/**/" -D__OSVERSION__=2 "-DOMNIORB=/**/" "-DCORBA_HAVE_POA=/**/" "-DCORBA_ORB_INIT_HAVE_3_ARGS=/**/" "-DCORBA_ORB_INIT_THIRD_ARG=/**/" -I. -I/usr/include/python2.6 -I/usr/lib/python2.6/site-packages/numpy/core/include -I/usr/include -I./../Basics -I./../SALOMELocalTrace -I./../NamingService -I./../Utils -I./../Registry -I./../Notification -I./../ResourcesManager -I./../Container -I../../idl -DOMNIORB_VERSION=4 -D__x86__ -D__linux__ -DCOMP_CORBA_DOUBLE -DCOMP_CORBA_LONG -I/usr/include -I/usr/include/omniORB4 -I/usr/include/COS -DHAVE_MPI2 -DHAVE_SOCKET -I../../salome_adm/unix -include SALOMEconfig.h -O2 -march=pentium4 -pipe -mmmx -msse -msse2 -m32 -O -Wparentheses -Wreturn-type -Wmissing-declarations -Wunused -pthread -MT libSalomeMPIContainer_la-MPIObject_i.lo -MD -MP -MF .deps/libSalomeMPIContainer_la-MPIObject_i.Tpo -c MPIObject_i.cxx -fPIC -DPIC -o .libs/libSalomeMPIContainer_la-MPIObject_i.o libtool: compile: i686-pc-linux-gnu-g++ "-DPACKAGE_NAME=\"Salome2 Project\"" -DPACKAGE_TARNAME=\"SalomeKERNEL\" -DPACKAGE_VERSION=\"5.1.4\" "-DPACKAGE_STRING=\"Salome2 Project 5.1.4\"" -DPACKAGE_BUGREPORT=\"paul.rascle@edf.fr\" -DPACKAGE_URL=\"\" -DPACKAGE=\"SalomeKERNEL\" -DVERSION=\"5.1.4\" "-DHAVE_SALOME_CONFIG=/**/" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_LIBDL=1 -DHAVE_LIBRT=1 -DHAVE_LIBM=1 "-DHAVE_NAMESPACES=/**/" "-DF77_FUNC(name,NAME)=name ## _" "-DF77_FUNC_(name,NAME)=name ## _" -DSIZEOF_LONG=4 -DSIZEOF_INT=4 -DSIZEOF_FORTRAN_INTEGER=4 -DCAL_INT=int -DHAVE_PTHREAD=1 "-DWITH_NUMPY=/**/" -D__OSVERSION__=2 "-DOMNIORB=/**/" "-DCORBA_HAVE_POA=/**/" "-DCORBA_ORB_INIT_HAVE_3_ARGS=/**/" "-DCORBA_ORB_INIT_THIRD_ARG=/**/" -I. -I/usr/include/python2.6 -I/usr/lib/python2.6/site-packages/numpy/core/include -I/usr/include -I./../Basics -I./../SALOMELocalTrace -I./../NamingService -I./../Utils -I./../Registry -I./../Notification -I./../ResourcesManager -I./../Container -I../../idl -DOMNIORB_VERSION=4 -D__x86__ -D__linux__ -DCOMP_CORBA_DOUBLE -DCOMP_CORBA_LONG -I/usr/include -I/usr/include/omniORB4 -I/usr/include/COS -DHAVE_MPI2 -DHAVE_SOCKET -I../../salome_adm/unix -include SALOMEconfig.h -O2 -march=pentium4 -pipe -mmmx -msse -msse2 -m32 -O -Wparentheses -Wreturn-type -Wmissing-declarations -Wunused -pthread -MT libSalomeMPIContainer_la-MPIContainer_i.lo -MD -MP -MF .deps/libSalomeMPIContainer_la-MPIContainer_i.Tpo -c MPIContainer_i.cxx -fPIC -DPIC -o .libs/libSalomeMPIContainer_la-MPIContainer_i.o distcc[27015] ERROR: compile /var/tmp/ccache/MPIObject_.tmp.Andromeda.27004.ii on 192.168.1.20 failed In file included from MPIObject_i.cxx:28: MPIObject_i.hxx:62: error: ISO C++ forbids declaration of 'map' with no type MPIObject_i.hxx:62: error: invalid use of '::' MPIObject_i.hxx:62: error: expected ';' before '<' token MPIObject_i.hxx:65: error: ISO C++ forbids declaration of 'map' with no type MPIObject_i.hxx:65: error: invalid use of '::' MPIObject_i.hxx:65: error: expected ';' before '<' token MPIObject_i.hxx:66: error: ISO C++ forbids declaration of 'map' with no type MPIObject_i.hxx:66: error: invalid use of '::' MPIObject_i.hxx:66: error: expected ';' before '<' token MPIObject_i.hxx:67: error: ISO C++ forbids declaration of 'map' with no type MPIObject_i.hxx:67: error: invalid use of '::' MPIObject_i.hxx:67: error: expected ';' before '<' token MPIObject_i.cxx: In member function 'void MPIObject_i::remoteMPI2Connect(std::string)': MPIObject_i.cxx:153: error: '_srv' was not declared in this scope MPIObject_i.cxx:159: error: '_srv' was not declared in this scope MPIObject_i.cxx:171: error: '_port_name' was not declared in this scope MPIObject_i.cxx:213: error: '_icom' was not declared in this scope MPIObject_i.cxx:215: error: '_icom' was not declared in this scope MPIObject_i.cxx:218: error: '_icom' was not declared in this scope MPIObject_i.cxx:218: error: '_gcom' was not declared in this scope MPIObject_i.cxx: In member function 'void MPIObject_i::remoteMPI2Disconnect(std::string)': MPIObject_i.cxx:235: error: '_srv' was not declared in this scope MPIObject_i.cxx:241: error: '_gcom' was not declared in this scope MPIObject_i.cxx:242: error: '_srv' was not declared in this scope MPIObject_i.cxx:246: error: '_port_name' was not declared in this scope MPIObject_i.cxx:255: error: '_icom' was not declared in this scope MPIObject_i.cxx:256: error: '_srv' was not declared in this scope make[2]: *** [libSalomeMPIContainer_la-MPIObject_i.lo] Error 1 make[2]: *** Waiting for unfinished jobs.... distcc[27014] (dcc_writex) ERROR: failed to write: No route to host distcc[27014] (dcc_writex) ERROR: failed to write: Broken pipe distcc[27014] Warning: failed to distribute /var/tmp/ccache/SALOME_MPI.tmp.Andromeda.26919.ii to 192.168.1.104, running locally instead distcc[27016] (dcc_writex) ERROR: failed to write: No route to host distcc[27016] (dcc_writex) ERROR: failed to write: Broken pipe distcc[27016] Warning: failed to distribute /var/tmp/ccache/MPIContain.tmp.Andromeda.27010.ii to 192.168.1.102, running locally instead mv -f .deps/SALOME_MPIContainer-SALOME_MPIContainer.Tpo .deps/SALOME_MPIContainer-SALOME_MPIContainer.Po In file included from /usr/include/python2.6/Python.h:8, from MPIContainer_i.cxx:40: /usr/include/python2.6/pyconfig.h:1079:1: warning: "_XOPEN_SOURCE" redefined In file included from /usr/lib/gcc/i686-pc-linux-gnu/4.3.1/include/g++-v4/i686-pc-linux-gnu/bits/os_defines.h:44, from /usr/lib/gcc/i686-pc-linux-gnu/4.3.1/include/g++-v4/i686-pc-linux-gnu/bits/c++config.h:40, from /usr/lib/gcc/i686-pc-linux-gnu/4.3.1/include/g++-v4/iostream:44, from MPIContainer_i.cxx:27: /usr/include/features.h:160:1: warning: this is the location of the previous definition MPIContainer_i.cxx: In member function 'Engines::_objref_Component* Engines_MPIContainer_i::createMPIInstance(std::string, void*, int)': MPIContainer_i.cxx:386: warning: unused variable 'ret_studyId' mv -f .deps/libSalomeMPIContainer_la-MPIContainer_i.Tpo .deps/libSalomeMPIContainer_la-MPIContainer_i.Plo make[2]: Leaving directory `/var/tmp/portage/sci-misc/salome-kernel-5.1.4/work/src5.1.4/KERNEL_SRC_5.1.4/src/MPIContainer' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/sci-misc/salome-kernel-5.1.4/work/src5.1.4/KERNEL_SRC_5.1.4/src' make: *** [all-recursive] Error 1 * ERROR: sci-misc/salome-kernel-5.1.4 failed: * emake failed * * Call stack: * ebuild.sh, line 54: Called src_compile * environment, line 4785: Called _eapi2_src_compile * ebuild.sh, line 646: Called die * The specific snippet of code: * emake || die "emake failed" * * If you need support, post the output of 'emerge --info =sci-misc/salome-kernel-5.1.4', * the complete build log and the output of 'emerge -pqv =sci-misc/salome-kernel-5.1.4'. * This ebuild is from an overlay: '/usr/local/portage/' * The complete build log is located at '/var/tmp/portage/sci-misc/salome-kernel-5.1.4/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sci-misc/salome-kernel-5.1.4/temp/environment'. * S: '/var/tmp/portage/sci-misc/salome-kernel-5.1.4/work/src5.1.4/KERNEL_SRC_5.1.4'
I just finished building salome-gui. I had a problem configuring pyqt and pyuic4. I had to add: --with-pyqt=/usr/lib64/python2.6/site-packages/PyQt4 \ --with-pyuic4=/usr/bin/pyuic4 \ to the econf line. I just hard coded the paths, I would think that there is a proper more elegant way to do this, but I have no knowledge of ebuild scripts.
Created attachment 257260 [details, diff] salome-yacs-5.1.4-lib_location.patch I built salome-yacs successfully after creating this patch. I just copied the changes to the 5.13 patch.
Created attachment 257261 [details, diff] salome-yacs-5.1.4-libdir.patch I built salome-yacs successfully after creating this patch. I just copied the changes from the 5.13 patch.
Created attachment 268839 [details, diff] Patch to AMD64 Fix error during compiling salome-med 5.1.4
Created attachment 268883 [details] Fix qscintilla path Fix eroor in path qscintilla. In configure qscintilla is a not important params. And compilation throw. But in fact, without qscintilla.
Created attachment 278009 [details] Build.log The build.log
Not Build sci-misc/salome-yacs-5.1.4 parsing file: xml/YACSlibEngineExport_8hxx.xml parsing file: xml/dir_fe2cb4379a8bdf0202862e4d7623d6ff.xml echo "Error: SWIG version >= 1.3.17 is required. You have 2.0.2. You should look at http://www.swig.org" ; false -c++ -python -noexcept -DYACS_PTHREAD -I./../bases -I./../engine -DDOXYGEN_IS_OK -o pilotWRAP.cxx ./pilot.i Error: SWIG version >= 1.3.17 is required. You have 2.0.2. You should look at http://www.swig.org make[3]: *** [pilotWRAP.cxx] Errore 1 make[3]: Leaving directory `/var/tmp/portage/sci-misc/salome-yacs-5.1.4/work/src5.1.4/YACS_SRC_5.1.4/src/engine_swig' make[2]: *** [all-recursive] Errore 1 make[2]: Leaving directory `/var/tmp/portage/sci-misc/salome-yacs-5.1.4/work/src5.1.4/YACS_SRC_5.1.4/src' make[1]: *** [all-recursive] Errore 1 make[1]: Leaving directory `/var/tmp/portage/sci-misc/salome-yacs-5.1.4/work/src5.1.4/YACS_SRC_5.1.4' make: *** [all] Errore 2 emake failed * ERROR: sci-misc/salome-yacs-5.1.4 failed (compile phase): * emake failed * * Call stack: * ebuild.sh, line 56: Called src_compile * environment, line 4545: Called _eapi2_src_compile * ebuild.sh, line 665: Called die * The specific snippet of code: * emake || die "emake failed" * * If you need support, post the output of 'emerge --info =sci-misc/salome-yacs-5.1.4', * the complete build log and the output of 'emerge -pqv =sci-misc/salome-yacs-5.1.4'. * This ebuild is from an overlay named 'science': '/var/lib/layman/science/' * The complete build log is located at '/var/tmp/portage/sci-misc/salome-yacs-5.1.4/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sci-misc/salome-yacs-5.1.4/temp/environment'. * S: '/var/tmp/portage/sci-misc/salome-yacs-5.1.4/work/src5.1.4/YACS_SRC_5.1.4'
The upstream version has reached already 6.3.1. Is there any progress about this package?
Created attachment 286253 [details] ebuild for salome-kernel-6.3.1
Created attachment 286255 [details, diff] patch for above ebuild
Created attachment 286257 [details, diff] patch for above ebuild
Created attachment 286259 [details] salome-kernel-6.3.1-lib_location.patch
Created attachment 286261 [details] salome-kernel-6.3.1-occ-stdplugin.patch
Created attachment 286263 [details] ebuild for salome-gui-6.3.1 I added a two new mutually exclusive USE flags, vtk and paraview to select the vtk version to compile with. It requires either vtk-5.8.0 which is not yet in portage or paraview-3.10 which is included in the science overlay. But you have to recompile paraview with -DVTK_USE_GL2PS=ON added to mycmakeargs.
Created attachment 286265 [details] salome-gui-6.3.1-qt4-path.patch
Created attachment 286267 [details] salome-gui-6.3.1-qt-4.7.patch This one was really annoying.
Created attachment 286269 [details] salome-gui-6.3.1-vtk.patch
Created attachment 286271 [details] ebuild salome-geom-6.3.1
Created attachment 286273 [details] salome-geom-6.3.1-docutils-DESTDIR.patch
The patches which allow to compile salome-{gui,geom} with opencascade-6.5 are not ready, yet. I'll post them soon together with an ebuild for opencascde-6.5 (which has been released not to long ago) see bug #118656. Also in preparation are live ebuilds for salome-git (git.salome-platform.org/gitweb).
(In reply to comment #568) > The patches which allow to compile salome-{gui,geom} with opencascade-6.5 are > not ready, yet. I'll post them soon together with an ebuild for opencascde-6.5 > (which has been released not to long ago) see bug #118656. > Also in preparation are live ebuilds for salome-git > (git.salome-platform.org/gitweb). Compiled occ-6.5 for gmsh, works. I would try the patches; did you already finalize the patches?
Thank you very much for all your work. I apologize in advance for their breach of trust. When will version 6.3.1 in the science tree? Thank you very much
Created attachment 323878 [details] Patch for qobject cast Solves the case where you get this error message: error: cannot convert from base 'QObject' to derived type 'SalomeApp_Module' via virtual base 'LightApp_Module'
Hi, I did some work on ebuilds for salome-*-6.6.0 (*=kernel, gui, component, med, visu, geom, smesh). The ebuilds except "smesh" could be emerged without useflasg "doc". There is some work todo. Anyone interessted to help?
(In reply to comment #572) > Hi, I did some work on ebuilds for salome-*-6.6.0 (*=kernel, gui, component, > med, visu, geom, smesh). The ebuilds except "smesh" could be emerged without > useflasg "doc". There is some work todo. Anyone interessted to help? I don't think I have the time to spare, but it would be nice to have 6.6.0 in the tree. What needs to be done?
Ok, I will upload the files soon. I don't know what does not work while emerging with use flag "doc", but I think you will see I you try it.
I uploaded the ebuilds and patches under a new "bug" with ID 472894.
*** Bug 364749 has been marked as a duplicate of this bug. ***
*** Bug 472894 has been marked as a duplicate of this bug. ***
*** Bug 362483 has been marked as a duplicate of this bug. ***
