This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 185690 - Need to install to %libdir instead of %prefix/lib
Need to install to %libdir instead of %prefix/lib
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: mono (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Alexander Larsson
:
Depends On:
Blocks: 199790
  Show dependency treegraph
 
Reported: 2006-03-16 17:11 EST by David Zeuthen
Modified: 2013-03-05 22:45 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-18 15:08:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch to place mono in %{_liibdir} rather that %{_prefix}/lib (5.10 KB, patch)
2006-07-21 05:31 EDT, Toshio Kuratomi
no flags Details | Diff
spec file patch to place mono in libdir (1.46 KB, patch)
2006-07-21 05:36 EDT, Toshio Kuratomi
no flags Details | Diff
spec files patch that also accounts for bin wrappers (3.32 KB, patch)
2006-08-09 11:56 EDT, Toshio Kuratomi
no flags Details | Diff

  None (edit)
Description David Zeuthen 2006-03-16 17:11:55 EST
Description of problem:

Mono installs stuff into $prefix/lib when it probably should install into
%datadir instead. This complicates matters since e.g. avahi-sharp happily
installs into %libdir and this ends up on /usr/lib64 which is wrong (will file
separate bug) - note that dbus-sharp does "the right thing" and installs into
%prefix/lib.

Version-Release number of selected component (if applicable):

Rawhide
Comment 1 Ray Strode [halfline] 2006-03-16 17:19:06 EST
For the record, the separate bug is bug 185692
Comment 2 Alexander Larsson 2006-03-17 03:55:13 EST
I'm not sure diverging from the upstreams packages in such an extreme way is
very good. It will force use to patch every mono-using package, won't it?
Anyway, this is something that very much should be discussed with upstream.
Comment 3 Alexander Larsson 2006-03-17 03:56:49 EST
Note: 
All our other packages are either installing into prefix/lib by default or (a
few of them) patched to change from libdir to prefix/lib, as this is how the
upstream packages are done
Comment 4 David Zeuthen 2006-03-17 10:43:28 EST
Yea, agree that this should be discussed with upstream as it would be a
catastrophe diverging for no good reason. Maybe mono ought to include a
pkgconfig variable so upstream mono-using packages could use this.

Btw, our avahi-sharp package is going to be patched locally to adhere to this
scheme (bug 185692). Someone should tell avahi upstream about it.

I suppose you can close this as UPSTREAM then.
Comment 5 Toshio Kuratomi 2006-07-18 16:25:05 EDT
The Packaging Committee has discussed which hierarchy assemblies belong in and
decided on %{_libdir}.  So mono should be placed in %{_libdir} rather than
%{_datadir} or its present %{_prefix}/lib location.

The discussions around this were manifold but basically boiled down to these few
points:
1) If mono packages are arch specific they should go into %{_libdir}.
2) If they are noarch, they belong in %{_datadir}.

In neither case is %{_prefix}/lib the correct placement.

Mono packages may not contain any arch specific code but because a system
administrator may want to AOT compile them _and_ because the mono runtime cannot
find AOT binaries unless they are in the same directory as the assemblies, we
need to consider all packages which use the mono runtime as arch specific.
Comment 6 Toshio Kuratomi 2006-07-21 05:31:33 EDT
Created attachment 132791 [details]
Patch to place mono in %{_liibdir} rather that %{_prefix}/lib

Here's a first cut at placing mono into %{_libdir}/mono instead of
/usr/lib/mono.	I've modified configure.in, a few Makefile.am's, the pkgconfig
files, and some Makefile fragments that may or may not be relevant  (I'm not
sure if the mono build is completely autotooled or if some portion is writing
and pulling in these Makefile fragments instead.)

Along with the spec file patch I'll submit next, this places all mono files
into %{_libdir} and grepping the files doesn't show any occurrences of /usr/lib
or prefix + lib.  I haven't installed and tested yet.  I need to work on
patches for the other .net packages that use the GAC in order to get to that
stage.
Comment 7 Toshio Kuratomi 2006-07-21 05:36:21 EDT
Created attachment 132793 [details]
spec file patch to place mono in libdir

This patch to the spec file applies the libdir patch, runs autoreconf to apply
the changes to configure.in and Makefile.am, updates %monodir to expect files
to end up in %{_libdir}, and also owns the mono/compat-* directories.
Comment 8 Toshio Kuratomi 2006-07-21 05:42:38 EDT
Okay.  Next step is to determine what other packages need to have fixes applied
in order to use the new location.  anything that's installing into the gac will
need changes.  On my system this is:

avahi-sharp
dbus-sharp
evolution-sharp
gecko-sharp2
gmime-sharp
gsf-sharp
gtk-sharp
gtk-sharp2
muine

Do you know of some way I can determine if I'm missing anything in this list?

Also, will I need to do anything special to programs which are not in the gac,
but depend on libraries installed within it?  IIUC, the pkgconfig files should
tell the programs how to locate the libraries at compile time.  Does this mean
they need a recompile but should work after that?
Comment 9 Paul F. Johnson 2006-07-21 17:05:18 EDT
Where is the mono-libdir.patch file? Can you attach it to this bug please?
Comment 10 Alexander Larsson 2006-07-27 17:09:33 EDT
I'm not sure its a good idea to move around all the mono packages and their
dependencies so late in the cycle. Especially since it means we'll be different
than upstream which could easily cause new bugs to pop up.
Comment 11 Paul F. Johnson 2006-07-27 17:20:45 EDT
#10, you're probably right. I just get annoyed that packages have to fiddled
with so much because upstream have messed up with where things have to go
Comment 12 Alexander Larsson 2006-08-08 08:18:38 EDT
I tested the patch above. I still get conflicts when installing both the 32bit
and the 64bit mono-core package. The problem is that the binary wrappers such as
/usr/bin/gacutil now differ (lib vs lib64). 

I'm not sure what the best way to solve this is. Depending on what you want to
do you really want different exes. For instance, if you're building a 32bit mono
dll on 64bit you want to use the 32bit gacutil when installing, otherwise it'll
be installed in the wrong directory (i think, because the mono dir is compiled
into gacutils).
Comment 13 Paul F. Johnson 2006-08-08 08:34:35 EDT
From the digging around I've done and looking at the build structure and
associated files, it seems that /usr/lib is very deliberate on the part of
Ximian (as was) and now Novell.

There are two solutions to this problem that I can see.

1. We create a new macro (call it _monodir) which always puts things into
/usr/lib irrespective of architecture
2. We fix mono ourselves so that it becomes architecture agnostic.

The problem with (2) is that it's not easy - mono relies on things being in
/usr/lib and /usr/lib/pkgconfig. It can be done, but there is that much hacking
around on both mono and on packages associated with mono that it becomes hard to
justify. I'm not saying we shouldn't fix it - I'm just asking on the time
justification.

(1) is what is currently happening except that the macro would be similar to
%{_bindir} and be built in to rpmbuild (or whatever it is that defines these macros)

I'm personally not happy with (1), but then I'm not happy with mono being
fundamentally broken and upstream not being that willing to do anything much
about it. However, it does seem to be an answer - probably not the best one though.
Comment 14 Toshio Kuratomi 2006-08-08 11:35:35 EDT
Ugh.  Forgot about %{_bindir}.  If we don't want to have the 32-bit programs on
x86_64, then we could subpackage around the issue in the spec file.  If we do
want the 32-bit versions then we'd probably have to add a bittedness suffix:
gacutil64 etc.

From a packaging perspective we invoke gacutil at build time, not install time
so there's no need to have both 32bit and 64bit versions of gacutil installed. 
Additionally, gacutil has a -root option that can specify an alternate path to
the gac:
  gacutil -i -root /usr/lib
So the end-user can install into /usr/lib if they have that need.

Do you know if the library path is hardcoded into any of the other programs?
Comment 15 Alexander Larsson 2006-08-08 12:03:45 EDT
It seems like the library path is only hardcoded into the mono jit itself, not
in any of the dlls. However there are lots of places in that code that currently
hardcode or assume "lib", not "lib64" (see assembly.c), so the attached patch is
not good enough, and this change will be pretty major. So, whatever version
/usr/bin/mono is, that will decide what mono dir gacutil uses by default.

We certainly don't want to call mono "mono32" on x86 machines, nor do we want to
add prefixes for every mono using app that we ship. Especially when they are
basically noarch all of them. 

