OpenModelica configure script doesn't check for compatibility with MMC+RML configuration

[Bill Janssen]

On Darwin 10.5, mmc auto-senses a configuration of x86_64-darwin-gcc, while OpenModelica autosenses the equivalent of x86-darwin-gcc. This means that the data structures generated by rml won't match up with the expectations of the rest of the OpenModelica code, resulting, without any compile errors, in a horribly broken omc. Perhaps the configure file for OM could include a compatibility check with the rml installation.

[Adrian Pop]

I don't think the OpenModelica's configure needs to detect 64 vs. 32 bit.
There are places in the SimulationRuntime/c code where we check for _LP64 and define
the size of things we use accordingly. Maybe the weird GCC on MacOS X does not define this?

[Bill Janssen]

Which "weird GCC" where you thinking of? The gcc in Xcode 4 is indeed weird, based on llvm. However, I'm using fairly vanilla gcc from Xcode 3, on Darwin 9.8.0 (Mac OS X 10.5.8). When I configure and build mmc right from Subversion, I get an auto-detected --build flag of "x86_64-darwin-gcc", which works fine for compiling and building, but selects a config.h file which defines

{{{typedef long rml_sint_t;
typedef unsigned long rml_uint_t;
#define RML_LOG2_SIZE_INT 3
#define RML_SIZE_INT 8
#define RML_SIZE_DBL 8
}}}

And I get the odd omc with binary trash in it that I was complaining about. Note that when I look at config.status from OpenModelica, it says that the OPENMODELICA_SPEC_PLATFORM is "darwin-i386".

If, for mmc, I select "--build x86-darwin-gcc" instead, I get a config.h with

{{{typedef int rml_sint_t;
typedef unsigned int rml_uint_t;
#define RML_LOG2_SIZE_INT 2
#define RML_SIZE_INT 4
#define RML_SIZE_DBL 8
}}}

And this seems to work.

The code in mmc/etc/config.guess that figures out the architecture is

{{{ Darwin)

OPSYS=darwin
OSX64=sysctl hw | grep -q "^hw.cpu64bit_capable: 1\$" && echo _64
case uname -m in

Power\ Macintosh) ARCH=ppc;;
i[3456]86) ARCH=x86$OSX64;;
x86_64) ARCH=x86_64;;
*) exit 1;;

esac

;;

}}}

The code in OpenModelica's configure.in is this:

{{{# I don't really agree with the Modelica specification since "Intel 32-bit" is
# very unspecific.
# Also, they forgot about Mac users. We will just default to uname -sm and patch
# to Modelica Spec standards as well.
OPENMODELICA_SPEC_PLATFORM=uname -sm | tr "@<:@:upper:@:>@ " "@<:@:lower:@:>@-"
AC_MSG_RESULT([$OPENMODELICA_SPEC_PLATFORM])
AC_MSG_CHECKING([for Modelica platform name])
if test "$OPENMODELICA_SPEC_PLATFORM" = "linux-x86_64" -o "$OPENMODELICA_SPEC_PLATFORM" = "linux-i.86"; then

MODELICA_SPEC_PLATFORM=echo $OPENMODELICA_SPEC_PLATFORM | sed "s/linux-x86_64/linux64/" | sed "s/linux-i.86/linux32/"

else

MODELICA_SPEC_PLATFORM=$OPENMODELICA_SPEC_PLATFORM

fi
AC_MSG_RESULT([$MODELICA_SPEC_PLATFORM])
}}}

"uname -sm" on this platform simply says, "Darwin i386". It doesn't play the cute little trick of looking at "sysctl" for more insight.

So, I'm just pointing out that these have to agree, because making this work depends on both having the same idea of how big an int is.

[Martin Sjölund]

Stupid train made me lose my comment.

The gist of it is: RML is wrong, not the OpenModelica build system. The OpenModelica build system configure does not care about this stuff. The platform is only used for the directory names in FMI - nothing else.

The RML configure script should probably add -m64 to CFLAGS because older OSX versions reported the wrong "uname -m" (says it is x86 even when gcc defaults to x86_64).

[Bill Janssen]

I think the bug is that when they don't agree, gibberish gets spit at the screen when you try to run omc. Whether the fix is to change RML or to change OpenModelica is up to you folks.

[Adrian Pop]

The fix is up to whoever has OSX :) and commit access so he/she can test the fix.
As I don't have such a platform and probably never will, I can't do anything about this.
Feel free to hack the RML/MMC configure.

[Martin Sjölund]

I added -m64 to the CFLAGS for 64-bit capable OSX. Maybe it will work, maybe it won't. I also added an assertion that checks the sizeof(void*) and compares it to the assumed size of void* in the rml.h. So even if it doesn't work, you should now get an assertion thrown instead of gibberish.

Note that I do not know of anyone who still runs 32-bit x86 OSX, so I cannot test this myself.

[Bill Janssen]

I'll try it, though probably not till next week. Thanks.

[Bill Janssen]

I'm trying this out. I think the problem still exists.

I see the -m64 flag on MMC, but that wasn't the problem. It correctly saw, already, that the compiler and platform was 64-bit capable. It's OpenModelica that's sensing it as 32-bit, because uname -m returns i386. That's where the -m64 flag is needed.

[Martin Sjölund]

I'll just close this as rml-mmc doesn't even build on OSX 10.9 and we are using the bootstrapped compiler.