gdl
gdl copied to clipboard
gnudatalanguage
[WIP] macOS dmg release
just tried the most recent artefact dmg and still the same problem with MPI_INIT and references to /usr/local/Cellar/...
sarabas@atmos-sarabas /Applications % ./GNU\ Data\ Language.app/Contents/Resources/bin/gdl
GDL - GNU Data Language, Version 1.0.0 Git
- For basic information type HELP,/INFO
- Default library routine search path used (GDL_PATH/IDL_PATH env. var. not set): /Users/runner/work/gdl/install/share/gnudatalanguage/lib
- Using WxWidgets as graphics library (windows and widgets).
- No startup file read (GDL_STARTUP/IDL_STARTUP env. var. not set).
- Please report bugs, feature or help requests and patches at: https://github.com/gnudatalanguage/gdl
--------------------------------------------------------------------------
Sorry! You were supposed to get help about:
opal_init:startup:internal-failure
But I couldn't open the help file:
/usr/local/Cellar/open-mpi/4.1.1_2/share/openmpi/help-opal-runtime.txt: No such file or directory. Sorry!
--------------------------------------------------------------------------
--------------------------------------------------------------------------
Sorry! You were supposed to get help about:
orte_init:startup:internal-failure
But I couldn't open the help file:
/usr/local/Cellar/open-mpi/4.1.1_2/share/openmpi/help-orte-runtime: No such file or directory. Sorry!
--------------------------------------------------------------------------
--------------------------------------------------------------------------
Sorry! You were supposed to get help about:
mpi_init:startup:internal-failure
But I couldn't open the help file:
/usr/local/Cellar/open-mpi/4.1.1_2/share/openmpi/help-mpi-runtime.txt: No such file or directory. Sorry!
--------------------------------------------------------------------------
*** An error occurred in MPI_Init
*** on a NULL communicator
*** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort,
*** and potentially your MPI job)
[atmos-sarabas:82119] Local abort before MPI_INIT completed completed successfully, but am not able to aggregate error messages, and not able to guarantee that all other processes were killed!
sarabas@atmos-sarabas /Applications %
@GillesDuvert I just got my new M1 macbook last week and I'm working on it. It was a big pain in the ass developing dmg release without a working mac, but now resolved.
@GillesDuvert I just got my new M1 macbook last week and I'm working on it. It was a big pain in the ass developing dmg release without a working mac, but now resolved.
I can figure :smile:
It would be helpful to distribute .DMGs for GDL and get rid of build problems, see recent issues. @pjb7687 Could we close this with a valid GDL MacOSX .dmg even if it does not contain the workbench? And eventually open a new PR for adding the workbench? After all, gdl works ok in a OSX basic terminal. Also, perhaps the Github Continuous Integration machines have an M1, so we could have also available an M1 version of the .DMG ?
Also, perhaps the Github Continuous Integration machines have an M1, so we could have also available an M1 version of the .DMG ?
IIUC, no M1 support yet: https://github.com/actions/runner-images/issues/2187
@pjb7687 This is 99% OK but unfortunately the bundle lacks what has ben made with the Windows installer, i.e., define the 3 fundamental environmement variables:
-
GDL_PATH -> "+$BUNDLE_LOCATION/share/gnudatalanguage/lib"(note the '+') -
GDL_MAPS_DIR -> "$BUNDLE_LOCATION/share/gnudatalanguage/resource/maps - and the more obscure but badly needed
PLPLOT_DRV_DIR -> "$BUNDLE_LOCATION/share/gnudatalanguage/drivers"
Ideally the environment variables should be defined in Info.plist but the documentation is more than contradictory, seems to depend from the OSX version, and I've not succeded to make the gdl app behave using this solution.
If one cannot just 'copy' the bundle in Applications and use it from the box, then we are in trouble,as the dmg solution is not a good one, and and installer must be preferred...
If all is well installed, the inside gdl, typing print getenv("PLPLOT_DRV_DIR") one should get
"[whatever is $BUNDLE_LOCATION]/share/gnudatalanguage/drivers"
I suspect all this can be avoided if GDL was compiled with internal paths relative to the location of the excutable, not the traditional unix fixed installation path, but it is anotehr story...