Patch for Perl and DotNet binding are wrong

[GoogleCodeExporter]

Perl detected installation path is /usr/local/lib64/perl instead of 
/usr/lib64/perl folder.

DotNet detected installation is /usr/lib/mono instead of /usr/lib64/mono.

This has been tested on FC13.

Original issue reported on code.google.com by nicolas.dufresne@gmail.com on 9 Jul 2010 at 8:03

[GoogleCodeExporter]

FYI, /usr/lib64/mono is a Fedora'ism.  The upstream mono devs think this is 
wrong and that all mono related stuff should go into /usr/lib/mono, even on 
64bit.

Original comment by npmccallum@gmail.com on 9 Jul 2010 at 8:22

[GoogleCodeExporter]

Oh well, the upstream mono dev failed to force the world doing things there 
way, so we need to write appropriate code to detect that situation.

Original comment by nicolas.dufresne@gmail.com on 9 Jul 2010 at 8:54

[GoogleCodeExporter]

For perl, we rely on what the perl installation tells us, by querying:
perl -MConfig -e "print \$Config{sitearch}"

Are you sure you do not have a perl in /usr/local/bin? That would have 
precedence over /usr/bin/perl for example.

Original comment by dominiqu...@gmail.com on 9 Jul 2010 at 11:00

[GoogleCodeExporter]

And for the mono stuff: are the files in /usr/lib64/mono/gac (*.dll) really 
64bit compiles? That would be rather surprising... mono is, AFAIK, creating 
only 32bit binaries at this time.

As such, /usr/lib6 would actually be semantically wrong on Fedora.

Original comment by dominiqu...@gmail.com on 9 Jul 2010 at 11:06

[GoogleCodeExporter]

Ok, on my system FC13 

perl -MConfig -e "print \$Config{sitearch}"

returns

/usr/local/lib64/perl5

That must be a FC13 bug then.

Original comment by nicolas.dufresne@gmail.com on 9 Jul 2010 at 11:08

[GoogleCodeExporter]

For the mono stuff, it's indeed 32bit PE

file /usr/lib64/mono/gac/nunit.core/2.4.8.0__96d09a1eb7f44a77/nunit.core.dll
/usr/lib64/mono/gac/nunit.core/2.4.8.0__96d09a1eb7f44a77/nunit.core.dll: PE32 
executable for MS Windows (DLL) (console) Intel 80386 32-bit Mono/.Net assembly

So yes it's odd to have it there. Base on those, I would say as long as we can 
-D to override the detected path, it should be fine then. Can we ?

Original comment by nicolas.dufresne@gmail.com on 9 Jul 2010 at 11:12

[GoogleCodeExporter]

At this time, there is no override for the mono path.. it's set to lib. We can 
certainly come up with a system there though.

For perl: check "which perl"

Original comment by dominiqu...@gmail.com on 9 Jul 2010 at 11:22

[GoogleCodeExporter]

Mono binding destination path can now be overridden with:
-DCSHARP_ASSEMBLY_DIR=[path] (r717)

Original comment by dominiqu...@gmail.com on 17 Aug 2010 at 5:49

[GoogleCodeExporter]

Forget about .net, the bug was about me forgetting to install mono-devel and 
csharp script habbit of setting default values instead of letting you know that 
it's not possible to install the .net bindings because a path is missing

Original comment by nicolas.dufresne@gmail.com on 18 Aug 2010 at 4:16

[GoogleCodeExporter]

Bug reported to redhat
https://bugzilla.redhat.com/show_bug.cgi?id=625169

Original comment by nicolas.dufresne@gmail.com on 18 Aug 2010 at 6:45

[GoogleCodeExporter]

Original comment by nicolas.dufresne@gmail.com on 18 Aug 2010 at 6:46

• Added labels: Milestone-Release0.4.5

[GoogleCodeExporter]

r717 was reverted (introduced more bad than good) -> thanks for spotting this 
nicolas.

Still leaves us with the perl bindings being 'misplaced' on some distros, which 
we need an easy way to override it.

Original comment by dominiqu...@gmail.com on 18 Aug 2010 at 7:20

[GoogleCodeExporter]

Perl packager should enable PERL_VENDORINSTALL option or override sitearch by 
using PX_PERL_ARCH (r729).

Original comment by nicolas.dufresne@gmail.com on 19 Aug 2010 at 3:21

• Changed state: Fixed

[GoogleCodeExporter]

Issue 143 has been merged into this issue.

Original comment by dominiqu...@gmail.com on 30 Sep 2010 at 8:39