Personal tools
You are here: Home Forum Install & build salome 3.2.2 on suse 10.0

salome 3.2.2 on suse 10.0

Up to Install & build

salome 3.2.2 on suse 10.0

Posted by walter steffe at October 03. 2006
I had no problem with the previous version of Salome (3.2.1) but with the new one I get the following error:

runSalome > temp
SALOME_Session_Server: symbol lookup error: /home/walter/local/salome_3.2.2/KERNEL_3.2.2/lib/salome/libSalomeDSImpl.so.0: undefined symbol: NULL_STRING
th. 1097317408 COMPILED with /dn22/SALOME/OCCtestE/KERNEL/Mandriva/KERNEL_SRC/src/Container/SALOME_ContainerManagerServer.cxx [31] : g++, Sep 19 2006 at 16:42:07
th. 1097317504 COMPILED with /dn22/SALOME/OCCtestE/KERNEL/Mandriva/KERNEL_SRC/src/Container/SALOME_Container.cxx [76] : g++, Sep 19 2006 at 16:41:44
 ..........

From the messages it seems that the undefined symbol is in a code that was precompiled in the distribution.
But I have asked to install the KERNEL (which contanis the two files SALOME_ContainerManagerServer.cxx and SALOME_Container.cxx)
from the sources so I do not understand what is going on.





Re: salome 3.2.2 on suse 10.0

Posted by walter steffe at October 04. 2006
In the hope of solving the problems I have tried to resinstall Salome 3.2.2 with the all  the prerequisite packages recompiled from sources but I had a problem with CAS.
The compilation of CAS terminated with the following message:

libtool: install: warning: relinking `libTKDCAF.la'
libtool: install: warning: relinking `libTKXDEDRAW.la'
/tmp/INSTALLWORK8066/CAS-6.1/adm/make/TKernel/.libs/libTKernel.so: undefined reference to `pthread_detach'
/tmp/INSTALLWORK8066/CAS-6.1/adm/make/TKernel/.libs/libTKernel.so: undefined reference to `pthread_join'
collect2: ld returned 1 exit status
make[3]: *** [DRAWEXE] Error 1
make[2]: *** [install-recursive] Error 1
make[1]: *** [install-recursive] Error 1
make: *** [install-strip] Error 2

I think I have to change add -lpthread to the  compiler/loader options but I do not know how I can pass this option to the runInstall wizard.
Thanks In advance for any help.

Re: salome 3.2.2 on suse 10.0

Posted by walter steffe at October 05. 2006
Hy

I have seen that the loader options can be defined trough the LDFLAGS variable. So I have used export LDFLAGS=-lpthreads and
the CAS problem is solved.

Unfortunately now I have another problem with netgen.
The errore messages in the related make.log are

