Frama-C-discuss mailing list archives

This page gathers the archives of the old Frama-C-discuss archives, that was hosted by Inria's gforge before its demise at the end of 2020. To search for mails newer than September 2020, please visit the page of the new mailing list on Renater.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Frama-c-discuss] problem with installation of Frama-C Beryllium (2) for Mac OS X 10.5.8


> I am a new user of Frama-C. I am trying to install the Frama-C Beryllium (2)
> for Mac OS X 10.5.8 Intel (the distribution that includes Why 2.23). I have
> followed all the instructions in the README file. But I get the following
> error.
> Macintosh-2:~ nghafari$ frama-c-gui -slevel 10 first.c
> [kernel] warning: cannot load file
> "/usr/local/Frama-C_Be/lib/frama-c/plugins/._Jessie.cmxs" (dynlink error
> "error loading shared library:
> dlopen(/usr/local/Frama-C_Be/lib/frama-c/plugins/._Jessie.cmxs, 138): no
> suitable image found. ?Did find:

These files should not exist. A likely explanation is that you used a tar other
than "Apple tar", which is installed in /usr/bin/tar. I can only try to explain
these two warning and hope that the later errors have the same cause,
and thus will be fixed at the same time.

Here is my take, but this is only my guess of
what happened and why, so anyone feel free to correct me:

Apple loves to associate metadata with files. It started with "resource forks"
in the 80s and while the metadata goes by another name nowadays,
it's still the same principle and still something that filesystems other than
HFS+ cannot accomodate.

In order to avoid repeating the fiasco of the resource forks in the
80s with modern
USB disks and samba mounts, however, it was decided that the metadata
of file foo would go in a file named ._foo each time foo would be copied
to a filesystem that did not support metadata. The tar format, which was
fixed a long time ago for the excellent reason of bidirectional compatibility,
was considered like a filesystem like any other filesystem that does not
understand metadata.

The tar binary provided by Apple knows both how to encode a file metadata
into a ._ file and to recreate it when such an archive is untarred on
a filesystem
that supports it. But if you untar this file with another tar -- say, the
original GNU tar that a distribution of source packages for Mac OS X
decided to install for unfathomable reasons -- then ._ files will be created
and lay there.

In the case of Frama-C there is nothing important in these files, but Frama-C
looks for all files with the .cmxs extension in
at each launch and tries to load these files as plug-ins. Since a file such
as /usr/local/Frama-C_Be/lib/frama-c/plugins/._Jessie.cmxs is only a short
file destined to encode metadata temporarily, it is not a valid plug-in.

The solution would be to erase /usr/local/Frama-C and to make sure that
you use /usr/bin/tar for untarring it again. In fact, if my guess is correct,
it would save you other headaches to make sure that Apple's tar is
always used in preference to the other tar you have.

> Tue Apr 20 12:49:37 Macintosh-2.local frama-c-gui[1243] <Error>:
> GCGetStrikeMetrics failed: error 4.
> (frama-c-gui:1243): Pango-CRITICAL **: pango_glyph_string_set_size:
> assertion `new_len >= 0' failed
> Bus error

I have not explanation for these messages, but if my previous guess that
you use a distribution of Unix software such as MacPorts or Fink, it might
be worth trying to rename temporarily any .gtk* configuration file that you
have in your home directory before launching Frama-C. Frama-C uses
gtk+. While all the necessary libraries (compiled thanks to MacPorts)
are packaged in the archive and are installed in /usr/local/Frama-C_Be to
avoid clashes for MacPorts users, a user's personal configuration files
can still cause problems when interpreted by Frama-C's version of
these libraries (for instance if the refer to themes that are not provided
in Frama-C).

To summarize:

- are you using MacPorts?
- what does "which tar" say on your computer?
- perhaps reinstall while making sure of using Apple tar
- or perhaps you might be better served by compiling Frama-C from
sources after having used MacPorts to install all of those dependencies
it has packages for. Jens Gerlach posted a laundry list for doing that a
while ago:
Note that this message is referenced from the excellent Frama-C wiki: