| View previous topic :: View next topic |
| Author |
Message |
unlocked
n00b
Joined: 24 Oct 2004
Posts: 53
Location: Austin, Tx.
|
 Posted: Sun Feb 27, 2005 7:22 pm Post subject: mod_mono svn ebuild for amd64 fixes |
 |
|
You will need to make an overlay dir and name the ebuild something like
mod_mono-1.0.6-r1000.ebuild
and copy over mod_mono-1.0.2-70_mod_mono.conf from the /usr/portage dir
to your overlay mod_mono/files dir.
run ebuild mod_mono-1.0.6-r1000.ebuild digest and manifest
You also need to have a fully working mono 1.1.4 system on ~amd64.
ie add packages to /etc/portage/package.keywords with ~amd64 for various ebuilds or edit them maually
and create a complete overlay of all the packages you want outside of regular portage
so no mater if portage changes you can fix it fast in your overlay and you
will have to hard unmask some stuff. 
With this svn version xsp demo examples work and apache doesnt hang trying to run them.
Mono seems to be working fairly well. Just need to get all the ebuild maintainers to put
~amd64 back in all of them except the debugger so it is easier for more people to try it and
find bugs..
Well just my opinion.
| Code: |
# Copyright 1999-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
inherit subversion mono eutils multilib flag-o-matic
ESVN_REPO_URI="svn://svn.myrealbox.com/source/trunk/mod_mono"
DESCRIPTION="asp.net connector for apache"
HOMEPAGE="http://www.mono-project.com/"
SRC_URI=""
LICENSE="GPL-2"
SLOT="0"
KEYWORDS="~x86 ~amd64"
IUSE=""
DEPEND=">=dev-dotnet/mono-1.1.4
=net-www/apache-2*
>=dev-dotnet/xsp-1.0.6"
RDEPEND=""
S="${WORKDIR}/mod_mono"
src_compile() {
strip-flags
./autogen.sh || die "./autogen.sh failed"
econf \
--libexecdir=/usr/lib/apache2-extramodules \
--with-apxs=/usr/sbin/apxs2 \
--with-apr-config=/usr/bin/apr-config || die "econf failed"
emake -j1 || die "make failed"
}
src_install() {
exeinto /usr/lib/apache2-extramodules
doexe src/.libs/mod_mono.so.0.0.0
dosym /usr/lib/apache2-extramodules/mod_mono.so.0.0.0 \
/usr/lib/apache2-extramodules/mod_mono.so
dosym /usr/lib/apache2-extramodules/mod_mono.so.0.0.0 \
/usr/lib/apache2-extramodules/mod_mono.so.0
insinto /etc/apache2/conf/modules.d
newins ${FILESDIR}/${PN}-1.0.2-70_mod_mono.conf 70_mod_mono.conf
doman man/mod_mono.8
einfo "To view the samples, uncomment the commented blocks in"
einfo "/etc/apache2/conf/modules.d/70_mod_mono.conf"
einfo
einfo "Edit /etc/conf.d/apache2 and add \"-D MONO\" to APACHE2_OPTS"
}
|
_________________
abit av8 (939), 3000+, 1gig ram, ti4400, dc10+, 120gig sata, audigy2. |
|
| Back to top |
|
 |