......
/home/walter/local/Salome/salome_3.2.2/CAS-6.1/inc/Standard_Integer.hxx: In function ‘Standard_Integer IntegerFirst()’:
/home/walter/local/Salome/salome_3.2.2/CAS-6.1/inc/Standard_Integer.hxx:129: error: ‘INT_MIN’ was not declared in this scope
/home/walter/local/Salome/salome_3.2.2/CAS-6.1/inc/Standard_Integer.hxx: In function ‘Standard_Integer IntegerLast()’:
/home/walter/local/Salome/salome_3.2.2/CAS-6.1/inc/Standard_Integer.hxx:135: error: ‘INT_MAX’ was not declared in this scope
/home/walter/local/Salome/salome_3.2.2/CAS-6.1/inc/Standard_Integer.hxx: In function ‘Standard_Integer IntegerSize()’:
/home/walter/local/Salome/salome_3.2.2/CAS-6.1/inc/Standard_Integer.hxx:141: error: ‘CHAR_BIT’ was not declared in this scope
/home/walter/local/Salome/salome_3.2.2/CAS-6.1/inc/Standard_Integer.hxx: In function ‘Standard_Integer IntegerFirst()’:
/home/walter/local/Salome/salome_3.2.2/CAS-6.1/inc/Standard_Integer.hxx:129: error: ‘INT_MIN’ was not declared in this scope
/home/walter/local/Salome/salome_3.2.2/CAS-6.1/inc/Standard_Integer.hxx: In function ‘Standard_Integer IntegerLast()’:
/home/walter/local/Salome/salome_3.2.2/CAS-6.1/inc/Standard_Integer.hxx:135: error: ‘INT_MAX’ was not declared in this scope
/home/walter/local/Salome/salome_3.2.2/CAS-6.1/inc/Standard_Integer.hxx: In function ‘Standard_Integer IntegerSize()’:
/home/walter/local/Salome/salome_3.2.2/CAS-6.1/inc/Standard_Integer.hxx:141: error: ‘CHAR_BIT’ was not declared in this scope
/home/walter/local/Salome/salome_3.2.2/CAS-6.1/inc/Standard_Integer.hxx: In function ‘Standard_Integer IntegerFirst()’:
/home/walter/local/Salome/salome_3.2.2/CAS-6.1/inc/Standard_Integer.hxx:129: error: ‘INT_MIN’ was not declared in this scope
/home/walter/local/Salome/salome_3.2.2/CAS-6.1/inc/Standard_Integer.hxx: In function ‘Standard_Integer IntegerLast()’:
/home/walter/local/Salome/salome_3.2.2/CAS-6.1/inc/Standard_Integer.hxx:135: error: ‘INT_MAX’ was not declared in this scope
/home/walter/local/Salome/salome_3.2.2/CAS-6.1/inc/Standard_Integer.hxx: In function ‘Standard_Integer IntegerSize()’:
/home/walter/local/Salome/salome_3.2.2/CAS-6.1/inc/Standard_Integer.hxx:141: error: ‘CHAR_BIT’ was not declared in this scope
/home/walter/local/Salome/salome_3.2.2/CAS-6.1/inc/Standard_Integer.hxx: In function ‘Standard_Integer IntegerFirst()’:
/home/walter/local/Salome/salome_3.2.2/CAS-6.1/inc/Standard_Integer.hxx:129: error: ‘INT_MIN’ was not declared in this scope
.....


any idea about how to define INT_MAX INT_MAX CHAR_BIT ...... ?

Thanks
Walter

Re: salome 3.2.2 on suse 10.0

Posted by Vadim SANDLER at October 05. 2006
Hello Walter,

The problems is with limits header file. Depending on the platfrorm it can be either limits ot limits.h. This is automatically determined when CASCADE is compiled but not in netgen.
Could you please check your CASCADE installation (after building from sources): please check config.h header file in CAS-6.1 folder: which macro is defined there: HAVE_LIMITS or HAVE_LIMITS_H?

The netgen compilation procedure uses -DHAVE_LIMITS_H flag but it may be not correct on Suse 10.0.

Regards,
Vadim.

Re: salome 3.2.2 on suse 10.0

Posted by walter steffe at October 05. 2006
Hy Vadim

In CAS-6.1/config.h   there is:   
#define HAVE_LIMITS_H 1

while in netgen-4.5/MAKE.LOG there is DHAVE_LIMITS (see bolow)

....
gcc -c -I../../libsrc/include -I/home/walter/local/Salome/salome_3.2.2/CAS-6.1/inc -DOCCGEOMETRY -DOCC52 -DHAVE_IOSTREAM -DHAVE_LIMITS -O2 -I/usr/include/GL3.5 -DLINUX -ftemplate-depth-99 -finline-limit=10000 -Wdisabled-optimization  -funroll-loops  -DnoNGSOLVE   occgeom.cpp occmeshsurf.cpp occgenmesh.cpp occconstruction.cpp Partition_Inter2d.cxx Partition_Inter3d.cxx Partition_Loop2d.cxx Partition_Loop3d.cxx Partition_Loop.cxx Partition_Spliter.cxx
/home/walter/local/Salome/salome_3.2.2/CAS-6.1/inc/Standard_Integer.hxx: In function ‘Standard_Integer IntegerFirst()’:
/home/walter/local/Salome/salome_3.2.2/CAS-6.1/inc/Standard_Integer.hxx:129: error: ‘INT_MIN’ was not declared in this scope
....

So  what have I to do do put DHAVE_LIMITS_H also in netgen

An other question:
is it possible to remake/reinstall netgen without the recompilation/reinstallation of CAS and  other packages (which takes a long time) ?

thanks for your help

Re: salome 3.2.2 on suse 10.0

Posted by Vadim SANDLER at October 05. 2006
Hello Walter,

Actually when netgen 4.5 is built from sources with help of SALOME Install Wizard its sources are patched automatically by replacing -DHAVE_LIMITS by -DHAVE_LIMITS_H. You can check this by looking at INSTALL_ROOT/config_files/netgen-4.5.sh, install_sources() function.

It is possible to rebuild only netgen from sources. Run Install Wizard, switch to advanced installation mode (More... button), unselect all products, choose "install sources" for Netgen-4.5 and select as installation directory the same directory you previously installed SALOME and proceed with the Installation Wizard.

Regards,
Vadim.

Re: salome 3.2.2 on suse 10.0

Posted by walter steffe at October 05. 2006

Hello Vadim

I have looked inside netgen-4.5.sh, install_source() function but I was not able to find where the substitution -DHAVE_LIMITS >> -DHAVE_LIMITS_H could take place. Indeed it seems to me that it is not done at all.

So at the end I have performed the substituition directly in the archive Product/SOURCES/netgen-4.5.tar.gz (file libsrc/makefile.inc).

Now all the prereqisuite package are built and installed. Next step is to build Salome. I will use build.csh.

Thanks for your help

Re: salome 3.2.2 on suse 10.0

Posted by Vadim SANDLER at October 05. 2006
You are welcome.

But I have one question. Are you sure you use SALOME 3.2.2 Installation Wizard?
Because the patch I meant was added to the netgen-4.5.sh for this version of SALOME. It is the following line in the install_source() function:

(cd ${PRODUCT_WORK}/libsrc; sed -e 's%\(.*\)-DHAVE_LIMITS%\1-DHAVE_LIMITS_H%g' makefile.inc > makefile.inc.new; mv makefile.inc.new makefile.inc)


Regards,
Vadim.

Re: salome 3.2.2 on suse 10.0

Posted by walter steffe at October 05. 2006

Hello Vadim

Yes I am sure it is the SALOME 3.2.2 Installation Wizard and that line is not present. I have done a search for the string DHAVE_LIMITS with no results.

Regards,

Walter

Re: salome 3.2.2 on suse 10.0

Posted by Igor Nazarov at October 05. 2006
Dear Walter,

It seems it is problem of config_files/netgen-4.5.sh netgen configure file of Installation Wizard.

After string :

# apply patch: to make compilable on latest versions of gcc
(cd ${PRODUCT_WORK}/libsrc/meshing; echo -e '16s/^$/class Mesh;\nwq' | ed - meshtype.hpp > /dev/null)

please add string :

# apply patch: to make compilable with CASCADE-6.1
(cd ${PRODUCT_WORK}/libsrc; sed -e 's%\(.*\)-DHAVE_LIMITS%\1-DHAVE_LIMITS_H%g' makefile.inc > makefile.inc.new; mv makefile.inc.new makefile.inc)

and then try to build netgen by Installation Wizard.

Re: salome 3.2.2 on suse 10.0

Posted by walter steffe at October 05. 2006
Dear Igor

I have added the patch but it desn't work properly.
To be more precise the replacement DHAVE_LIMITS >> DHAVE_LIMITS_H in the file
/tmp/INSTALLWORK.../netgen-4.5/libsrc/makefile.inc is done correctly but there are some side effects and the make of netgen generates a lot of errors. Here are some of them:


In file included from ../../libsrc/include/occgeom.hpp:1,
                 from occgeom.cpp:5:
../../libsrc/include/../occ/occgeom.hpp:14:25: error: BRep_Tool.hxx: No such file or directory
../../libsrc/include/../occ/occgeom.hpp:15:26: error: Geom_Curve.hxx: No such file or directory
../../libsrc/include/../occ/occgeom.hpp:16:28: error: Geom2d_Curve.hxx: No such file or directory
../../libsrc/include/../occ/occgeom.hpp:17:28: error: Geom_Surface.hxx: No such file or directory
../../libsrc/include/../occ/occgeom.hpp:18:42: error: GeomAPI_ProjectPointOnSurf.hxx: No such file or directory
../../libsrc/include/../occ/occgeom.hpp:19:43: error: GeomAPI_ProjectPointOnCurve.hxx: No such file or directory
../../libsrc/include/../occ/occgeom.hpp:20:25: error: BRepTools.hxx: No such file or directory
../../libsrc/include/../occ/occgeom.hpp:21:22: error: TopExp.hxx: No such file or directory
../../libsrc/include/../occ/occgeom.hpp:22:41: error: BRepBuilderAPI_MakeVertex.hxx: No such file or director
............