I think the best approach is something like using /usr/lib, and then handling
mono .exe and .dll multiarch conflicts better in rpm (similar to how we do elf
ones). Then solve the ahead-of-time problem in some other way. I'll continue
looking at this tomorrow.
Comment 16 Alexander Larsson 2006-08-08 12:06:07 EDT
Also, i ran cmp on two .dll files built on 32bit and 64bit. They differed only
in about 15 bytes, which i assume was timestamps or something. Maybe we can make
them identical so that we don't get conflicts.
Comment 17 Toshio Kuratomi 2006-08-08 13:57:42 EDT
Re: Comment#15(In reply to comment #15)
> It seems like the library path is only hardcoded into the mono jit itself, not
> in any of the dlls. However there are lots of places in that code that currently
> hardcode or assume "lib", not "lib64" (see assembly.c), so the attached patch is
> not good enough, and this change will be pretty major. 

I found the following relevant functions by searching for "lib" in assembly.c. 
Let me know if I've missed anything::

  mono_assembly_setrootdir(): Sets default_path[0] to the pathname passed in as
an argument.

  mono_set_dirs(): If this function is given a directory path it sets the
assembly_dir to that directory using mono_assembly_setrootdir(), otherwise it
sets the path to MONO_ASSEMBLIES.  MONO_ASSEMBLIES is set in
mono/metadata/Makefile.am to $(assembliesdir) which is set to $(libdir) with my
patch.

  fallback(): Calls mono_set_dirs() with no directories, so if we use
fallback(), assembliesdir will be $(libdir).

  set_dirs(): Checks for the existence of $prefix/lib/mono/1.0.  If that is not
found invoke fallback().

  mono_set_rootdir(): References "lib" within a WIN32-only section, otherwise
invokes set_dirs().

  mono_assembly_load_with_partial_name(), mono_assembly_load_publisher_policy(),
mono_assembly_load_from_gac(): If the environment variable MONO_GAC_PREFIX is
set, attempt to load the assembly from a user defined gac in the
MONO_GAC_PREFIX/lib/mono/gac/ASSEMBLYNAME.  If the assembly isn't found in the
user defined GACs then fallback to the gac defined in mono_assembly_setrootdir().

If that's everything and only the mono runtime needs to know where mono/gac is
located then the patch should be sufficient.  I did a grep for \"lib\" in the
mono/ subdirectory which didn't turn up anything else relevant.  The mcs
subdirectory also had "lib" in it but someone would have to check whether they
were actually referencing the path ("/usr/lib") or a prefix ("libbanshee.so").

> So, whatever version
> /usr/bin/mono is, that will decide what mono dir gacutil uses by default.
> 
> We certainly don't want to call mono "mono32" on x86 machines, nor do we want to
> add prefixes for every mono using app that we ship. Especially when they are
> basically noarch all of them. 
> 
I agree this is something we want to avoid.

> I think the best approach is something like using /usr/lib, and then handling
> mono .exe and .dll multiarch conflicts better in rpm (similar to how we do elf
> ones). Then solve the ahead-of-time problem in some other way. I'll continue
> looking at this tomorrow.
> 
Solving the AOT problem would work.  If mono can generate AOTs in a different,
arch specific directory structure and find them there when it needs, then the
assemblies should be okay in /usr/lib or datadir.  There are two caveats:

1) Some subset of packagers would then want assemblies in %{_datadir} since they
would then be arch independent (so the packaging committee would have to hash
out if that was a worthwhile change and then we'd sit in another bug trying to
figure out how to implement it :-)

and 2) My understanding is that getting mono to find AOTs is actually a much
more intrusive change than relocating the mono runtime to %{_libdir}
Comment 18 Alexander Larsson 2006-08-09 05:58:20 EDT
re 1) I'm not sure we can split the GAC up in both libdir and datadir. I think
it has to be in one directory.

re 2) That is possible, but switching to libdir causes other problems (binary
wrapper conflicts) that i'm not sure have a good solution.

An interesting question is why the 32bit mono-core and mono-devel packages are
in the 64bit yum repository. That is the main cause of immediate problems.
Comment 19 Paul F. Johnson 2006-08-09 06:35:57 EDT
#18

Point 1 : You can't. I've tried that and it ends up a complete mess. The whole
purpose of keeping to one directory is to ensure the same source base can be
used and that gacutil always knows where to look without having to mess around
with the platform (for example, Win32 would use C:/Windows/System32, OS X would
use something insane and we're in /usr/lib/mono/gacutil)

Point 2 : I quite agree. Having the .exe's in /lib with a wrapper in %_bindir is
dumb, especially with naming and access conflicts.

"An interesting question is why the 32bit mono-core and mono-devel packages are
in the 64bit yum repository. That is the main cause of immediate problems."

/me looks sheepish as I seem to be the biggest contributor of .NET apps to FE!

There are two problems here. 

The first is that those reviewing .NET apps have no guidance on the wiki as how
to identify a 32 bit only dll. Second to that is that rpmlint really isn't that
well suited to testing .NET apps. It's great for standard applications, but
doesn't recognise or plain gets wrong pieces of the .NET infrastructure.

Possibly a solution would be for the buildsys to do what it does with the likes
of OOo in core and call the package i386 for x86_64/ia64 architecture if it
detects it is a 32 bit only dll once built.

Not sure what the best way to do that would be. I suppose if it builds the i386
rpm first, then the x86_64 and compares the filesize, if they're the same, call
it i386. Failing that have the packager check (create a new rpmlint called
rpmlint.net or give instructions on the wiki) and include a flag in the spec -
something like

Netver : 32 | 0 [0 = has both 32 and 64]

which instructs the buildsys that the rpm for the 64 bit repos has to also be
called .i386

As for the packages already in FE, I'm not sure there is anything I can do other
than excludearch them - which I'm loathed to do as they don't upset anything
(currently) and also it would be wrong as they do build under 64 bit, just not
have the correct arch name.
Comment 20 Alexander Larsson 2006-08-09 10:29:45 EDT
So, it seems the reason we have the 32bit mono in the 64bit repository is
because there is a mono-devel package, and for all *-devel packages we add the
32bit version to the 64bit distro. This pulls in mono-core, which conflicts with
64bit mono-core because the .dll and .exe files differ (in very minor ways).
Comment 21 Paul F. Johnson 2006-08-09 10:45:47 EDT
Hmm. Why would having the -devel packages add the 32 bit version to the 64 bit
distro?

I'm actually wondering if the difference in the dlls and exe's are down to the
likes of struct padding rather than anything else

(see http://www-128.ibm.com/developerworks/linux/library/l-port64.html)
Comment 22 Alexander Larsson 2006-08-09 11:02:16 EDT
the -devel matching is part of the distro compose magic.

The difference in the dlls seems to be only a timestamp and a different strong
name. The padding and sizes are identical.

Also, i'm thinking the ahead of time compilation is really not a problem. There
is no reason to want aot compiled versions for both 32bit and 64bit, because
once you have the 64bit mono installed you can't really start the 32bit jit,
because /usr/bin/mono will always be the 64bit one.
Comment 23 Toshio Kuratomi 2006-08-09 11:48:07 EDT
(In reply to comment #18)
> re 1) I'm not sure we can split the GAC up in both libdir and datadir. I think
> it has to be in one directory.
> 
This is the change I'm talking about.  We have to make it so the GAC can place
AOTs into %{_libdir} even when the assemblies are in /usr/lib.  Like I say, this
is a more intrusive change than moving all of the GAC to %{_libdir}.

> re 2) That is possible, but switching to libdir causes other problems (binary
> wrapper conflicts) that i'm not sure have a good solution.
> 
The binary wrapper problem is trivial to fix.  You need to have the binary
wrappers in a separate subpackage from the assemblies.
Comment 24 Toshio Kuratomi 2006-08-09 11:56:59 EDT
Created attachment 133851 [details]
spec files patch that also accounts for bin wrappers

Here's a preliminary patch to the spec file that breaks apart the assemblies
and the bindir programs.  This way mono-core is a multiarch capable package. 
This is proof of concept but not quite up to Fedora Guidelines.  All packages
should depend on the %{name} package.  So the names of the mono and mono-core
packages should be switched.  I'll do that cosmetic touch up after I finish
commuting to work.  Go ahead and comment on whether this works for your
testing, though.
Comment 25 Alexander Larsson 2006-08-09 12:56:25 EDT
I had another idea for an easy multilib fix.
We split mono-core into mono-lib and mono-core, with mono-lib only containing
libmono and the stuff needed for embedding mono. Then we split up mono-devel to
mono-devel (containing libmono header, pc file and libmono.so) and mono-devtools
containing the rest.

This will pull in mono-devel and mono-lib as both 32bit and 64bit libs in the
distro. It will be without conflicts, and it will properly allow both 32bit and
64bit apps to embed mono. The conflicting 32bit files will not be pulled into
the 64bit distro, and both libraries will share the same dlls etc.

I just think duplicating all the arch independent .dlls is wrong. And I don't
buy the AOT argument. There is just no way to use both 32bit and 64bit AOT .so
files at the same time, since we only have one version of the jit. I also think
splitting out the bin wrappers is a very strange and unexpected packaging.
Comment 26 Toshio Kuratomi 2006-08-09 14:12:44 EDT
(In reply to comment #25)
> I had another idea for an easy multilib fix.
> We split mono-core into mono-lib and mono-core, with mono-lib only containing
> libmono and the stuff needed for embedding mono. Then we split up mono-devel to
> mono-devel (containing libmono header, pc file and libmono.so) and mono-devtools
> containing the rest.
> 
That should work to fix Bug #199790

> I just think duplicating all the arch independent .dlls is wrong.

I do to.  So the true solution is assemblies belong in %{_datadir}.  If the
package has no glue libraries, these packages can be noarch and thus there's no
duplication of arch independent assemblies on i386, x86_64, and ppc.

> And I don't
> buy the AOT argument. There is just no way to use both 32bit and 64bit AOT .so
> files at the same time, since we only have one version of the jit. 

Where were you when we had to discuss this on fedora-packaging?  :-) Your input
would have been greatly appreciated.

What happens if you have /usr/lib network mounted?  In multiarch, I should be
able to have /usr/lib shared between i386 and x86_64 with a separate /usr/bin
for each arch.  If AOTs are in /usr/lib, /usr/bin/mono is going to be pretty
upset with me.

> I also think
> splitting out the bin wrappers is a very strange and unexpected packaging.
> 
It's the standard way to do such things.  Splitting out the libs is the same
thing in reverse.  Look at db4, poppler, etc.

We can go with a subpackaging only approach to fix 199790 for now.  This keeps
us from having to make a big change this close to FC6 which is a big relief for
some (Extras seems to want the changes made sooner so they can fix their packages.)

For the FC7 devel cycle we either need to move mono to %{_libdir} or you need to
bring your AOT ideas to the packaging committee to see what falls out.  Judging
from the discussion last time, the leading proposal will be:

1) packages with assemblies and no shared objects are noarch and go in %{_datadir}
2) packages with assemblies and shared objects (glue libraries) go in %{_libdir}
and are arch specific
3) mono needs to be able to find AOTs in %{_libdir} even when the assemblies are
in %{_datadir}.

