Ah, that helps quite a bit: the snippet below for System_5finit seems
to have done the trick for the most part, as now (after a re-
configure and re-make) 281 out of 282 tests succeeded in mofiles.
The one that failed is
+ FunctionSimplex ... equation mismatch
after
../../build/bin/omc FunctionSimplex.mo
and looking at the *.log files, all of them have for their last line:
i686-apple-darwin8-gcc-4.0.1: unrecognized option '-shared'
(first line is "gcc -shared -export-dynamic -single_module -
dynamiclib -flat_namespace ... "
I see '-shared' as a linker option in the man pages...any ideas?
Thanks again,
Jason
On Jun 20, 2008, at 6:28 PM, Adrian Pop wrote:
Hi,
This can be fixed in:
OpenModelica/Compiler/runtime/systemimpl.c
in function: System_5finit (Linux part,
second definition) with something like:
#ifdef __APPLE_CC__ /* I don't know the actual define */
set_linker("gcc -shared -export-dynamic -single_module
-dynamiclib -flat_namespace");
#endif
Then the correct flags for the
linker will be put in the makefiles.
Cheers,
Adrian Pop/
Eric Meyers wrote:
I haven't seen the makefile being used for OSX, but I'll bet it
needs -single_module -dynamiclib -flat_namespace for the shared
libraries.
Eric
On Jun 20, 2008, at 6:02 PM, Adrian Pop wrote:
Hi Jason,
We have changed the way functions are handled.
Now we generate an .so (or .dll) for the function, load
it dynamically and call it. We haven't tested this at all
on Mac OS and I think this is the reason for the failures.
It works pretty OK in Linux, Windows, and Solaris.
To obtain more information on what might be the problem do:
1) cd OpenModelica/testsuite/mofiles
2) ../../build/bin/omc Vectorizable1.mo
3) look into all *.log generated to see
how the compilation of the functions went.
Let me know how it goes as I might be able to
help and we could fix also the compilation on
MacOS.
Cheers,
Adrian Pop/
Jason Brown wrote:
Hi,
I've been going over some of the failed testsuite models under
OS X Tiger:
1. In mofiles, 261 out of 282 tests succeed; failures are:
... + Constant6 ... nonzero exit status
...
+ Vectorizable1 ... equation mismatch
+ Vectorizable2 ... equation mismatch
+ Vectorizable3 ... equation mismatch
...
+ FunctionEval1 ... equation mismatch
+ FunctionEval2 ... equation mismatch
...
+ FunctionEval9 ... equation mismatch
...
+ FunctionBubblesort ... equation mismatch
+ FunctionSimplex ... equation mismatch
+ ExternalFunction1 ... equation mismatch
+ ExternalFunction2 ... equation mismatch
+ ExternalFunction3 ... equation mismatch
...
+ MultFuncCall ... equation mismatch
...
+ EquationCall ... equation mismatch
...
+ MultipleResultsFunction ... equation mismatch
+ PolynomialEvaluator1 ... equation mismatch
...
+ FuncMultResults ... equation mismatch
...
+ EqualityEquationsCorrect ... equation mismatch
...
+ FuncDer ... equation mismatch
...
+ InOutBool ... equation mismatch
+ InOutArray ... equation mismatch
It seems like a common thing in these test cases is that
somewhere they call a function with a constant as an argument,
e.g. foo(1.2) or foo(a) where a is, e.g., "constant Real a = 1.2;"
2. In mofiles/msl, everything passes.
3. in mosfiles, 94 out of 105 tests succeeded, and for the most
part the output looks like what has been discussed in previous
posts, along with some function calls with constants as arguments.
4. in meta, everything passes.
I was wondering if anyone has had the passing constants failures
like in item #1 above under Leopard?
Thanks,
Jason
--------------------------------------------
Jason Brown
Georgia Institute of Technology
College of Architecture
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
Eric Meyers
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
--------------------------------------------
Jason Brown
Georgia Institute of Technology
College of Architecture
[EMAIL PROTECTED]