Please notice that all works properly if the substitution is made manually in the netgen source archive.

I will check the difference of the two makefile.inc files (manually and wizard patced) in INSTALLWORK dir in order to undestand what is going wrong.


Walter



Re: salome 3.2.2 on suse 10.0

Posted by walter steffe at October 05. 2006
Hy Igor

I am sorry but what I have to amend to what said in the previous post.

In fact now I have repeated the installation of netgen using the manually patched repository
(and the file netgen-4.5.sh without the line ...) and I got the same errors as with the patch applied trough the additional line in netgen-4.5.sh.
I can't understand what is going on. This morning I have done the same thing and the netgen was compiled and installed with no errors.

Walter

Re: salome 3.2.2 on suse 10.0

Posted by walter steffe at October 05. 2006
Now I have anderstood what has happened.

The first time I have installed netgen only the wizard has changed the files
env_build.sh and env_products.sh which are sourced by my .bash_profile
In this change the environment variable CASROOT ... which were generated  during the installation of  CAS has  been lost. The second time I have tried to install netgen (with the netgen-4.5.sh patched) it failed because the wizard was not able to find directory for the CAS/include files.

So now the problem is:
how can I regenerate the env_build.sh and env_products.sh files with all the variables setted according to my installation without rebuilding everithing.

Walter

Re: salome 3.2.2 on suse 10.0

Posted by Igor Nazarov at October 05. 2006
Dear Walter,

It seems you have problems with environment because after I have updated netgen4.5.sh by string above I compiled netgen. Nevertheless try to update netgen4.5.sh and compile netgen from Install Wizard.

I suggest to do it the following way:

1. Update netgen4.5.sh file
2. Start Installation Wizard
3. Press Unselect All buttons
4. Select netgen / install sources (all depended products will be selected automatically)
5. Start installation


Re: salome 3.2.2 on suse 10.0

Posted by walter steffe at October 05. 2006
I have already done all the 5 steps you are suggesting. And the results is the list of errors I showed in my previous post. The reason is that, this morning I had already done an installation of netgen only (that is pass 2 to 5 in your list) and I have observed that by doing that the wizard rewrites the two environment files. The old file are lost and so all the variables (like CASROOT) related to the CAS environment. The CAS variables are not written in the new env files because the wizard has installed only netgen. So when I repeat the installation of netgen it fails because the env variables are not complete and the wizard is not able to find the include files that are needed by netgen. In fact at the and of the pass 1 to 5 I got the following errors: In file included from ../../libsrc/include/occgeom.hpp:1, from occgeom.cpp:5: ../../libsrc/include/../occ/occgeom.hpp:14:25: error: BRep_Tool.hxx: No such file or directory ../../libsrc/include/../occ/occgeom.hpp:15:26: error: Geom_Curve.hxx: No such file or directory .....

Re: salome 3.2.2 on suse 10.0

Posted by walter steffe at October 05. 2006
I forgot to say that beyond what you suggest in steps 1-5 I have also deselected CAS which has been automatically selected as a prerequisite (otherwise I would have to wait a long time for the recompilation of CAS). by Walter

Re: salome 3.2.2 on suse 10.0

Posted by Vadim SANDLER at October 05. 2006
It's OK that you deselect CASCADE also when installing netgen. But you should point the same instrallation directory where you previously installed SALOME.

And, to be sure, please check that your CAS-6.1 folder contains env_OpenCascade.sh file and this file is correct (i.e. not empty, etc...).
If this file does not exist or bad the Installation Wizard will fail to find it and thus compile netgen from sources.


Regards,
Vadim.

Re: salome 3.2.2 on suse 10.0

