Hi,
I've asked about the architecture agnostisism on the mono-developers
list and had this back
8-->
On Wed, 2006-06-14 at 09:49 +0100, PFJ wrote:
> Is there any sure fire way to detect if either a dll or binary
compiled
> with mono is platform agnostic or platform specific?
It all depends on what your definition of "platform agnostic" and
"platform specific" is. :-)
The best example of a "platform specific" assembly would be a "mixed
mode" assembly, in which actual x86/AMD64/Itanium/etc. code is placed
into the assembly along with the platform agnostic CIL code.
However, only .NET tools can create such mixed mode assemblies, and Mono
doesn't support their execution on any platform, so they're currently
not a concern (and likely won't ever be, for a variety of reasons).
Consequently, any assembly of consequence executing under Mono will
contain *only* platform agnostic CIL code.
The only thing left to determine whether an assembly is platform
specific is the use of Platform Invoke (P/Invoke), and this is _not_
trivial, as "portable" P/Invoke code can be written, but
platform-specific platform code can also be written. Classic example:
`struct stat' in C#:
public struct stat {
public ulong st_dev, st_ino;
public uint st_mode;
private uint _padding_;
public ulong st_nlink, st_uid, st_gid, st_rdev;
public long st_size, st_blksize, st_blocks, st_atime,
st_mtime, st_ctime;
}
Question: is that structure definition portable for use with fstat(2)?
Answer: Maybe. :-) It should work on 64-bit ABIs (since long/ulong are
64-bit integer types), but it will fail badly on 32-bit ABIs, and it
will fail on any ABI in which the member ordering differs.
Consequently, such a structure would be platform specific if used with a
DllImport statement, but there is NO EASY WAY for a program to make this
determination. :-/
(Plus, it can get more complicated, particularly if such a structure is
instead used with some native library which will accept that structure,
such as Mono.Posix.dll & libMonoPosixHelper.so, which uses a 64-bit ABI
throughout, and libMonoPosixHelper.so converts this to a 32-bit ABI as
appropriate.)
So it's easiest to assume that all CIL code is platform agnostic.
> There is currently a debate about this on the fedora-packagers list,
but
> as yet, no one is able to determine a simple way to see where things
> need to go (in respects to agnostic going in /usr/share and platform
> specific in /usr/lib or /usr/lib64). As FC has only recently taken
mono
> as part of it's core distro, the packagers (me included) want to get
> this right from the outset.
I would suggest looking at what SuSE and Debian/Ubuntu have done with
this, as they have all encountered these issues. Following in their
footsteps would help consistency, and make it easier to repackage
existing programs.
I believe that they currently use /usr/lib for everything.
However, this gets considerably more complicated, as applications may
bundle native libraries with them -- take Blam! and F-Spot as examples:
$ ls /usr/lib/f-spot
FlickrNet.dll libfspoteog.so.0.0.0 libfspot.so.0
f-spot.exe libfspotjpegtran.so libfspot.so.0.0.0
f-spot.exe.config libfspotjpegtran.so.0
libgphoto2-sharp.dll
libfspoteog.so libfspotjpegtran.so.0.0.0
libgphoto2-sharp.dll.config
libfspoteog.so.0 libfspot.so SemWeb.dll
The *.dll and *.exe files may be platform agnostic, but the *.so* files
certainly are NOT.
So the easiest solution may be to check to see if any native libraries
are bundled with the app, and if that's the case stick it under the
appropriate /usr/lib or /usr/lib64 directory. Otherwise, stick
with /usr/lib.
<--8
It doesn't exactly help, but does confirm that really, %_libdir should
be getting used. I do find it odd though that they suggest looking at
Debian and SuSE as they both do things differently (out of the two, I
think I'd go with the SuSE system rather than the Debian one)
TTFN
Paul
--
ich liebe Ashleigh, eins zwei drei
ich liebe Ashleigh, auf meinem Knee zu hüpfen
Attachment:
signature.asc
Description: This is a digitally signed message part
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
