aster-11.4.0, waf and OS X

ThomasDESOZA

Hi,

You need to patch the wscript files to pass the configure step. Have a look at the commit I mentioned in my previous post to see the required changes.

For your information I used the Python provided by Macports (essentially for the Qt4 graphic part) but it should be OK with the OS X one.

TdS

podallaire

Hi Thomas,

I'm using the Bitbucket version that you pointed in your post and adjusted wafcfg/aster_full_config.py.

It definitively works better than before but Python is creating problems for some reason, .

ThomasDESOZA

Hi,

OK then could you attach the config.log located in the "build" directory ?

TdS

podallaire

Hi there,

sure, see attached. It crashes when trying to create an executable :

['/opt/gcc-4.6.4/bin/gfortran', 'test.c.1.o', '-o', '/Users/podallaire/Downloads/codeaster-src/build/.conf_check_81e0598c8554785db2d64cd5f8a9c706/testbuild/testprog', '-L/opt/public/hdf5-1.8.10/lib', '-L/opt/public/med-3.0.7/lib', '-L/opt/public/metis-4.0.3/lib', '-L/opt/public/scotch-5.1.11_esmumps/lib', '-L/opt/public/mumps-4.10.0/lib', '-framework', 'vecLib']

err: Undefined symbols for architecture x86_64:

"_main", referenced from:

start in crt1.10.5.o

ld: symbol(s) not found for architecture x86_64

collect2: ld returned 1 exit status

Thanks for your help

Attached file:
config.log, 214898kb

ThomasDESOZA

Hi,

It serms to me that if fails because a "-arch" option is passed to gcc4.6 which is not recognized. Could yoûpost your config file ? (The python file)

TdS

podallaire

this one ?

Looks like gfortran cannot create an executable file from test.c.1.o

Might just need to tweak the config to include -lgfortranbegin

Attached file:
aster_full_config.py, 1304kb

ThomasDESOZA

OK, i understand where the error is coming from : the waf config tries to build simple programs with Python in order to determine some options. To do that, it retrieves the CFLAGS that were used to build the python interpreter.

Unfortunately, the CFLAGS used by Apple reference some GCC options that are unique to GNU compilers provided by Apple (-arch to select the type of universal binary). So unless you use the GNU compilers from Apple (which is ilpossible since they are too old) you won't be able to pass the configure step.

To workaround this, the only alternative I see is to use a manually compiled Python. Either from MacPorts (but you don't seem to be using it) or from another source (compiled yourself or retrieved from Python.org).

Good luck,

TdS

podallaire

Hi,

I worked on this in the last few days. Couple things:

- I switched to gcc 4.8;

- I compiled Python for the sources;

- I recompiled all libraries from scratch; and finally

- Got it to compile !

Unfortunately, this would have been too simple ... it crashed during the catalog build process.

After trying couple things, I decided to switch to version 12.1 from the *.tar.gz. I applied your changes to get to waf to work

and I got it to compile as well. But same result ...:

Command 'LD_LIBRARY_PATH="/opt/public/hdf5-1.8.10/lib:/opt/public/med-3.0.7/lib:/opt/public/mumps-4.10.0/lib:/opt/public/metis-4.0.3/lib:/opt/public/scotch-5.1.11_esmumps/lib:/opt/aster/12.1/lib:/opt/scotch_6.0.0/lib:/opt/metis-5.1.0/lib:/opt/CGAL-4.3/lib:/opt/boost-1.55.0/lib:/opt/gcc-4.8.2/lib:/opt/bison-2.7/lib:/opt/flex-2.5.37/bin:/opt/gsl-1.16/lib:/opt/readline-6.2/lib" ${BINDIR}/aster /opt/aster/12.1/lib/python2.7/site-packages/Execution/E_SUPERV.py -eficas_path ${PYTHONDIR} -commandes /Users/podallaire/Documents/Code_ASTER/MacInstall/12.1-Dev/aster-full-src-12.1.0/SRC/aster-12.1.0/build/release/fort.1 -memjeveux 500 -tpmax 120' returned -11

${BINDIR}/aster /opt/aster/12.1/lib/python2.7/site-packages/Execution/E_SUPERV.py -eficas_path ${PYTHONDIR} -commandes /Users/podallaire/Documents/Code_ASTER/MacInstall/12.1-Dev/aster-full-src-12.1.0/SRC/aster-12.1.0/build/release/fort.1 -memjeveux 500 -tpmax 120

Segmentation fault: 11

It reminds me the 1st time I tried to compile Aster on my Mac long time ago.

Any suggestion ?

Thanks

ThomasDESOZA

podallaire wrote:
${BINDIR}/aster /opt/aster/12.1/lib/python2.7/site-packages/Execution/E_SUPERV.py -eficas_path ${PYTHONDIR} -commandes /Users/podallaire/Documents/Code_ASTER/MacInstall/12.1-Dev/aster-full-src-12.1.0/SRC/aster-12.1.0/build/release/fort.1 -memjeveux 500 -tpmax 120

Segmentation fault: 11

It reminds me the 1st time I tried to compile Aster on my Mac long time ago.

Any suggestion ?

Good to see you're making progress. Regarding this segmentation fault, additional details will be needed to explore further.

You should read this post and post the output obtained when analyzing the core file produced by the crash.

This may give some hint as to where the error occurs in Code_Aster.

TdS

bvenkat

Good day,

I managed to compile it and run some test cases without errors, I have compiled it using gfortran 4.8.2 from macports. I will post the steps I followed to build.

Regards,

Venkat

bvenkat

Below are the steps I followed for installation on mavericks using gfortran-4.8.2 from macports. Thanks to Thomas DE SOZA for fixing various build issues.

For installing pre-requisites, I followed the instructions from:

http://www.code-aster.org/wiki/doku.php?id=en

1. Download Code_Aster testing and patched aster from:

http://www.code-aster.org/V2/spip.php?article272

https://bitbucket.org/desoza/codeaster-src/downloads

You download using a browser, you may need to unset the quatantine flag for example:

xattr -r -d com.apple.quarantine desoza-codeaster-src-b8a6166cd193.zip

2. Set paths

export PATH=/opt/local/bin:/opt/local/sbin:/opt/local/libexec/gnubin:$PATH

export MANPATH=/opt/local/man:$MANPATH

export DYLD_LIBRARY_PATH=/opt/local/lib:$DYLD_LIBRARY_PATH

3. Install pre-requisites

/opt/local/bin/port install coreutils grace nedit tcl tk python27 py27-pyqt4 py27-numpy qt-assistant wget zlib

4. Apply fix for python-2.7.6 for Python 2.7.6 from macports for the problem described at:

http://stackoverflow.com/questions/6490513/vim-failing-to-compile-with-python-on-os-x

sudo vi /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7//_sysconfigdata.py

Change the LINKFORSHARED line so that it is:

'LINKFORSHARED': '-u _PyMac_Error /opt/local/Library/Frameworks/Python.framework/Versions/2.7/Python',

5. Extract + apply patches (below commands assume the attached patches & CA sources in current directory)

tar --gunzip -xf aster-full-src-12.1.0-4.noarch.tar.gz

tar --gunzip -xf aster_patches.tar.gz

cd aster-full-src-12.1.0

patch -p1 < ../AsterMavericks/setup.patch

cd SRC/

unzip ../../desoza-codeaster-src-b8a6166cd193.zip

mv desoza-codeaster-src-b8a6166cd193 aster-12.1.0

tar --gzip -cf aster-12.1.0.tgz aster-12.1.0

tar --gunzip -xf mumps-4.10.0-aster2.tar.gz

tar --gunzip -xf scotch-5.1.11_esmumps-2.tar.gz

cd scotch-5.1.11_esmumps

patch -p3 < ../../../AsterMavericks/scotch.patch

cd ../mumps-4.10.0

patch -p3 < ../../../AsterMavericks/mumps.patch

cd ..

tar --gzip -cf scotch-5.1.11_esmumps-2.tar.gz scotch-5.1.11_esmumps

tar --gzip -cf mumps-4.10.0-aster2.tar.gz mumps-4.10.0

cd ..

6. Run the installer

python setup.py install

Attached file:
aster_patches.tar.gz, 2506kb

podallaire

Hi,

I finally re-compiled Code_Aster using these instructions after a fresh OS X Yosemite install.

I had to tweak couple things but got it all compiled with waf - thanks !

However, when trying to fun couple test cases, I realized that Aster is having issues identifying the version.

I'm getting this error message after running a simple "as_run --getversion" :

bro-mac-pod:/opt/aster/12.2/share/aster/tests podallaire$ as_run --getversion <F>_PROGRAM_ERROR 'vers' does not exist in config or options. Perhaps it must be defined in /Users/podallaire/.astkrc/prefs. Traceback (most recent call last): File "<string>", line 1, in <module> File "/opt/aster/lib/python2.7/site-packages/asrun/main.py", line 109, in main start() File "/opt/aster/lib/python2.7/site-packages/asrun/main.py", line 96, in start meth(run, *args) File "/opt/aster/lib/python2.7/site-packages/asrun/maintenance.py", line 729, in GetVersion result = get_aster_version(vers) File "/opt/aster/lib/python2.7/site-packages/asrun/maintenance.py", line 758, in get_aster_version conf = build_config_of_version(run, vers, error=False) File "/opt/aster/lib/python2.7/site-packages/asrun/config.py", line 222, in build_config_of_version version_path = run.get_version_path(label) File "/opt/aster/lib/python2.7/site-packages/asrun/run.py", line 551, in get_version_path dict_vers = self.get_versions_dict() File "/opt/aster/lib/python2.7/site-packages/asrun/run.py", line 520, in get_versions_dict if self['vers']: File "/opt/aster/lib/python2.7/site-packages/asrun/run.py", line 494, in __getitem__ '<F>_PROGRAM_ERROR') File "/opt/aster/lib/python2.7/site-packages/asrun/run.py", line 668, in Mess self.Sortie(4) File "/opt/aster/lib/python2.7/site-packages/asrun/run.py", line 708, in Sortie raise RunAsterError, exit_code