Posted by walter steffe at October 05. 2006
The CAS-6.1 folder contains env_OpenCascade.sh and it seems ok
I am pointing always to the same directory which was defined in  the file config.xml (and never changed).
Nevertheless the netgen installazion fails to find the include file that are in the directory CAS-6.1/inc
The netgen (only) installation was succesfull only the first  time when the files env_build.sh and env_pruducts.sh
in INSTALL_ROOT were that one generated in the previous run of runInstall (when I have compiled and installed CAS).
So I suppose that the change of these files (which now do not define anymore the CASROOT) is the reason of the failure of
the subsequent netgen installations.

Anyway now I am lunching again the whole installation process (after having Updated netgen4.5.sh)  and if all goes ok
tomorow morning the new installation will be finished and the env files will be aligned with the installation.

Re: salome 3.2.2 on suse 10.0

Posted by walter steffe at October 06. 2006

Hello

After having update the netgen4.5.sh file I have rebuilt all using the install wizard and all was ok.

I have installed only the prerequisite packages and I have deselected the Salome  modules  because I wanted to build them with build.csh.

So after the rinInstall I have performed also a run of build.csh.
All the Salome modules were compiled correctly with the exception of NETGENPLUGIN which failed to build the configure script.
In the build_configure_NETGENPLUGIN.log there is the following error:

Creating new file 'configure.in' ... done
Creating 'configure' script ...  aclocal: couldn't open directory `/home/walter/local/Salome/salome_3.2.2/SMESH_BUILD/adm_local/unix/config_files': No such file or directory

But this directory is present in my installation so I do not understand the message.
I think that the missing of the NETGENPLUGIN is not very important to me because I need to generate only 2D meshes with mephisto.

To test the installation I have run salome and I have bulit a simple cube in the geo module. Then I have swithed to the mesh module but I was not able to generate the 2D mesh. After having selected the 2D hypotesis I have pressed the 'compute' buttom but nothing happened.
In the install wizard I have noticed a warning message (during the make of SMESH) that complained the missing of a SMESH lib (now I do not remember which one but I have checked that it was present in the directory SMESH_BUILD/lib/salome). The message was also saying to define the load path trough  -RPATH or LD_LIBRARY_PATH.  So I suspect that salome is not able to generate the mesh because I do not have completed this task. May you please give me a list of directories (such as MODULE_ROOT_DIR/....)  that have to add to my  LD_LIBRARY_PATH. At the moment I have defined only the various MODULE_ROOT_DIRs (like SMESH_ROOT_DIR=${INSTALL_ROOT}/SMESH_BUILD).

Thanks
Walter
 

Re: salome 3.2.2 on suse 10.0

Posted by Vadim SANDLER at October 06. 2006
Hello Walter,

In the directory where you built the SALOME module using build.csh script should be generated the LOGS directory.
Could you please tar/gzip this directory and send to me (vadim.sander@opencascade.com)?
I will check log files to see what is the problem.

What options did you use with build.csh script?
Did you build all modules at once or separately (i.e. ran build.csh several for each module)?

Regards,
Vadim.

Re: salome 3.2.2 on suse 10.0

Posted by Vadim SANDLER at October 06. 2006
Sorry, I misprinted my email address :)
Here is the correct one: vadim.sandler@opencascade.com

Regards,
Vadim.

Re: salome 3.2.2 on suse 10.0

Posted by walter steffe at October 06. 2006

Hello Vadim

I have used the –d –c options

 

The first time I have try to build all the modules together. But the SMESH building failed because of the missing of the f77 command and of the libg2c library. To solve the first problem I have made a dynamic link of f77 with ifort (I have the INTEL fortran compiler). The second problem was solved by installation of the Suse Package compat-g77.

 

Then I have run build.csh –d –c SMESH NETGENPLUGIN GHS3DPLUGIN    (because the last two depend on SMESH)

 

 

Thanks for your help

 

 

Walter Steffè

 

Re: salome 3.2.2 on suse 10.0

Posted by walter steffe at October 06. 2006

Hy Vadim

I forgot to say that I have sent the LOG.tgz files to your E-mail.

Walter

 

Re: salome 3.2.2 on suse 10.0

Posted by Vadim SANDLER at October 06. 2006
Hello Walter,

OK, I see where is the mistake.
When you restart build.csh for some module second, third, etc... time, please you -b option. Because in your caese it is necessary to re-generate configure script.
You can try now build.csh -d -b NETGENPLUGIN and it should succeed.

