SpringFrictionPendulum1D not working on Ubuntu 18.04 about fmizoo.jl HOT 12 CLOSED

Dear @ufechner7,
yes you are right, we are only testing against Ubuntu latest (which should be 22.04. LTS I think). We cannot provide FMUs that work with all available OS versions. But: We are working on the possibility to automatically compile OS-dependent FMUs form C-source (which should fix your issue), but this may need some more time until we can provide a stable implementation.

Best regards!

from fmizoo.jl.

Well, but this issue could easily be fixed by linking to an older version of glibc because glibc is backwards compatible.
Despite the long history of compatibility and its almost magical ability to keep old programs running, there is one scenario that compatibility can't solve. You can't run a new program on an old glibc. Well, that's not exactly true. You can build a new program that's intended to run on an old glibc if you have a copy of that old glibc and its headers around. The easiest way to do that is to install an older operating system that has the version of glibc you want, which is the typical advice of "build on the oldest platform you want to support," possibly using a more modern toolset (gcc et al.), such as Red Hat's Developer Toolset, which was created for this purpose. That way, the new program depends only on compatibility symbols that are available in that old glibc and any newer glibc. Older glibcs cannot, of course, know the future.

https://developers.redhat.com/blog/2019/08/01/how-the-gnu-c-library-handles-backward-compatibility#plan_ahead

from fmizoo.jl.

Sorry, wrong button :-)

from fmizoo.jl.

If you say you have only a build machine with Ubuntu 22.04, this issue could be solved by using a docker container to build the binaries. Can you point me to the build job that is currently creating the binaries?

from fmizoo.jl.

The FMUs are exported (so compiled) from Dymola 2022X, so there is no build job. Unfortunately, the FMUs are not source-code FMUs (no C-source included in the archive), so they can't be build for another platform.

@dafred94 could we replace the current FMUs with source-code FMUs? (this would be a good idea in general)

from fmizoo.jl.

FYI @ufechner7 if we had source code FMUs, you could:

1. Rename the *.fmu with *.zip
2. Unpack
3. Find the source code and makefile inside the archive, build for whatever OS/version you need the FMU

from fmizoo.jl.

As far as I see the purpose of this FMU is just to have an example to test the Julia import. Can't we use OpenModelica for this purpose: https://openmodelica.org/doc/OpenModelicaUsersGuide/v1.11.0/fmi.html
I can run OpenModelica on my Ubuntu 18.04 computer...

from fmizoo.jl.

Best thing would be to use both I think. The good thing with Dymola is, that it is (almost) always up-to-date with the current FMI-specification (like for example with the new FMI3-release) and we use it in many of our use-cases. As said, I would suggest to use both, FMIZoo.jl provides the ability to add new tools in the folder hierarchy (that is similar to the FMI-crosschecks).

from fmizoo.jl.

we provide source code FMUs in the next release, see branch "sourcecode_fmus"

from fmizoo.jl.

Version 0.2.0 provides source-code FMUs, these include source code and a makefile to build FMUs on your own :-)
(you can unzip the FMU file by renaming it from *.fmu to *.zip and find the files under the sources-folder)

Does this resolve the issue for you?

Best regards!

from fmizoo.jl.

Is this still open @ufechner7 ?

from fmizoo.jl.