Our present guidelines with everything in %{_libdir} are a compromise between
the ideal and the practical.  Making #3 work looks like something that is best
done with upstream cooperation (and preferably by upstream :-).

If we just want to move things into %{_libdir} we can do that with the
subpackage approach (which you're going to do anyway) and my patch.  Plus
patching (or unpatching in some cases) the build scripts to the other mono packages.
Comment 27 Alexander Larsson 2006-08-10 03:41:40 EDT
>> I also think
>> splitting out the bin wrappers is a very strange and unexpected packaging.
> It's the standard way to do such things.  Splitting out the libs is the same
> thing in reverse.  Look at db4, poppler, etc.

Maybe it makes some sense for mono, which has a .so file. But take a normal mono
app/library. It will have both dlls (or exes) and binary wrappers. Would you
also split tomboy into two packages?

>2) packages with assemblies and shared objects (glue libraries) go in 
> {_libdir} and are arch specific

Ideally this shouldn't be needed. Such shared glue libraries are already in
lib/lib64 (take a look at for instance gtk-sharp2 on x86-64) and are loaded
correctly. If we could make either the dlls be identical (fix timestamp and
strong name differences) or make rpm ignore the dlls conflicts things would just
work.

Anyway, for FC6 i'll just do the mono-lib split.
Comment 28 Toshio Kuratomi 2006-08-10 11:42:35 EDT
(In reply to comment #27)
> Maybe it makes some sense for mono, which has a .so file. But take a normal mono
> app/library. It will have both dlls (or exes) and binary wrappers. Would you
> also split tomboy into two packages?
> 
Libraries don't have binary wrappers, only apps.  Tomboy doesn't need a split --
there's no devel package.

If you have a package that includes both programs and libraries then yes, it
needs to be split.  This is nothing new -- it's the same as libraries and
applications written in C.  We've been filing bugs and making those splits for a
long time now.  elfutils, bind, bzip2, etc.

> >2) packages with assemblies and shared objects (glue libraries) go in 
> > {_libdir} and are arch specific
> 
> Ideally this shouldn't be needed. Such shared glue libraries are already in
> lib/lib64 (take a look at for instance gtk-sharp2 on x86-64) and are loaded
> correctly.