Regards,
Vadim.

Re: salome 3.2.2 on suse 10.0

Posted by walter steffe at October 06. 2006

Hello Vadim

You are right, now the NETGENPLUGIN has been built correctly.

Anyway I still am not able to generate the cube mesh.

I am not sure if it is a problem of the installation or it is that I am giving the wrong commands. In the 3.2.1 I was able to make the mesh but the meshing part has changed.

An other strange thing (even worse) is that when I look in the module help menu I can see only the kernel module and there is nothing about geo and mesh modules. This should be an installation problem. In fact if I remember well in the previous version (now I have removed it) had a help for all the modules.

Any idea about that ?

thanks

Walter

Re: salome 3.2.2 on suse 10.0

Posted by Vadim SANDLER at October 06. 2006
Hello Walter,

User documentaion is built by 'make install' step for the module.
To do this with build.csh script use should use either -i or -p option.

Regards,
Vadim.

Re: salome 3.2.2 on suse 10.0

Posted by walter steffe at October 06. 2006
Hello Vadim

Now the documentation is all ok.

The problem with the mesh generation seems to be a bug.

The salome crashed after having performed the following actions:
1) Open the Geo module
2) define a cube with dimension of 20x20x20.
3) switch to the mesh module
4) select create mesh
4.1) Define 1D Algo=Wire discretisation with average length=20
4.2) Define 2D Algo=Triangle (Mefisto) with Length From Edges
5) Select the mesh (Mesh_1) and press compute

Here is the relevant part of the trace messages:


.........
th. 1142204160 - Trace /home/walter/local/Salome/salome_3.2.2/SMESH_SRC_3.2.2/src/MEFISTO2/aptrte.cxx [374] : Temps de l'ajout arbre-4 des Triangles Equilateraux=0.01 secondes
th. 1142204160 - Trace /home/walter/local/Salome/salome_3.2.2/SMESH_SRC_3.2.2/src/MEFISTO2/aptrte.cxx [395] : Temps de l'adaptation et l'homogeneisation de l'arbre-4 des TE=0 secondes
forrtl: severe (408): fort: (2): Subscript #1 of the array NUTR has value 2 which is greater than the upper bound of 1

Image              PC        Routine            Line        Source
libifcore.so.5     4DD7BAF8  Unknown               Unknown  Unknown
libifcore.so.5     4DD79914  Unknown               Unknown  Unknown
libifcore.so.5     4DD7987C  Unknown               Unknown  Unknown
libifcore.so.5     4DD01419  Unknown               Unknown  Unknown
libifcore.so.5     4DD0161E  Unknown               Unknown  Unknown
libMEFISTO2D.so.0  4F34B061  Unknown               Unknown  Unknown
libMEFISTO2D.so.0  4F342F0D  Unknown               Unknown  Unknown
libMEFISTO2D.so.0  4F31F227  Unknown               Unknown  Unknown
libMEFISTO2D.so.0  4F30F4FA  Unknown               Unknown  Unknown
libStdMeshers.so.  4F2CF822  Unknown               Unknown  Unknown
libSMESHimpl.so.0  4D86FC72  Unknown               Unknown  Unknown
libSMESHimpl.so.0  4D8484B0  Unknown               Unknown  Unknown
libSMESHEngine.so  4E268BDB  Unknown               Unknown  Unknown
libSMESH.so        4C233E4E  Unknown               Unknown  Unknown
libomniORB4.so.0   40CD8ABB  Unknown               Unknown  Unknown
libomniORB4.so.0   40CBCFAD  Unknown               Unknown  Unknown
libomniORB4.so.0   40CCF1FA  Unknown               Unknown  Unknown
libSMESH.so        4C2370F7  Unknown               Unknown  Unknown
libSMESH.so        4C0361D9  Unknown               Unknown  Unknown
libSMESH.so        4C025C2B  Unknown               Unknown  Unknown
....


I am sorry but I do not know how to get e better debug info.
I have tried with gdb but it doesn't work because runSalome is not an executable file.
May be you already now where is the array NUTR that was indexed out of its bounds.

Regards
Walter

Re: salome 3.2.2 on suse 10.0