latexer
Retired Dev
Joined: 05 Mar 2003
Posts: 239
Location: NYC
|
| Posted: Mon Feb 28, 2005 3:47 pm Post subject: Re: mod_mono svn ebuild for amd64 fixes |
|
|
| unlocked wrote: |
Mono seems to be working fairly well. Just need to get all the ebuild maintainers to put
~amd64 back in all of them except the debugger so it is easier for more people to try it and
find bugs..
|
Not sure if your tone is how i'm interpreting it or not, but this struck me as if you think we aren't working hard on this, or we aren't paying attention or something. If that's not how you intended this to come off, then please ignore the following rant/explanation.
We can't add more ~amd64 keywords to things until mono-1.1.4 is moved out of package.mask. This isn't happening *at the earliest* until after mono-1.0.5-r4 is marked stable on x86 and ppc. This should be happening in the next week or two, as i *finally* have all the bugs regarding mono-1.0.x closed. Once that has settled, i'll feel more confortable getting 1.1.4 out of package.mask. Even then, i'd prefer to wait for a new monodevelop release first, which will work much better with the 1.1.x series. Yes, i've been doing *active* testing on amd64 stuff, so that when the time comes, *-sharp, tomboy, etc will work for people.
That said, thank you for posting ebuilds like this one to help people out that really need these things working.
_________________
overlays - Use at your own risk. File bug reports on this stuff and i'll kick you in the junk. Ask me before asking upstream if these fail. I mean it. No, really.
#gentoo-dotnet on freenode |
|
| Back to top |
|
|
unlocked
n00b
Joined: 24 Oct 2004
Posts: 53
Location: Austin, Tx.
|
| Posted: Tue Mar 01, 2005 4:28 am Post subject: |
|
|
nah I didn't mean anything by that statement. I have been a slackware user for the last 8 years and I switched to Gentoo for amd64 support. I was not sure how the development cycle went and was just trying to say that if mono 1.1.4 was unmasked and put into ~amd64 testing it might not be quite such a pain to have to make a complete everything mono overlay on each users machine. That is what I thought ~amd64 testing was. I would of never got it working if I hadn't stripped mono build to -O1. It just seems that once you got a working mono the rest comes together for the most part, well at least on my machine. I've always lived off cvs source builds on top of slackware so I thought ~amd64 testing was a little more on the edge like I'm used to.
Just to reiterate I'm a Gentoo noob sorry if I came off wrong.
So I gather that testing is one step down from the devs doing there testing and calling it good enough for others to do bug hunting and not testing per say Hehe. 
no big deal I'll just make a nice set of cvs/svn ebuilds and not bother the natives with my chatter and treat my gentoo box like my old slackware box. carry on
_________________
abit av8 (939), 3000+, 1gig ram, ti4400, dc10+, 120gig sata, audigy2. |
|
| Back to top |
|
|
latexer
Retired Dev
Joined: 05 Mar 2003
Posts: 239
Location: NYC
|
| Posted: Tue Apr 12, 2005 5:50 pm Post subject: |
|
|
I've openned bug #88880 concerning this issue, with a possible fix + ebuild for people to use to test this. I don't have an amd64 box on which to test, so *please* give this a shot and report on the bug any problem/success you have with that patch. Thanks.
_________________
overlays - Use at your own risk. File bug reports on this stuff and i'll kick you in the junk. Ask me before asking upstream if these fail. I mean it. No, really.
#gentoo-dotnet on freenode |
|
| Back to top |
|
|
isolationism
Tux's lil' helper
Joined: 01 Nov 2004
Posts: 127
|
| Posted: Wed Apr 13, 2005 4:33 am Post subject: |
|
|
I wanted to give this a try but I couldn't even get close to actually compiling it because of the dependencies. I had mono 1.0.4 installed (and working, as far as I could tell) but it seems this mod_mono ebuild has a dependency chain that requires xsp-1.0.6. XSP itself errors out almost immediately when compiling:
| Code: |
/usr/bin/mcs -debug+ -debug:full -nologo -r:System.Web.dll /out:xsp.exe ./IApplicationHost.cs ./MonoWorkerRequest.cs ./Tracing.cs ./ApplicationServer.cs ./LingeringNetworkStream.cs ./BaseApplicationHost.cs ./BaseRequestBroker.cs ./IWebSource.cs ./server.cs ./InitialWorkerRequest.cs ./XSPApplicationHost.cs ./XSPWorkerRequest.cs AssemblyInfo.cs
** (/usr/lib/mono/2.0/gmcs.exe:10901): WARNING **: Could not find assembly System, references from /usr/lib/mono/2.0/gmcs.exe (assemblyref_index=1)
Major/Minor: 2,0
Build: 3600,0
Token: b77a5c561934e089
System error: No such file or directory
** (/usr/lib/mono/2.0/gmcs.exe:10901): WARNING **: Could not load class from token 0x01000052 in /usr/lib/mono/2.0/gmcs.exe
** (/usr/lib/mono/2.0/gmcs.exe:10901): WARNING **: Could not load class from token 0x01000053 in /usr/lib/mono/2.0/gmcs.exe
** (/usr/lib/mono/2.0/gmcs.exe:10901): WARNING **: Could not load class from token 0x01000084 in /usr/lib/mono/2.0/gmcs.exe
** (/usr/lib/mono/2.0/gmcs.exe:10901): WARNING **: Missing method .ctor in assembly /usr/lib/mono/2.0/gmcs.exe typeref index 132
Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object
make[1]: *** [mod-mono-server2.exe] Error 1
make[1]: *** Waiting for unfinished jobs....
Compilation succeeded
Compilation succeeded
make[1]: Leaving directory `/var/tmp/portage/xsp-1.0.6/work/xsp-1.0.6/server'
make: *** [all-recursive] Error 1
|
... And mentioned that if it fails to build, I should unmerge and remerge xsp (which I did, and got the same failure). I figured it might be a mono version problem, so tried to upgrade using several of the various available ebuilds for it -- all of which also failed to compile. I can't even re-emerge the existing installation of Mono I have running (1.0.4-r1) because the ebuild is no longer in Portage -- I still have the tarball in my metadata cache, but I'm not so desperate to get mono running that I want to start compiling it (and, more importantly, all of its dependencies) manually.
I have indeed read the following thread: https://forums.gentoo.org/viewtopic-t-318670.html?sid=f8bb99b57242541289811ebb950f2b7c ... where your replies have been somewhat instructional on some of the build errors I've seen trying to build Mono -- such as adding "nptl" addition to my USE flags, but even after making the addition and recompiling glibc with nptl, mono (any version attempted, including 1.0.5, 1.0.6 and 1.1.6) have failed to compile with what look like similar errors. It anyway looks as though you yourself, latexer, have masked all 1.1* mono releases in the packages.mask file, so evidently either mono 1.0.5-r5 or 1.0.6 is supposed to be working for me ... But neither seem to want to compile:
| Code: |
make[1]: Entering directory `/var/tmp/portage/mono-1.0.5-r5/work/mcs-1.0.5/mcs'
../jay/jay -ctv < ../jay/skeleton.cs cs-parser.jay > jay-tmp.out && mv jay-tmp.out cs-parser.cs
../jay/jay: 3 rules never reduced
../jay/jay: 30 shift/reduce conflicts, 1 reduce/reduce conflict.
/var/tmp/portage/mono-1.0.5-r5/work/mono-1.0.5/runtime/mcs -d:NET_1_1 -d:ONLY_1_1 -g /target:exe /out:mcs.exe cs-parser.cs @mcs.exe.sources
/var/tmp/portage/mono-1.0.5-r5/work/mono-1.0.5/runtime/mcs: line 1: /var/tmp/portage/mono-1.0.5-r5/work/mono-1.0.5/mono/mini/mono: No such file or directory
make[1]: *** [mcs.exe] Error 127
make[1]: Leaving directory `/var/tmp/portage/mono-1.0.5-r5/work/mcs-1.0.5/mcs'
make: *** [all-recursive] Error 1
|
Thanks very much for your hard work in getting mono working on amd64. I hope I haven't done something stupid/annoying -- I appreciate the diligence of yourself and people like you who continue to throw their backs into getting packages to run on amd64. |
|
| Back to top |
|
|
I1uv4t4r
n00b
Joined: 11 Dec 2004
Posts: 21
Location: Netherlands, Europe
|
| Posted: Wed Apr 13, 2005 12:47 pm Post subject: |
|
|
I don't exactly have a solution to your problem, but everything works on my pc (amd64). I think you should try to unmerge all mono related packages, then merge the latest hard masked package (1.1.6 atm). For that package it is mandatory that you have compiled glibc with ntpl enabled. Then try to merge other packages, like mod_mono and xsp. Best is to use the latest testing packages.
Note that bug 88880 is probably obsolete already because mod_mono-1.0.8 en xsp-1.0.8 has been released (not in the portage tree yet, but you can make your own ebuild by copying an older one), and this mod_mono release has the fix in it.
I've just merged the 1.0.8 releases and they are working fine. |
|
| Back to top |
|
|
taskara
Advocate
Joined: 10 Apr 2002
Posts: 3763
Location: Australia
|
| Posted: Sat May 28, 2005 1:53 am Post subject: |
|
|
do we need 32bit support for dev_mono under gentoo? or will this work on a pure 64bit system?
cheers
update: seems to work on a pure 64bit system
_________________
Kororaa install method - have Gentoo up and running quickly and easily, fully automated with an installer! |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo on AMD64