Sounds reasonable.  Assemblies into %{_datadir} and the shared objects into
%{_libdir}.  The package still has to be arch specific.

> If we could make either the dlls be identical (fix timestamp and
> strong name differences) or make rpm ignore the dlls conflicts things would just
> work.
>
It just works in the sense that the program runs.  It doesn't work in the sense
that using %%{_prefix}/lib conflicts with the FHS + multilib.  Either the
assemblies have to be treated as arch specific (because of the AOTs) and go in
%{_libdir} or the assemblies can be treated as arch independent (with AOTs being
read/written to a %{_libdir} hierarchy) and then they go to %{_datadir}.
 
> Anyway, for FC6 i'll just do the mono-lib split.
> 
That sounds like the best plan for this release.
Comment 29 Alexander Larsson 2006-08-11 05:51:27 EDT
Ok. So, what we have is:

Modify mono so that assemblies are loaded from /usr/share/mono/.
Modify mono to load/write AOT .so files for dlls in the gac in the
%_libdir/mono/gac tree.
Make sure 32bit and 64bit compiled dlls from same source are identical.
Pure mono lib packages are noarch
Mono lib packages with glue libraries are arch, and put the .so files in %{_libdir}.
Pure mono apps put stuff in %datadir/appname/ and are noarch.
Mono apps that have a glue lib put stuff in %libdir/appname and are arch dep.
These apps will not be multilib safe as the binary wrapper will conflict.

Seems like it could work. Its quite some work though.
Comment 30 Toshio Kuratomi 2006-08-11 12:11:57 EDT
Yes, that looks right.  And you have a gift for understatement :-)

If you think it's worthwhile to attempt that level of change we should present
the plan to the packaging committee so we can get more eyes on it.
Comment 31 Paul F. Johnson 2006-08-11 15:37:58 EDT
With this new release in rawhide (11th Aug 2006), what impact does it have on
packaging? Do I need to rebuild all of my mono stuff in FE?
Comment 32 Alexander Larsson 2006-08-14 03:32:20 EDT
Toshio:
I don't really think its worthwile. Its a load of work, and its mainly for
estetical reasons. However, maybe we can get some buy-in from upstream for going
this way. Then it seems like a better idea.

Paul:
The only change you might need to do with the rawhide change is to change
BuildRequire: mono-devel (if you have any) to BuildRequire: mono-devtools.
(Unless the package actually embedds mono.)
Comment 33 Toshio Kuratomi 2006-08-14 12:53:27 EDT
When the packaging committee met, they thought it was too much work to implement
a shift to %{_datadir} on our own as well.  That's why the guidelines were
written to place things in %{_libdir} instead.

So far it seems that the patch I provided accounts for all the references to
"lib" within the mono runtime.  The mcs/ hierarchy has two pieces of suspect code:

mcs/tools/gacutil/driver.cs: EnsureLib() When gacutil is given a dircetory for a
user-defined gac on the commandline, this function is used to confirm that it is
a   valid directory.  The check asks if the directory is "lib" and if not,
appends "lib" to the end.  It is not necessary to change this as user defined
directories within the user's home dir are going to be "lib".  If we want we can
 patch this to allow either "lib" or "lib64", though.

mcs/class/Microsoft.Build.Utilities/Mono.XBuild.Utilities/MonoLocationHelper.cs:
 MonoLocationHelper(): This one needs some analysis.  The code takes the
assembly dir and strips off levels until it gets to the $prefix.  Then it
re-appends "lib" to make a "libdir" which can be accessed from the
MonoLocationHelper.GetLibDir() method.  This method is never invoked in the mono
 source code.  If we wanted to retrieve the proper libdir for the platform it
seems like the code should save the libdir when it is stripping off directory
levels instead of reappending "lib".  Since no other code uses this, I can't
verify what the reason is for using such a strange algorithm in the first place
is, though.