asrun.core.RunAsterError: 4

Any idea on this ?

Thanks

ThomasDESOZA

Hi,

Congratulations on making it work on Yosemite.

The error you report is likely due to a mismatch between your Aster version and as_run version. We changed the way to retrieve the version number through the Python API (after 12.1.14) and therefore as_run needs to be updated for "--getversion" to continue working.

What as_run and Aster version (or Bitbucket revision) are you running ?

TdS

podallaire

Hi,

I'm using aster-full-src-12.2.0-1.noarch.tar.gz combined with your Code Aster branch:

https://bitbucket.org/desoza/codeaster-src/downloads

I found something here to force the version, tried it and seems to be ok when I try to run the test cases:

http://www.code-aster.org/forum2/viewtopic.php?pid=42546#p42546

I'll try to update as_run as you suggested.

Note that :

- in Yosemite, vecLib seems to have been superseded by the Accelerate framework;

- I applied the tweak for copy -L -R (system_command.py);

- Tweaked common_func.py for the hosted; and

- Modified the waf settings not to build for arch i386.

Thanks

podallaire

Hey guys,

I'm back on this thread. A quick question about waf ...: is it possible to disable some of the options regarding the architecture detection ? For some reasons, waf is detecting these "arch" flags and I'm having a hard time identifying the source of this. Any way to disable this and avoid mixing i386 with x86_64 ?

------------------------------------------


Checking for python version
(2, 7, 10, 'final', 0)
['/usr/bin/python', '-c', "from distutils.sysconfig import get_config_var, get_python_lib\n\nprint(repr(get_config_var('prefix') or ''))\nprint(repr(get_config_var('SO') or ''))\nprint(repr(get_config_var('LDFLAGS') or ''))\nprint(repr(get_config_var('LIBDIR') or ''))\nprint(repr(get_config_var('LIBPL') or ''))\nprint(repr(get_config_var('INCLUDEPY') or ''))\nprint(repr(get_config_var('Py_ENABLE_SHARED') or ''))\nprint(repr(get_config_var('MACOSX_DEPLOYMENT_TARGET') or ''))\nprint(repr(get_config_var('LDSHARED') or ''))\nprint(repr(get_config_var('CFLAGS') or ''))"]
out: '/System/Library/Frameworks/Python.framework/Versions/2.7'
'.so'
'-arch i386 -arch x86_64            -Wl,-F.'
'/System/Library/Frameworks/Python.framework/Versions/2.7/lib'
'/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config'
'/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7'
''
'10.11'
'cc -bundle -undefined dynamic_lookup -arch i386 -arch x86_64            -Wl,-F.'
'-fno-strict-aliasing -fno-common -dynamic -arch i386 -arch x86_64 -g -Os -pipe -fno-common -fno-strict-aliasing -fwrapv -DENABLE_DTRACE -DMACOSX -DNDEBUG -Wall -Wstrict-prototypes -Wshorten-64-to-32 -DNDEBUG -g -fwrapv -Os -Wall -Wstrict-prototypes -DENABLE_DTRACE'

'/System/Library/Frameworks/Python.framework/Versions/2.7'
'.so'
'-arch i386 -arch x86_64            -Wl,-F.'
'/System/Library/Frameworks/Python.framework/Versions/2.7/lib'
'/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config'
'/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7'
''
'10.11'
'cc -bundle -undefined dynamic_lookup -arch i386 -arch x86_64            -Wl,-F.'

'-fno-strict-aliasing -fno-common -dynamic -arch i386 -arch x86_64 -g -Os -pipe -fno-common -fno-strict-aliasing -fwrapv -DENABLE_DTRACE -DMACOSX -DNDEBUG -Wall -Wstrict-prototypes -Wshorten-64-to-32 -DNDEBUG -g -fwrapv -Os -Wall -Wstrict-prototypes -DENABLE_DTRACE'

As a result, compiling with -arch i386 totally crashes my new system:

err: /var/folders/b4/2x_4h7q13bb_d__fj557d3xm0000gn/T//ccidyPw6.s: error: register %rbp is only available in 64-bit mode


        pushq   %rbp
                ^~~~
/var/folders/b4/2x_4h7q13bb_d__fj557d3xm0000gn/T//ccidyPw6.s: error: register %rsp is only available in 64-bit mode
        movq    %rsp, %rbp
                ^~~~
/var/folders/b4/2x_4h7q13bb_d__fj557d3xm0000gn/T//ccidyPw6.s: error: register %rbp is only available in 64-bit mode
        movl    %edi, -4(%rbp)
                         ^~~~
/var/folders/b4/2x_4h7q13bb_d__fj557d3xm0000gn/T//ccidyPw6.s: error: register %rsi is only available in 64-bit mode
        movq    %rsi, -16(%rbp)
                ^~~~
/var/folders/b4/2x_4h7q13bb_d__fj557d3xm0000gn/T//ccidyPw6.s: error: register %rbp is only available in 64-bit mode
        popq    %rbp
                ^~~~

from /Volumes/OpenFOAM/Aster/codeaster-src.V11/bibc: Test does not build: Traceback (most recent call last):

Compiling manually the test program without arch -i386 works no problem.

Thanks

mathieu.courtois

Hello

As you can see these 'arch' values are returned by your python installation (sysconfig module).

You could probably adapt it.

podallaire

Hi Mathieu,

I actually tricked "waf" by compiling and using a 64-bit version only of python that I compiled from source this way:

./configure MACOSX_DEPLOYMENT_TARGET=10.11 CFLAGS="-arch x86_64" LDFLAGS="-arch x86_64" --prefix=/opt/Python-2.7.10

Thanks

« Previous Page