Issue with Med-3.0.3 compilation

[Laurent Malod-Panisset]

Hi
 
I have an issue when compiling Med-3.0.3 on a Centos 6.0 machine, gcc 4.4
Here is the last line of the log file:
./../src/.libs/libmed.so: undefined reference to `std::basic_ostream<char, std::char_traits<char> >& std::basic_ostream<char, std::char_traits<char> >::_M_insert<unsigned long>(unsigned long)'
I attached the log file 
 
I am puzzled at the fact that i already compiled Med-3.0.3 on the same machine without an itch, and it looks (but i'm really not experienced enough, hence this message) that it could be linked to some basic compilation environment or something like that
 
Could somebody give me an hint?
Thanks in advance and have a nice day

[Yvan Fournier]

Hello,
Was the machine already running Centos 6 when you compiled MED 3.0.3 before, or some older version ?
I have heard that MED 3.0.3 does not compile correctly with gcc 4.6, but we have compiled it many times with gcc 4.4 with no issue, so I do not believe this is the problem.
Do you have multiple compiler versions on you machine (in which case forcing the choice of the C++ compiler using CXX=<correct_g++> in MED's configure may help) ?
Also, as MED 3.0.4 has been released a few days ago with SALOME 6.4, you may want to try it instead of 3.0.3, but I suspect more of a C++ compiler/libraries installation issue (such as missing developpement environment files).
Best regards,
  Yvan

[Laurent Malod-Panisset]

Hi
 
1)
I did compile Med 3.0.3 once on the same machine (same hardware, same linux) without any issue, with the standard script
However, i know that the administrator modified the install in-between my 2 attempts. I don't know what has changed.
 
2)
After a few reads on the internet and in addition to your comments, it did look like a C++ compiler/libraries issues so i switched the setup to specifically use g++
In that case,
HDF 1.8.7 has an issue before MED compilation is attempted.
So, i kept usual setup for CGNS, HDF and went g++ for MED
MED compilation fails with
/home/malodpan/Softs-Acoustic/Code-Saturne/Code_Saturne_203/installer/med-3.0.3_SRC/src/2.3.6/ci/MEDjointTypeCorres.c: In function 'med_err MEDjointTypeCorres(med_idt, char*, char*, int, med_entite_maillage*, med_geometrie_element*, med_entite_maillage*, med_geometrie_element*)': /home/malodpan/Softs-Acoustic/Code-Saturne/Code_Saturne_203/installer/med-3.0.3_SRC/src/2.3.6/ci/MEDjointTypeCorres.c:64: error: cannot convert 'med_entite_maillage' to 'med_geometrie_element' in initialization /home/malodpan/Softs-Acoustic/Code-Saturne/Code_Saturne_203/installer/med-3.0.3_SRC/src/2.3.6/ci/MEDjointTypeCorres.c:64: error: invalid conversion from 'int' to 'med_geometrie_element'
...
...
/home/malodpan/Softs-Acoustic/Code-Saturne/Code_Saturne_203/installer/med-3.0.3_SRC/src/2.3.6/ci/MEDjointTypeCorres.c:84: error: cannot convert 'med_geometrie_element' to 'med_entite_maillage' in assignment make[3]: *** [MEDjointTypeCorres.lo] Error 1
 
(finally)
 
I'm attaching the log file
Next step will be to see whether i have more luck with a Med from Code Aster or, as you suggested, Med 3.0.4.
 
Have a nice day

[Laurent Malod-Panisset]

Hi
 
1) Med with Aster
a. Aster 10.6
No issues following Aster's standard setup file and aster packages hdf-1.8.4 and Med 3.0.4
b. Aster 11.1
No issues following Aster's standard setup file and aster packages hdf-1.8.4 and Med 3.0.4
 
2) Linking Aster's Med with Code Saturne
I get the following when compiling FVM
MED >= 2.9.0 headers found configure: WARNING: no MED file support with C only link configure: error: in `/home/malodpan/Softs-Acoustic/Code-Saturne/Code_Saturne_204/installer/fvm-0.15.3.build': configure: error: MED support is requested, but test for MED failed! See `config.log' for more details
 
But that should be my inexperience at compiliing/linking here

Regards

[Yvan Fournier]

Hello,
Is the Code_Aster distribution a binary distribution ? If it is a binary distribution, chances are it is compiled in 32-bit mode (it was last time I checked, but that was a few years ago), so on a 64-bit machine, the test for MED will fail unless you force all of Code_Saturne to 32-bit mode (using the -m32 compiler option for C, C++, and Fortran compilers), which I do not recommend if you need to use meshes larger than 1.5 million elements or so.
When you forced MED to g++, did you use CC=g++ or CXX=g++ ? I would try CXX=g++, but keep CC=gcc or CC=cc (equivalent on most Linux systems, unless you have another compiler installed an an environment making it the default).
Did you try building MED 3.0.4 with Code_Saturne's configure options (either the install script switching from MED 3.0.3 to 3.0.4 in the Python script, or the manual install, using MED's configure script, make, and make install.
Also, in the latter case, did you run ./configure from the MED source directory or from a separate build directory. In recent years, (since it has been possible), I have always built in a separate directory.
Best regards,
  Yvan

[Laurent Malod-Panisset]

Hi
 
1) To cut the chase
I was always using the script provided by the Code Saturne website: I noticed MED was referring to some 3.4.x C++ libraries and wouldn't take my options.
After many trials, i decided to contact the administrator to remove the 3.4.x compatibility libraries as well as former versions of the compiler.
=> It worked great
[which is why i was previously able to build Saturne on the same machine: the 3.4.x libraries weren't probably there]
 
2) Regarding other points:
a. i used the Code Aster sources and followed the script provided by Aster. So i believe MED 3.0.4 was compiled properly by Aster, without any issue regarding the 3.4.x libraries, but i am not sure if Med was compiled or the executable copied
b. when i forced MED, i used the script and tried your recommendations BUT i believe the script never picked up my command
(when i ask to use another compiler, it wasn't picked up)
This is when i looked carefully at what was happening and understood wrong libraries were being used.
 
 
Thanks for your help: it set me in the good direction
Regards