So between the first patch, patching these two mcs/* files, and splitting
%{_bindir} stuff from %{_libdir} (which you're already doing conceptually to fix
the multilib problems) mono should place itself into %{_libdir} fine.

If you think upstream may buy into helping to do the work to switch to
%{_datadir} then we need to confirm that upstream is willing to make this change
and put the proposal to the packaging committee.  If not, the %{_libdir} change
seems just about complete to me (unless you can find other problems with it.)

If you have a third alternative, feel free to bring it up and propose it to the
Packaging Committee.
Comment 34 Alexander Larsson 2006-08-18 15:08:02 EDT
Mono 1.16.1-2 has dlls and exes in %libdir, and the binary wrappers are modified
so that they are identical on all arches by calling the executable "monodir" to
get the current mono directory. Since monodir is an elf binary the rpm file
coloring will handle that the same way as the "mono" binary, thus it will always
point to the currently active arch.

I've started to convert all the mono packages to put dlls in libdir.
Comment 35 Paul F. Johnson 2006-08-18 15:59:16 EDT
Can you upload the srpms (x86_64 and i386) so I can get going on my packages as
well?

Can I also take it that the likes of pkgconfig is correctly picking up from
usr/lib64/pkgconfig?
Comment 36 Paul F. Johnson 2006-08-18 15:59:34 EDT
Can you upload the rpms (x86_64 and i386) so I can get going on my packages as well?

Can I also take it that the likes of pkgconfig is correctly picking up from
usr/lib64/pkgconfig?
Comment 37 Alexander Larsson 2006-08-22 05:51:57 EDT
All the packages are in rawhide now.
Comment 38 Paul F. Johnson 2006-08-22 05:55:37 EDT
Excellent.

They seem nice and stable. Any chance of pushing them into core?

Rebuild time for my packages I think once that's done (the changes [-devel in
gtk-sharp2 and gnome-sharp] break quite a lot of what I have in extras)
Comment 39 Alexander Larsson 2006-08-22 10:00:50 EDT
What do you mean by "core", its already in fedora core? Did you mean FC5? Thats
not likely at this point.
Comment 40 Paul F. Johnson 2006-08-22 10:22:11 EDT
Sorry, yes. I class core as being the stable release rather than rawhide. Apologies.

Problem is though that FC5 is now broken for mono without the devel packages.
Okay, I realise that we're close to FC6 hitting pay dirt, but having FC5 broken
just ain't cricket.
Comment 41 Alexander Larsson 2006-08-23 07:44:37 EDT
How can FC5 be broken? Its a stable distribution, and as such it hasn't changed
at all wrt to these changes.
Comment 42 Paul F. Johnson 2006-08-23 08:06:46 EDT
In FC5, the monohack is still required due to still being on the -1 release, the
-2 release in rawhide fixed that and also altered how the core mono package was
released.
Comment 43 Alexander Larsson 2006-08-23 09:07:41 EDT
I still don't understand what you're talking about. What is the -1 release?
FC5 has "mono-1.1.13.7-1.fc5.1", which has everything in /usr/lib/mono, and
rawhide/FC6 has "mono-1.1.16.1-2.fc6" which uses %_libdir/mono.
Comment 44 Toshio Kuratomi 2006-08-23 11:04:27 EDT
Re: Comment #34
Thanks Alex!

Re: Paul
Moving the mono library directory is a big change affecting nearly all the
mono-using packages.  It's not really a change that's suitable for a stable
release.  So you're going to have to continue to do things differently on FC5. 
You'll either have to maintain a different spec file there or use conditionals
to detect the version of fedora you're building on and use the correct
directories for that release.
Comment 45 Paul F. Johnson 2006-08-24 11:02:33 EDT
Looks like something is still wrong. gtksourceview-sharp isn't building for
x86_64 in rawhide...

Job failed on arch x86_64


         Build logs may be found at
http://buildsys.fedoraproject.org/logs/fedora-development-extras/14532-gtksourceview-sharp-2.0-16.fc6/


-------------------------------------------------

+ rm -f
/var/tmp/gtksourceview-sharp-2.0-16.fc6-root-mockbuild/usr/share/gtksourceview-1.0/language-specs/vbnet.lang
+ /usr/lib/rpm/find-debuginfo.sh /builddir/build/BUILD/gtksourceview-sharp-2.0-0.10
0 blocks
find: /var/tmp/gtksourceview-sharp-2.0-16.fc6-root-mockbuild/usr/lib/debug: No
such file or directory
+ /usr/lib/rpm/redhat/brp-compress
+ /usr/lib/rpm/redhat/brp-strip-static-archive /usr/bin/strip
+ /usr/lib/rpm/redhat/brp-strip-comment-note /usr/bin/strip /usr/bin/objdump
+ /usr/lib/rpm/brp-python-bytecompile
Processing files: gtksourceview-sharp-2.0-16.fc6
error: File not found:
/var/tmp/gtksourceview-sharp-2.0-16.fc6-root-mockbuild/usr/lib64/mono/gac/gtksourceview-sharp
error: File not found:
/var/tmp/gtksourceview-sharp-2.0-16.fc6-root-mockbuild/usr/lib64/mono/gtksourceview-sharp-2.0
Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.31142
+ umask 022
+ cd /builddir/build/BUILD
+ cd gtksourceview-sharp-2.0-0.10
+
DOCDIR=/var/tmp/gtksourceview-sharp-2.0-16.fc6-root-mockbuild/usr/share/doc/gtksourceview-sharp-2.0
+ export DOCDIR
+ rm -rf
/var/tmp/gtksourceview-sharp-2.0-16.fc6-root-mockbuild/usr/share/doc/gtksourceview-sharp-2.0
+ /bin/mkdir -p
/var/tmp/gtksourceview-sharp-2.0-16.fc6-root-mockbuild/usr/share/doc/gtksourceview-sharp-2.0
+ cp -pr AUTHORS COPYING INSTALL NEWS README
/var/tmp/gtksourceview-sharp-2.0-16.fc6-root-mockbuild/usr/share/doc/gtksourceview-sharp-2.0
+ exit 0
Processing files: gtksourceview-sharp-devel-2.0-16.fc6
error: File not found:
/var/tmp/gtksourceview-sharp-2.0-16.fc6-root-mockbuild/usr/lib64/pkgconfig/gtksourceview-sharp-2.0.pc
Processing files: gtksourceview-sharp-debuginfo-2.0-16.fc6


RPM build errors:
    File not found:
/var/tmp/gtksourceview-sharp-2.0-16.fc6-root-mockbuild/usr/lib64/mono/gac/gtksourceview-sharp
    File not found:
/var/tmp/gtksourceview-sharp-2.0-16.fc6-root-mockbuild/usr/lib64/mono/gtksourceview-sharp-2.0
    File not found:
/var/tmp/gtksourceview-sharp-2.0-16.fc6-root-mockbuild/usr/lib64/pkgconfig/gtksourceview-sharp-2.0.pc

I've removed the monodir hack and get the above
Comment 46 Toshio Kuratomi 2006-08-24 11:20:39 EDT
This is a problem with gtksourceview-sharp, not with the new mono packaging. 
Here's the relevant line from your build.log:

/usr/bin/gacutil /i gtksourceview-sharp.dll /f /package gtksourceview-sharp-2.0
/root /var/tmp/gtksourceview-sharp-2.0-16.fc6-root-mockbuild/usr/lib

gtksourceview-sharp is using the -root option to specify where it wants to be
installed.  In this case, it is erroneously saying /usr/lib.  If
gtksourceview-sharp didn't supply a /root option or used %{_libdir} instead of
$prefix/lib then it would do the right thing.
Comment 47 Paul F. Johnson 2006-08-24 11:27:30 EDT
This is probably why a lot of the fun and games started in the first place, the
packages makefiles and configuration files have the problems and not us. 

Oh well, time to hack around...
Comment 48 Alexander Larsson 2006-08-25 04:12:04 EDT
A lot of makefiles let you specify GACUTIL_FLAGS though, which lets you easily
fix things like this.
Comment 49 Ilya Konstantinov 2006-09-18 08:11:01 EDT
There are other reasons than AOT to keep 32-bit and 64-bit .NET binaries separate.

According to this:
http://www.request-response.com/blog/PermaLink,guid,34966ef8-3142-46b2-84e0-372b5c36ddcc.aspx
Microsoft keeps separate copies of their class library (BCL) for 32-bit and 64-bit: 

This document:
http://msdn.microsoft.com/netframework/programming/64bit/default.aspx
specifies things which will make a 32-bit .NET binary impossible to use on a
64-bit VM.
Any binary which has 'unsafe' code blocks is not portable.
I didn't understand whether P/Invoke, which is used a lot by things like
gtk-sharp and avahi-sharp, is one of the things which make a binary non-portable.

They say that a .NET binary should be "verifiable" if it's to be portable.
Microsoft has a utility called PEInvoke.exe which can confirm that. Until we
have such a utility, we should assume every DLL to be non-portable and instal it
in %libdir.

Note You need to log in before you can comment on or make changes to this bug.