Re: [Fedora-packaging] Mono Packaging Issues

[Toshio Kuratomi]

Here's a recap of the blocker issues as I see them presently standing:

On Mon, 2006-06-12 at 18:23 -0500, Tom 'spot' Callaway wrote:
>  1. Redefining libdir for mono packages: 
>  If mono and its tools cannot find a library on a 64bit architecture
> when
>  it lives in %{_libdir} (/usr/lib64), then mono is fundamentally broken
>  on that architecture, and needs to be fixed. 
I think we're in agreement about this.  But Paul Johnson (Nodoid) has
run into some issues with this and making the packages noarch.  A look
at the lat approval:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177580

and the package in cvs shows that this is likely an overzealous
configure.ac.  Paul Howarth should ask upstream why they are using
AC_CANONICAL_TARGET in their configure.ac.  AFAICT there is no reason
for it.  Removing it from the spec and regenerating configure means that
we do not have to play tricks with either %{_libdir} or
%{_target_platform}.

(Diff to lat.spec as attachment #1)

>  
>  2. Putting DLLs in %{_datadir} vs %{_libdir}:
>   
A) DLLs are mostly architecture independent.  Testing of DLLImport
appears to show that code that is not architecture independent has to be
rewritten or it will fail at runtime on unsupported architectures.  A
simple recompile won't fix things.  The simple test case that I used was
a C library with a structure that contained an unsigned long type.  In
C, this can be a 32 bit or 64 bit value depending on the platform it is
compiled on.  In mono this structure is defined as either ulong or uint
for 64bit or 32bit respectively.  The mono code will fail to work
correctly on the platform it is not coded for.  Either the C library has
to be coded to explicitly use a 32bit or a 64bit integer or the mono
library will have to detect the number of bits at runtime and translate
its values correctly before passing to C (I don't know how this is done
but I've read that Mono's POSIX library does this.)

I have no objection to DLLs being noarch due to this.

Attachment #2 is a tarball of the code for my test case.  Run make on an
x86_64.  The resulting files will run fine.  Run make on an ix86.  The
resulting files will generate incorrect answers.

B) Using Ahead-of-time compilation currently has to place the .so files
in the same directory as the DLLs.  Putting those into /usr/share is
plainly wrong.  We have two options: i) Explicitly do not support ahead
of time compilation until mono can be enhanced to recognize an aot .so
in a different directory [Is this in upstream's roadmap?] ii) Put DLLs
in arch specific directories (somewhere under %{_libdir}).

To test I used nant as my test program.  This could probably be done
with tomboy/banshee/etc as  well.
1) cp -pr /usr/share/nant ~/nant
2) export MONO_PATH=$MONO_PATH:~/nant:~/nant/lib:~/nant/lib/mono:\
~/nant/lib/mono/1.0:~nant/lib/mono/2.0:~/nant/lib/net/1.0:\
~/nant/lib/net/1.1:~/nant/lib/net/2.0
3) cd ~/nant
4) sed 's^/usr/share/NAnt/bin^$HOME/nant^' < /usr/bin/nant > nant
5) mono --aot ./nant
6) strace ./nant &> aot-in-same-dir.log
7) strace /usr/bin/nant &> aot-in-monpath.log
8) Compare the two logs and notice that running our copy of nant that
uses dlls from ~/nant finds the .dll.so files there.  The system nant
does not even though the .dll.so's are in MONO_PATH.

>  3. Forcing local copies of DLL libraries instead of using system
>  installed DLLs. 
Everyone is against this.  So far, we've only discovered one possible
instance of this in banshee.  We have a list of possible ways to check
for this but it isn't foolproof.  We would like the monoproject to
rethink their position.

-Toshio