#5261 closed defect (fixed)
OM Won't build under MacOS 10.14
Reported by: | Adam Dershowitz | Owned by: | Martin Sjölund |
---|---|---|---|
Priority: | blocker | Milestone: | 1.14.0 |
Component: | Build Environment | Version: | |
Keywords: | Cc: | Martin Sjölund, Andreas Heuermann |
Description
I just upgraded my mac to 10.14 Mojove. This was released about 3 months ago, so is stable. I now can't get OM to install with Macports.
The first error seemed to be missing headers. I've attached the build log as main1.log. It seems that OM is searching for headers related to 3rd party build in /usr/include, and Apple has moved them. Based on this https://silvae86.github.io/sysadmin/mac/osx/mojave/beta/libxml2/2018/07/05/fixing-missing-headers-for-homebrew-in-mac-osx-mojave/, I followed those instructions to install the additional headers, and the build get's further.
But,this doesn't seem like a long term solution, since this is a short-term apple work around. Additionally, I believe that OM should be using "parser.h" from either macports (it is located here: /opt/local/include/libxml2/libxml/parser.h) or from the Openmodelica 3rd party directory, and not from /usr/include. So, these additional headers should not be necessary, and suggest that some build flag is not pointing to the correct location.
Adding the header files allowed the build to progress further, but not to complete.
I've attached the log for the build attempt after installing the headers above. I see that make gets to 100%, but the build doesn't actually complete. Any suggestions for getting this working?
Thanks,
Attachments (4)
Change History (39)
by , 6 years ago
comment:1 by , 6 years ago
Milestone: | Future → 1.14.0 |
---|---|
Priority: | high → blocker |
comment:2 by , 6 years ago
I have tried a few different compilers as well.
It seems that clang3.8 port is no longer available. But, I tried clang7, and got the same results. I also tried gcc5 and again it would not build successfully.
comment:3 by , 6 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
Problem with building OMSimulator.
The other problem seems to be that OSX changed their C++ standard library implementation again (we manually set the C++ implementation to use, which no longer seems available)...
comment:5 by , 6 years ago
I had not tried in a while, but I just tried to build OM again, and it does still fail. I don't think that the log is identical, so I've attached the new log.
comment:7 by , 6 years ago
https://github.com/OpenModelica/OMSimulator/pull/671 might be fixed soon
comment:8 by , 6 years ago
I just tried again (2 hrs after your edit) and it still fails. I'm not sure if that was a long enough wait for the fix to propagate. It is trying to build: openmodelica_1.14.0~dev-5886-gb54f826
I can post the updated the log if that might be helpful.
comment:10 by , 6 years ago
It's now been merged. The job had a random failure yday and didn't merge.
comment:11 by , 6 years ago
It still doesn't build. But, it looks like it is a different problem. Here's the last part of the log file:
:info:build In file included from Modeling/FunctionArgumentDialog.cpp:34: :info:build In file included from Modeling/LibraryTreeWidget.h:38: :info:build In file included from ./OMC/OMCProxy.h:38: :info:build In file included from ../../../build/include/omc/scripting-API/OpenModelicaScriptingAPIQt.h:2: :info:build In file included from ../../../build/include/omc/scripting-API/OpenModelicaScriptingAPI.h:3: :info:build In file included from ../../../build/include/omc/c/meta/meta_modelica.h:49: :info:build In file included from ../../../build/include/omc/c/meta/../gc/omc_gc.h:150: :info:build ../../../build/include/omc/c/meta/../gc/../meta/meta_modelica_segv.h:69:88: warning: unused parameter 'oldThreadData' [-Wunused-parameter] :info:build static inline void mmc_init_stackoverflow_fast(threadData_t *threadData, threadData_t *oldThreadData) :info:build ^ :info:build Modeling/ModelWidgetContainer.cpp:3443:3: error: use of undeclared identifier 'QDesktopServices' :info:build QDesktopServices::openUrl(url); :info:build ^ :info:build 1 warning and 1 error generated. :info:build make[3]: *** [ModelWidgetContainer.o] Error 1 :info:build make[3]: *** Waiting for unfinished jobs.... :info:build 1 warning generated. :info:build 1 warning generated. :info:build 6 warnings generated. :info:build 40 warnings generated. :info:build 1 warning generated. :info:build 1 warning generated. :info:build 1 warning generated. :info:build make[3]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_build.openmodelica.org_macports_lang_openmodelica-devel/openmodelica-devel/work/openmodelica_1.14.0~dev-5894-g6c4f794/OMEdit/OMEdit/OMEditGUI' :info:build make[2]: *** [OMEdit] Error 2 :info:build make[2]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_build.openmodelica.org_macports_lang_openmodelica-devel/openmodelica-devel/work/openmodelica_1.14.0~dev-5894-g6c4f794/OMEdit/OMEdit/OMEditGUI' :info:build make[1]: *** [omedit] Error 2 :info:build make[1]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_build.openmodelica.org_macports_lang_openmodelica-devel/openmodelica-devel/work/openmodelica_1.14.0~dev-5894-g6c4f794/OMEdit' :info:build make: *** [omedit.skip] Error 2 :info:build make: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_build.openmodelica.org_macports_lang_openmodelica-devel/openmodelica-devel/work/openmodelica_1.14.0~dev-5894-g6c4f794' :info:build Command failed: cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_build.openmodelica.org_macports_lang_openmodelica-devel/openmodelica-devel/work/openmodelica_1.14.0~dev-5894-g6c4f794" && /usr/bin/make -j8 -w :info:build Exit code: 2 :error:build Failed to build openmodelica-devel: command execution failed :debug:build Error code: CHILDSTATUS 12979 2 :debug:build Backtrace: command execution failed :debug:build while executing :debug:build "system {*}$notty {*}$nice $fullcmdstring" :debug:build invoked from within :debug:build "command_exec build" :debug:build (procedure "portbuild::build_main" line 8) :debug:build invoked from within :debug:build "$procedure $targetname" :error:build See /opt/local/var/macports/logs/_opt_local_var_macports_sources_build.openmodelica.org_macports_lang_openmodelica-devel/openmodelica-devel/main.log for details.
I can attach the whole file if that is more useful.
comment:12 by , 6 years ago
I think I need the whole file because I could compile fine with macports + Qt4 on Mojave. Maybe I use the XCode C-compiler though, and only gfortran from macports.
by , 6 years ago
Attachment: | main.2.log added |
---|
comment:13 by , 6 years ago
I've attached the full log. I just attempted a default install:
sudo port install openmodelica-devel
Which, I think, does use the Xcode C-compiler, although I'm not sure.
comment:14 by , 6 years ago
I have:
$ clang++ --version Apple LLVM version 10.0.1 (clang-1001.0.46.4) $ port info qt4-mac qt4-mac @4.8.7_8 (aqua)
And running the same command that fails for you, succeeds for me.
comment:15 by , 6 years ago
Me too:
$ clang++ --version Apple LLVM version 10.0.1 (clang-1001.0.46.4) Target: x86_64-apple-darwin18.5.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin $ port info qt4-mac qt4-mac @4.8.7_8 (aqua)
Some other port, library, header file getting involved?
In the last day or two, I upgraded libgcc port from 2.0_0 to 2.0_1 and libgcc8 from 8.3.0_4 to 8.3.0_5 which also installed libgcc9. Could that be at all related?
comment:16 by , 6 years ago
Never mind. I didn't have the git repo updated on my Mac. It's a new bug for compiling Qt4 introduced sometime around the 30th.
comment:17 by , 6 years ago
https://github.com/OpenModelica/OpenModelica/commit/b3569f0d6ee71734591c4442f4b464280c7fbe97 was the culprit (broke qt4). It's an easy fix to add the include though.
comment:18 by , 6 years ago
Has this change been implemented? I'm not sure which header needs to be included in which file?
comment:19 by , 6 years ago
comment:20 by , 6 years ago
That fixed it...mostly. But, not completely:
When I try to install macports does the expected: Build, Stage, Install and activate. Then, at the end, it does a scan, as expected. But, it returns this:
---> Activating openmodelica-devel @1.14.0~dev-5912-g3e23ece_0+gfortran5+libraries+omnotebook+qt ---> Cleaning openmodelica-devel ---> Scanning binaries for linking errors ---> Found 5 broken files, matching files to ports ---> Found 1 broken port, determining rebuild order You can always run 'port rev-upgrade' again to fix errors. The following ports will be rebuilt: openmodelica-devel @1.14.0~dev-5912-g3e23ece+gfortran5+libraries+omnotebook+qt Continue? [Y/n]:
If I say yes, it just tries a full compile again and continues three times, then fails.
I checked on what caused the failure:
sudo port -d -y rev-upgrade
And, it reports this:
Could not open libsundials_nvecserial.0.dylib: Error opening or reading file (referenced from /opt/local/lib/x86_64-darwin18.5.0/omc/omsi/libOMSIBase.dylib) libsundials_nvecserial.0.dylib seems to be referenced using a relative path. This may be a problem with its canonical library name and require the use of install_name_tool(1) to fix. DEBUG: Marking /opt/local/lib/x86_64-darwin18.5.0/omc/omsi/libOMSIBase.dylib as broken Could not open libsundials_kinsol.1.dylib: Error opening or reading file (referenced from /opt/local/lib/x86_64-darwin18.5.0/omc/omsi/libOMSIBase.dylib) libsundials_kinsol.1.dylib seems to be referenced using a relative path. This may be a problem with its canonical library name and require the use of install_name_tool(1) to fix. DEBUG: Marking /opt/local/lib/x86_64-darwin18.5.0/omc/omsi/libOMSIBase.dylib as broken Could not open libOMSISolver.dylib: Error opening or reading file (referenced from /opt/local/lib/x86_64-darwin18.5.0/omc/omsi/libOMSIBase.dylib) libOMSISolver.dylib seems to be referenced using a relative path. This may be a problem with its canonical library name and require the use of install_name_tool(1) to fix. DEBUG: Marking /opt/local/lib/x86_64-darwin18.5.0/omc/omsi/libOMSIBase.dylib as broken DEBUG: Marking /opt/local/lib/x86_64-darwin18.5.0/omc/omsi/libOMSISolver.dylib as broken DEBUG: Marking /opt/local/lib/x86_64-darwin18.5.0/omc/omsi/libOMSISolver.dylib as broken ---> Found 5 broken files, matching files to ports ---> Found 1 broken port, determining rebuild order DEBUG: Broken: openmodelica-devel DEBUG: Processing port openmodelica-devel @20190510:1.14.0~dev-5912-g3e23ece_0 +gfortran5+libraries+omnotebook+qt You can always run 'port rev-upgrade' again to fix errors. The following ports will be rebuilt: openmodelica-devel @1.14.0~dev-5912-g3e23ece+gfortran5+libraries+omnotebook+qt Continue? [Y/n]:
However, if I run OMEdit, after the error above, it does seem to work. Although, I've only run a model or two, not much else.
So, it looks like macports "thinks" that a few files are not being referenced or installed correctly, but most (or all) of OMEdit is working. This probably means that using some features will cause a crash (kinsol?). Perhaps just minor issue in how some file(s) are referenced on a mac?
comment:21 by , 6 years ago
One other minor issue that I just wanted to make a note of is that the default install includes the basic modelica library files, but something is missing from them, so that basic examples won't run. For example I tried to run modelica->blocks->Examples->PID_Controller and it gave me an error about eps.
But, by installing with the +libraries variant, this problem goes away. So, it seems that some libraries was moved from just being in the basic openmodelica-devel port to the libraries port.
I believe that it used to be that the default variant (without +libraries) would allow examples to run. This was probably a better way to do it, since the large set of libraries are considered optional.
comment:22 by , 6 years ago
OMSI is new experimental things, so I guess they don't work as expected on OSX yet
comment:23 by , 6 years ago
Cc: | added |
---|
comment:24 by , 5 years ago
It seems that the OMSI issue is just that a relative path is being used, so that the library can't be found correctly. The problem is not that OMSI doesn't "work", but that building OM at all on a mac causes three build attempts (since each gives an error) and then finally it fails (although OM does seem to work).
But this means that installing takes three times as long as it should, and ultimately provides an error.
I think that the fix is just to get libOMSIBase.dylib to point correctly to libsundials_nvecserial.0.dylib and libsundials_kinsol.1.dylib so that it can find them.
comment:25 by , 5 years ago
The following work around allows it to no longer fail to install using macports (I haven't actually tested OMSI). After the first build attempt, when it finds the link error, select no, so that it doesn't rebuild. Then do this:
sudo install_name_tool -change libsundials_nvecserial.0.dylib /opt/local/lib/x86_64-darwin18.6.0/omc/libsundials_nvecserial.0.dylib /opt/local/lib/x86_64-darwin18.6.0/omc/omsi/libOMSIBase.dylib sudo install_name_tool -change libsundials_kinsol.1.dylib /opt/local/lib/x86_64-darwin18.6.0/omc/libsundials_kinsol.1.dylib /opt/local/lib/x86_64-darwin18.6.0/omc/omsi/libOMSIBase.dylib sudo install_name_tool -change libOMSISolver.dylib /opt/local/lib/x86_64-darwin18.6.0/omc/omsi/libOMSISolver.dylib /opt/local/lib/x86_64-darwin18.6.0/omc/omsi/libOMSIBase.dylib sudo install_name_tool -change libsundials_nvecserial.0.dylib /opt/local/lib/x86_64-darwin18.6.0/omc/libsundials_nvecserial.0.dylib /opt/local/lib/x86_64-darwin18.6.0/omc/omsi/libOMSISolver.dylib sudo install_name_tool -change libsundials_kinsol.1.dylib /opt/local/lib/x86_64-darwin18.6.0/omc/libsundials_kinsol.1.dylib /opt/local/lib/x86_64-darwin18.6.0/omc/omsi/libOMSISolver.dylib
The other problem that comes up with the current situation is that any time any other port is upgrade, macports does a scan and finds that openmodelica-devel has this path link error and tries to rebuild it (even if OM itself wasn't actually upgraded).
I think that this might be a similar problem that came up and was fixed back in these old tickets: https://trac.openmodelica.org/OpenModelica/ticket/5060 https://trac.openmodelica.org/OpenModelica/ticket/2680 and https://trac.openmodelica.org/OpenModelica/ticket/3378
comment:27 by , 5 years ago
Since OMSI can't generate a working Makefile for FMUs on mac yet I will probalby disable the module completely for mac build.
But I will also try to fix the OMSI build on Mac once and for all...
comment:28 by , 5 years ago
What's wrong with generating a working makefile for Mac? Are you using gmake
to make it run or Apple's make
?
comment:29 by , 5 years ago
@sjoelund
Just didn't start to work on it. When OMSI is sufficient advanced on Windows and Linux I will adapt current makefiles for OSX to fit needs for OMSI.
@dersh
In commit 66d141d I added
sudo install_name_tool -change libsundials_nvecserial.0.dylib /opt/local/lib/x86_64-darwin18.6.0/omc/libsundials_nvecserial.0.dylib /opt/local/lib/x86_64-darwin18.6.0/omc/omsi/libOMSIBase.dylib sudo install_name_tool -change libsundials_kinsol.1.dylib /opt/local/lib/x86_64-darwin18.6.0/omc/libsundials_kinsol.1.dylib /opt/local/lib/x86_64-darwin18.6.0/omc/omsi/libOMSIBase.dylib sudo install_name_tool -change libOMSISolver.dylib /opt/local/lib/x86_64-darwin18.6.0/omc/omsi/libOMSISolver.dylib /opt/local/lib/x86_64-darwin18.6.0/omc/omsi/libOMSIBase.dylib sudo install_name_tool -change libsundials_nvecserial.0.dylib /opt/local/lib/x86_64-darwin18.6.0/omc/libsundials_nvecserial.0.dylib /opt/local/lib/x86_64-darwin18.6.0/omc/omsi/libOMSISolver.dylib sudo install_name_tool -change libsundials_kinsol.1.dylib /opt/local/lib/x86_64-darwin18.6.0/omc/libsundials_kinsol.1.dylib /opt/local/lib/x86_64-darwin18.6.0/omc/omsi/libOMSISolver.dylib
But it still produces the error
---> Scanning binaries for linking errors Could not open libsundials_kinsol.1.dylib: Error opening or reading file (referenced from /opt/openmodelica/lib/x86_64-darwin15.4.0/omc/omsi/libOMSIBase.dylib) libsundials_kinsol.1.dylib seems to be referenced using a relative path. This may be a problem with its canonical library name and require the use of install_name_tool(1) to fix. Could not open libsundials_nvecserial.0.dylib: Error opening or reading file (referenced from /opt/openmodelica/lib/x86_64-darwin15.4.0/omc/omsi/libOMSIBase.dylib) libsundials_nvecserial.0.dylib seems to be referenced using a relative path. This may be a problem with its canonical library name and require the use of install_name_tool(1) to fix. Could not open libOMSISolver.dylib: Error opening or reading file (referenced from /opt/openmodelica/lib/x86_64-darwin15.4.0/omc/omsi/libOMSIBase.dylib) libOMSISolver.dylib seems to be referenced using a relative path. This may be a problem with its canonical library name and require the use of install_name_tool(1) to fix. ---> Found 5 broken files, matching files to ports
Tried a lot of different combinations of install_name_tool
and wasted a lot of time to make the mac build happy but didn't succeed :-/
Would be happy if one of you has a tipp for me how to proceed. Doing PR's and waiting for the OpenModelica MAC from Linköping is kinda annoying. And I don't get the osx-crosscompile docker image to run correctly.
@sjoelund What does the nightly build do, that it finds the error and the PR test don't? Would it be possible to check for wrong linking in OMCompiler on Jenkins?
comment:30 by , 5 years ago
Well, first of all your change is wrong. The build directory is not the install directory; you must use @rpath paths. I guess doing something as simple as the following would detect that in the PR:
mv build build.sanitycheck build.sanitycheck/bin/omc --version mv build.sanitycheck build
comment:32 by , 5 years ago
What might help to diagnose it is:
otool -L /opt/openmodelica/lib/x86_64-darwin15.4.0/omc/omsi/libOMSIBase.dylib
That will show you the paths that the dynamic library will use to find other libraries.
comment:33 by , 5 years ago
Oh yeah, these are all omsi libraries. So the sanity check cannot see if they are correct because we don't link with omsi by default in the simulation executable :)
comment:34 by , 5 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Issues with rpath fixed in: ba9893/OpenModelica.
Initial Build log