Posted by walter steffe at October 06. 2006
sorry the Average length for the wire discretization was 3 and not 20 as stated before

Walter

Re: salome 3.2.2 on suse 10.0

Posted by walter steffe at October 06. 2006
even If I am not able to debug this code I am quite sure that the bug is inside the file:
SMESH_SRC_3.2.2/src/MEFISTO2/trte.f

In fact there there is the nutr array and there is the very strange routine
      subroutine trpite( letree, pxyd,
     %                   mosoar, mxsoar, n1soar, nosoar,
     %                   moartr, mxartr, n1artr, noartr,
     %                   noarst,
     %                   nbtr,   nutr,   ierr )

which receives the array declared as nutr(1:nbtr)

and then it makes the call:
               call tr3str( np, nt,
     %                      mosoar, mxsoar, n1soar, nosoar,
     %                      moartr, mxartr, n1artr, noartr,
     %                      noarst,
     %                      nutr(nbtr+1),  ierr )


When it sees this call the compiler must generate an error for sure
(the fortran code is compiled with -check option).

walter





Re: salome 3.2.2 on suse 10.0

Posted by Ulf Senechal at November 02. 2006
Hi,

I'm trying to compile salome 3.2.2 on a 64 bit linux machine with gcc 4.1.0 (suse 10.1). Semms that there is a problem with cpp...

mttpc187:/work/salome_3.2.2 # source env_products.sh
mttpc187:/work/salome_3.2.2 # cd KERNEL_BUILD/
mttpc187:/work/salome_3.2.2/KERNEL_BUILD # ../KERNEL_SRC_3.2.2/build_configure
====================================================== aclocal
====================================================== libtoolize
====================================================== autoconf
====================================================== automake
mttpc187:/work/salome_3.2.2/KERNEL_BUILD # ../KERNEL_SRC_3.2.2/configure --prefix=/home/salome/KERNEL_install
checking build system type... x86_64-suse-linux
checking host system type... x86_64-suse-linux
checking target system type... x86_64-suse-linux
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes

---------------------------------------------
Initialize source and build root directories
---------------------------------------------


Source root directory : /work/salome_3.2.2/KERNEL_SRC_3.2.2
Build root directory : /work/salome_3.2.2/KERNEL_BUILD


============================================================
testing general mandatory products - for all configurations
============================================================

checking for sh... /bin/sh
checking for ar... ar

---------------------------------------------
testing make
---------------------------------------------

checking whether make sets $(MAKE)... (cached) yes
checking for a BSD-compatible install... /usr/bin/install -c

---------------------------------------------
Configuring production
---------------------------------------------

checking wether /usr/local/bin/g++ accepts -Wno-deprecated... yes
checking wether /usr/local/bin/g++ accepts -Wparentheses... yes
checking wether /usr/local/bin/g++ accepts -Wreturn-type... yes
checking wether /usr/local/bin/g++ accepts -Wmissing-declarations... no
checking wether /usr/local/bin/g++ accepts -fmessage-length=0... yes
checking wether /usr/local/bin/g++ accepts -Wunused... yes
checking wether /usr/local/bin/g++ accepts -pipe... yes

---------------------------------------------
testing libtool
---------------------------------------------

checking for style of include used by make... GNU
checking for gcc... /usr/local/bin/gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether /usr/local/bin/gcc accepts -g... yes
checking for /usr/local/bin/gcc option to accept ANSI C... none needed
checking dependency style of /usr/local/bin/gcc... gcc3
checking for a sed that does not truncate output... /usr/bin/sed
checking for egrep... grep -E
checking for ld used by /usr/local/bin/gcc... /usr/x86_64-suse-linux/bin/ld
checking if the linker (/usr/x86_64-suse-linux/bin/ld) is GNU ld... yes
checking for /usr/x86_64-suse-linux/bin/ld option to reload object files... -r
checking for BSD-compatible nm... /usr/bin/nm -B
checking whether ln -s works... yes
checking how to recognise dependent libraries... pass_all
checking how to run the C preprocessor... /lib/cpp
configure: error: C preprocessor "/lib/cpp" fails sanity check
See `config.log' for more details.

Is there any solution?
thanks,
Ulf

Powered by Ploneboard
Document Actions