You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by Gert Driesen <ge...@telenet.be> on 2007/02/15 09:47:24 UTC
Issue building NAnt
I learned from Curt Arnold that there have been problems building NAnt on
the gump machine.
On unix, NAnt uses pkg-config to get information on the installed mono
package.
We did this in order to support multiple versions of Mono on a given
machine. Looking back, it might have been enough to get the path from the
mono shell script located in the PATH environment variable and leave it up
to users to modify the PATH accordingly when they want to target a different
version of Mono.
For people not familiar with Mono: a single version of Mono contains a
single runtime but class libraries for multiple versions of .NET (in Mono
these are referred to as profiles). Even if you do not modify the PATH
environment variable, NAnt will still support targeting multiple versions
.NET.
When we decided to use pkg-config to retrieve info on the mono package, the
actual packaging of Mono was not yet clear and we assumed that they'd ship a
separate package for each .NET version (including both a runtime and the
class libraries).
So far for the background information.
Curt sent me the build log of one of the NAnt build failure:
<snip>
The current runtime framework 'mono-2.0' is not correctly configured
in the NAnt configuration file.
Framework directory '/usr/lib/pkgconfig/../../lib/mono/1.0' does not exist.
</snip>
Would it possible to send me the output of the following commands on the
gump machine:
$ pkg-config --modversion mono
$ pkg-config --variable=prefix mono
$ pkg-config --variable=libdir mono
$ which mono
Can you also verify whether the following files/directories exist:
$prefix/bin/mono
$prefix/lib/mono/1.0 <= this probably won't exist
Our framework support is configured using NAnt projects in the NAnt
configuration file (NAnt.exe.config), and by reviewing it I noticed that we
do not use the value of the libdir variable, but instead assume that its
$prefix/lib. This is ofcourse not correct.
I'll stay on this until it's working.
Gert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Issue building NAnt
Posted by Sander Temme <sc...@apache.org>.
On Feb 18, 2007, at 9:34 PM, Stefan Bodewig wrote:
> On Fri, 16 Feb 2007, Gert Driesen <ge...@telenet.be> wrote:
>> So either:
>>
>> * you update Mono to a release that does not yet contain this extra
>> * strict compiler behavior (1.2.0 or 1.2.1 should be ok)
>
> this would be my preferred option. I don't think I'll find time to do
> that before the next weekend, though.
FWIW I updated Mono on Clarus last night and the NAnt build is now
fixed:
http://clarus.apache.org/nant/nant/index.html
S.
--
sctemme@apache.org http://www.temme.net/sander/
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Re: Issue building NAnt
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 16 Feb 2007, Gert Driesen <ge...@telenet.be> wrote:
> So either:
>
> * you update Mono to a release that does not yet contain this extra
> * strict compiler behavior (1.2.0 or 1.2.1 should be ok)
this would be my preferred option. I don't think I'll find time to do
that before the next weekend, though.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Issue building NAnt
Posted by Gert Driesen <ge...@telenet.be>.
----- Original Message -----
From: "Stefan Bodewig" <bo...@apache.org>
To: <ge...@gump.apache.org>
Sent: Monday, February 19, 2007 6:36 AM
Subject: Re: Issue building NAnt
> On Sat, 17 Feb 2007, Gert Driesen <ge...@telenet.be> wrote:
>
>> I wonder if Ant also does not require to bootstrap the version of
>> Ant that you want to build.
>
> Ant bootstraps itself in Gump, yes. It does so using a shell script
> that is part of the distribution.
We ship with a small shell script for bootstrapping as well.
Gert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Issue building NAnt
Posted by Stefan Bodewig <bo...@apache.org>.
On Sat, 17 Feb 2007, Gert Driesen <ge...@telenet.be> wrote:
> I wonder if Ant also does not require to bootstrap the version of
> Ant that you want to build.
Ant bootstraps itself in Gump, yes. It does so using a shell script
that is part of the distribution.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
RE: Issue building NAnt
Posted by Gert Driesen <ge...@telenet.be>.
> -----Original Message-----
> From: Curt Arnold [mailto:carnold@apache.org]
> Sent: zaterdag 17 februari 2007 6:20
> To: Gump code and data
> Subject: Re: Issue building NAnt
>
>
> On Feb 16, 2007, at 7:09 PM, Curt Arnold wrote:
> > However, if you try to do "nant" or "nant test", you will get a
> > failure that <exec> doesn't support the managed attribute. It
> > appears that the build file for NAnt requires features that are not
> > in NAnt 0.85. Removing the managed="true" replaces that error with
> > another when it tries to run the generated nant.exe as a Mac OS/X
> > executable.
> >
> >
>
> Changing managed="true" to useruntimeengine="true" will let the units
> test pass. I'd suggest using the old name so that you can build the
> next release of NAnt with the current release of NAnt and make the
> switch after the next release. Basically undo this commit: http://
> nant.cvs.sourceforge.net/nant/nant/NAnt.build?r1=1.236&r2=1.237
I wonder if Ant also does not require to bootstrap the version of Ant that
you want to build.
I don't think it's necessary to ensure NAnt can be built using a previous
release, if such a bootstrap procedure is in place.
Nevertheless, I have no problem undoing that commit. It's your call.
Gert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Issue building NAnt
Posted by Curt Arnold <ca...@apache.org>.
On Feb 16, 2007, at 7:09 PM, Curt Arnold wrote:
> However, if you try to do "nant" or "nant test", you will get a
> failure that <exec> doesn't support the managed attribute. It
> appears that the build file for NAnt requires features that are not
> in NAnt 0.85. Removing the managed="true" replaces that error with
> another when it tries to run the generated nant.exe as a Mac OS/X
> executable.
>
>
Changing managed="true" to useruntimeengine="true" will let the units
test pass. I'd suggest using the old name so that you can build the
next release of NAnt with the current release of NAnt and make the
switch after the next release. Basically undo this commit: http://
nant.cvs.sourceforge.net/nant/nant/NAnt.build?r1=1.236&r2=1.237
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Issue building NAnt
Posted by Curt Arnold <ca...@apache.org>.
On Feb 16, 2007, at 6:05 PM, Curt Arnold wrote:
>
> I have Mac OS/X boxes (both Intel and PowerPC). Have never fired
> up Mono on them, but could give it a shot. However it would not be
> until Monday. I'll move any more NAnt on Mono discussion to the
> NAnt-dev mailing list.
>
I'm a very sick man. Went ahead and installed MonoFramework-1.2.3.1
on Mac OS/X and got NAnt to build but not run self-test, but that
should be a start.
1. Download Mono 1.2.3.1_0 Framework - Universal (Stable) from http://
www.mono-project.com/Downloads
2. Install framework
3. Modify /Library/Frameworks/Mono.framework/Versions/1.2.3.1/bin/nant
Mono comes with a prebuilt NAnt 0.85, but on Mac OS/X, it needs to
have the export PKG_CONFIG_PATH statement added to the nant file.
#!/bin/sh
export PKG_CONFIG_PATH=/Library/Frameworks/Mono.framework/Versions/
Current/lib/pkgconfig
/Library/Frameworks/Mono.framework/Versions/1.2.3.1/lib/
pkgconfig/../../bin/mono /Library/Frameworks/Mono.framework/Versions/
1.2.3.1/lib/NAnt/NAnt.exe "$@"
See http://www.bleepsoft.com/tyler/index.php?itemid=82 and http://
bugzilla.ximian.com/show_bug.cgi?id=79671. Bug should be fixed in
next release of Mono.
At this point, you should have a usable NAnt 0.85 and all the Mono
compilers on the execute path. If you check out NAnt from the source
code repository, you can successfully do:
nant build
However, if you try to do "nant" or "nant test", you will get a
failure that <exec> doesn't support the managed attribute. It
appears that the build file for NAnt requires features that are not
in NAnt 0.85. Removing the managed="true" replaces that error with
another when it tries to run the generated nant.exe as a Mac OS/X
executable.
I'd recommend, update Mono on Clarus and changing the NAnt gump
descriptor to run "nant build" for now. I'd recommend adding a
"gump" target to NAnt.build in the NAnt CVS and then changing the
NAnt gump descriptor to run that.
NAnt uses log4net which uses NAnt, so we have a little cyclical
dependency. Ideally, we would get Gump to build NAnt with its
embedded log4net using the framework NAnt, use the built NAnt to
build log4net and then build NAnt again using the previously built
NAnt and log4net. One step at a time however.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Issue building NAnt
Posted by Curt Arnold <ca...@apache.org>.
On Feb 16, 2007, at 3:42 PM, Gert Driesen wrote:
>>
>> Looking at the code that fails on Mono, it looks like the problem is
>> that Mono is detected as supporting .NET 2 but is missing a framework
>> method expected to be there.
>
> NAnt by default targets that CLR on which its running, and it by
> default
> runs on the latest supported CLR.
>
> Hence on a system containing both the 1.0 and 2.0 profile of Mono,
> NAnt is
> built targeting Mono 2.0.
>
> Note: you can of course still build application targeting Mono 1.0
> using a
> version of NAnt that was built for Mono 2.0.
>> I'm guessing that it would either
>> successfully compile on something earlier that was not detected
>> as .NET 2 or something later that had the missing method. Do you
>> know of a later version of Mono that NAnt does build on? Updating
>> the Mono version seems to be the right direction as I'm guessing .NET
>> 1 is slowly fading (though I'm not in that world very much).
>
> Problem is that Mono's C# compiler has become more (and in some
> cases too)
> strict.
>
> Since we always compile NAnt with /warnaserror (to ensure we have
> clean
> code), you'll also get a build failure with the 0.85 release on
> very recent
> versions of Mono. The "issue" that the newer compiler reports is
> fixed in
> CVS though.
>
> I'm not sure what the best way of fixing this is. I was considering
> releasing a new (beta) version of NAnt anyway, but then again I
> think you
> guys want official releases only.
>
> So either:
>
> * you update Mono to a release that does not yet contain this extra
> strict
> compiler behavior (1.2.0 or 1.2.1 should be ok)
> * I provide you with a build script patch that causes the /warnaserror
> option not be set
> * I release a new (beta) version of NAnt for you to use
>
> I wish there were other (better) options, but I can't think of any
> right
> now. Perhaps we should stop treating warnings as error when
> compiling NAnt.
> It keeps code clean, but also leads to issues like this one here.
Looking at the message in the Claris log (and not having tried to
build on Mono or checking the Mono revision history), the problem
does not appear to be the compiler, but that the framework is missing
a method that should have been in NET 2.0. The failure message is:
[csc] /Volumes/X1/home/sctemme/work/workspace/nant/
src/NAnt.VSNet/WrapperReferenceBase.cs(358,20): error CS1502: The
best overloaded method match for
`System.Runtime.InteropServices.Marshal.GetTypeLibName
(System.Runtime.InteropServices.UCOMITypeLib)' has some invalid
arguments
[csc] /Volumes/X1/home/sctemme/work/workspace/nant/
src/NAnt.VSNet/WrapperReferenceBase.cs(358,20): error CS1503:
Argument 1: Cannot convert from
`System.Runtime.InteropServices.ComTypes.ITypeLib' to
`System.Runtime.InteropServices.UCOMITypeLib'
[csc] Compilation failed: 2 error(s), 0 warnings
The corresponding code is:
357 #if NET_2_0
358 return Marshal.GetTypeLibName((ITypeLib) typeLib);
359 #else
360 return Marshal.GetTypeLibName((UCOMITypeLib)
typeLib);
361 #endif
The interpretation I have of the failure is that NET_2_0 is true
(hence line 358 appearing in the compiler error), however
Marshal.GetTypeLibName(ITypeLib) which was introduced in .NET 2.0 is
not available in the framework only the obsolete
Marshal.GetTypeLibName(UCOMITypeLib).
Providing a pre-built NAnt is not the ideal solution. It might be
the best possible, but I'm not there yet.
From http://gump.apache.org:
>
> Gump is unique in that it builds and compiles software against the
> latest development versions of those projects. This allows gump to
> detect potentially incompatible changes to that software just a few
> hours after those changes are checked into the version control
> system. Notifications are sent to the project team as soon as such
> a change is detected, referencing more detailed reports available
> online.
A large number of Java projects in Gump are built using Apache Ant.
As Gump builds its projects, it does not use a released version of
Ant but builds it from the current SVN repository. If the Ant
developers mess up something, it could cause 100s of other projects
to fail their build. Eventually, the problem would be traced back to
a modification in the Ant code and the offending code would be
reverted or corrected. Since this is done shortly after the time
that the change was committed and long before people would have
become attached to the new behavior, it should be relatively painless
to correct. If Gump used only released versions of Ant, then a
problem could exist in the Ant SVN for a long time before it was
noticed, additional code might have been written that depended on the
new behavior and it might be very complicated to unwind the problem.
Obviously, there is not the equivalent stack of .NET applications
that depend on NAnt that are built by Gump. But the potential is there.
I have Mac OS/X boxes (both Intel and PowerPC). Have never fired up
Mono on them, but could give it a shot. However it would not be
until Monday. I'll move any more NAnt on Mono discussion to the NAnt-
dev mailing list.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
RE: Issue building NAnt
Posted by Gert Driesen <ge...@telenet.be>.
> -----Original Message-----
> From: Curt Arnold [mailto:carnold@apache.org]
> Sent: vrijdag 16 februari 2007 21:54
> To: Gump code and data
> Subject: Re: Issue building NAnt
>
>
> On Feb 16, 2007, at 10:30 AM, Sander Temme wrote:
>
> >
> > On Feb 16, 2007, at 7:46 AM, Gert Driesen wrote:
> >
> >> You either need a more recent version of Mono, or I could modify
> >> NAnt to
> >> allow it to compile on that version of Mono. I don't know if you'd
> >> consider
> >> using a nightly build (or any non-released version) of NAnt.
> >
> > I'll look into upgrading Mono on Clarus. Using nightly builds is
> > not what Gump is about: it merely tries to compile the latest,
> > perhaps-not-so-greatest of everything, satisfying dependencies with
> > the development trunk of that moment. It uses that to find out
> > when/where things break at the earliest possible moment.
> >
>
> Looking at the code that fails on Mono, it looks like the problem is
> that Mono is detected as supporting .NET 2 but is missing a framework
> method expected to be there.
NAnt by default targets that CLR on which its running, and it by default
runs on the latest supported CLR.
Hence on a system containing both the 1.0 and 2.0 profile of Mono, NAnt is
built targeting Mono 2.0.
Note: you can of course still build application targeting Mono 1.0 using a
version of NAnt that was built for Mono 2.0.
> I'm guessing that it would either
> successfully compile on something earlier that was not detected
> as .NET 2 or something later that had the missing method. Do you
> know of a later version of Mono that NAnt does build on? Updating
> the Mono version seems to be the right direction as I'm guessing .NET
> 1 is slowly fading (though I'm not in that world very much).
Problem is that Mono's C# compiler has become more (and in some cases too)
strict.
Since we always compile NAnt with /warnaserror (to ensure we have clean
code), you'll also get a build failure with the 0.85 release on very recent
versions of Mono. The "issue" that the newer compiler reports is fixed in
CVS though.
I'm not sure what the best way of fixing this is. I was considering
releasing a new (beta) version of NAnt anyway, but then again I think you
guys want official releases only.
So either:
* you update Mono to a release that does not yet contain this extra strict
compiler behavior (1.2.0 or 1.2.1 should be ok)
* I provide you with a build script patch that causes the /warnaserror
option not be set
* I release a new (beta) version of NAnt for you to use
I wish there were other (better) options, but I can't think of any right
now. Perhaps we should stop treating warnings as error when compiling NAnt.
It keeps code clean, but also leads to issues like this one here.
> As for vmgump, previous statements suggest it is pretty precarious
> and I doubt that the benefit would be worth the risk to touch Mono on
> it until the next major externally driven change. For log4net, as
> long as we had NAnt and log4net building on Claris and ideally with
> nag messages sent to the appropriate mailing lists, things would be
> good.
Sounds like a plan.
Gert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Issue building NAnt
Posted by Curt Arnold <ca...@apache.org>.
On Feb 16, 2007, at 10:30 AM, Sander Temme wrote:
>
> On Feb 16, 2007, at 7:46 AM, Gert Driesen wrote:
>
>> You either need a more recent version of Mono, or I could modify
>> NAnt to
>> allow it to compile on that version of Mono. I don't know if you'd
>> consider
>> using a nightly build (or any non-released version) of NAnt.
>
> I'll look into upgrading Mono on Clarus. Using nightly builds is
> not what Gump is about: it merely tries to compile the latest,
> perhaps-not-so-greatest of everything, satisfying dependencies with
> the development trunk of that moment. It uses that to find out
> when/where things break at the earliest possible moment.
>
Looking at the code that fails on Mono, it looks like the problem is
that Mono is detected as supporting .NET 2 but is missing a framework
method expected to be there. I'm guessing that it would either
successfully compile on something earlier that was not detected
as .NET 2 or something later that had the missing method. Do you
know of a later version of Mono that NAnt does build on? Updating
the Mono version seems to be the right direction as I'm guessing .NET
1 is slowly fading (though I'm not in that world very much).
As for vmgump, previous statements suggest it is pretty precarious
and I doubt that the benefit would be worth the risk to touch Mono on
it until the next major externally driven change. For log4net, as
long as we had NAnt and log4net building on Claris and ideally with
nag messages sent to the appropriate mailing lists, things would be
good.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Issue building NAnt
Posted by Sander Temme <sc...@apache.org>.
On Feb 16, 2007, at 7:46 AM, Gert Driesen wrote:
> You either need a more recent version of Mono, or I could modify
> NAnt to
> allow it to compile on that version of Mono. I don't know if you'd
> consider
> using a nightly build (or any non-released version) of NAnt.
I'll look into upgrading Mono on Clarus. Using nightly builds is not
what Gump is about: it merely tries to compile the latest, perhaps-
not-so-greatest of everything, satisfying dependencies with the
development trunk of that moment. It uses that to find out when/
where things break at the earliest possible moment.
> I would still be interested in getting the information I requested
> earlier
> for the other machine (VMGump).
That's right, I have a login for that too:
sctemme@vmgump:~$ pkg-config --modversion mono
1.1.13.2
sctemme@vmgump:~$ pkg-config --variable=prefix mono
/usr/lib/pkgconfig/../..
sctemme@vmgump:~$ pkg-config --variable=libdir mono
/usr/lib/pkgconfig/../../lib
sctemme@vmgump:~$ which mono
sctemme@vmgump:~$ ls -l `pkg-config --variable=prefix mono`/bin/mono
ls: /usr/lib/pkgconfig/../../bin/mono: No such file or directory
sctemme@vmgump:~$ ls -l `pkg-config --variable=prefix mono`/lib/mono/1.0
ls: /usr/lib/pkgconfig/../../lib/mono/1.0: No such file or directory
/usr/lib/mono also doesn't exist. It seems that we have an incomplete
installation on that box.
Back to Clarus, I wasn't reading your instructions correctly. The
*library* path *does* exist on that box:
clarus:~ sctemme$ ls -l `pkg-config --variable=prefix mono`/lib/mono
total 0
drwxr-xr-x 134 root wheel 4556 Jan 24 2006 1.0
drwxr-xr-x 74 root wheel 2516 Jan 24 2006 2.0
drwxr-xr-x 4 root wheel 136 Jan 24 2006 cocoa-sharp
drwxr-xr-x 3 root wheel 102 Jan 24 2006 compat-1.0
drwxr-xr-x 3 root wheel 102 Jan 24 2006 compat-2.0
drwxr-xr-x 65 root wheel 2210 Jan 24 2006 gac
drwxr-xr-x 3 root wheel 102 Jan 24 2006 monodoc
drwxr-xr-x 8 root wheel 272 Jan 24 2006 xbuild
Both the 1.0 and 2.0 directories are full of stuff.
Clarus and vmgump are getting different errors:
http://vmgump.apache.org/gump/public/nant/nant/gump_work/
build_nant_nant.html
This one seems to be due to the broken mono install.
sctemme@vmgump:~$ dpkg -l mono
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-
installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err:
uppercase=bad)
||/ Name Version Description
+++-==============-==============-
============================================
pn mono <none> (no description available)
sctemme@vmgump:~$
Perhaps someone with the necessary Fu on vmgump can run a broom
through that?
S.
--
sctemme@apache.org http://www.temme.net/sander/
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
RE: Issue building NAnt
Posted by Gert Driesen <ge...@telenet.be>.
> -----Original Message-----
> From: Sander Temme [mailto:sctemme@apache.org]
> Sent: vrijdag 16 februari 2007 16:35
> To: Gert Driesen
> Cc: 'Gump code and data'
> Subject: Re: Issue building NAnt
>
>
> On Feb 15, 2007, at 11:14 PM, Gert Driesen wrote:
>
> > Is the NAnt build actually failing on that machine, or was the
> > build log I
> > got from Curt Arnold taken from another machine ?
>
> The Gump that sends out mail is on another machine (VMGump), but NAnt
> is also failing on Clarus:
>
> http://clarus.apache.org/nant/nant/gump_work/build_nant_nant.html
>
> > I do not have access to a Mac OS X, so I have not been able to try
> > it out
> > myself.
>
> It *should* be the same, right? Since you're running on top of .NET
> 'n all.
>
> Are you Apache committer? If so I can let you on that box.
I am, but in this case there isn't much I can do. In NAnt 0.85, we
apparently use a method (when targeting .NET 2.0) that was not yet
implemented in Mono 1.13.2.
You either need a more recent version of Mono, or I could modify NAnt to
allow it to compile on that version of Mono. I don't know if you'd consider
using a nightly build (or any non-released version) of NAnt.
I would still be interested in getting the information I requested earlier
for the other machine (VMGump).
Gert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Issue building NAnt
Posted by Sander Temme <sc...@apache.org>.
On Feb 15, 2007, at 11:14 PM, Gert Driesen wrote:
> Is the NAnt build actually failing on that machine, or was the
> build log I
> got from Curt Arnold taken from another machine ?
The Gump that sends out mail is on another machine (VMGump), but NAnt
is also failing on Clarus:
http://clarus.apache.org/nant/nant/gump_work/build_nant_nant.html
> I do not have access to a Mac OS X, so I have not been able to try
> it out
> myself.
It *should* be the same, right? Since you're running on top of .NET
'n all.
Are you Apache committer? If so I can let you on that box.
S.
--
sctemme@apache.org http://www.temme.net/sander/
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
RE: Issue building NAnt
Posted by Gert Driesen <ge...@telenet.be>.
> -----Original Message-----
> From: Sander Temme [mailto:sctemme@apache.org]
> Sent: vrijdag 16 februari 2007 7:45
> To: Gump code and data; Gert Driesen
> Subject: Re: Issue building NAnt
>
>
> On Feb 15, 2007, at 12:47 AM, Gert Driesen wrote:
>
> > Would it possible to send me the output of the following commands
> > on the gump machine:
> >
> > $ pkg-config --modversion mono
> > $ pkg-config --variable=prefix mono
> > $ pkg-config --variable=libdir mono
> > $ which mono
>
> On clarus.apache.org. (an Xserve running Mac OS X Server 10.4.8, and
> Gump):
>
> clarus:~ sctemme$ pkg-config --modversion mono
> 1.1.13.2
> clarus:~ sctemme$ pkg-config --variable=prefix mono
> /Library/Frameworks/Mono.framework/Versions/1.1.13.2/lib/pkgconfig/../.
> .
> clarus:~ sctemme$ pkg-config --variable=libdir mono
> /Library/Frameworks/Mono.framework/Versions/1.1.13.2/lib/
> pkgconfig/../../lib
> clarus:~ sctemme$ which mono
> /usr/bin/mono
> clarus:~ sctemme$ ls -l /usr/bin/mono
> lrwxr-xr-x 1 root wheel 48 Feb 18 2006 /usr/bin/mono -> /Library/
> Frameworks/Mono.framework/Commands/mono
>
>
> > Can you also verify whether the following files/directories exist:
> >
> > $prefix/bin/mono
>
> clarus:~ sctemme$ ls -l `pkg-config --variable=prefix mono`/bin/mono
> -rwxr-xr-x 1 root wheel 4539848 Jan 24 2006 /Library/Frameworks/
> Mono.framework/Versions/1.1.13.2/lib/pkgconfig/../../bin/mono
>
> > $prefix/lib/mono/1.0 <= this probably won't exist
>
> The above is a regular file so, no.
>
> If there is anything else I can do to help, please let me know.
Is the NAnt build actually failing on that machine, or was the build log I
got from Curt Arnold taken from another machine ?
I do not have access to a Mac OS X, so I have not been able to try it out
myself.
Gert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Issue building NAnt
Posted by Sander Temme <sc...@apache.org>.
On Feb 15, 2007, at 12:47 AM, Gert Driesen wrote:
> Would it possible to send me the output of the following commands
> on the gump machine:
>
> $ pkg-config --modversion mono
> $ pkg-config --variable=prefix mono
> $ pkg-config --variable=libdir mono
> $ which mono
On clarus.apache.org. (an Xserve running Mac OS X Server 10.4.8, and
Gump):
clarus:~ sctemme$ pkg-config --modversion mono
1.1.13.2
clarus:~ sctemme$ pkg-config --variable=prefix mono
/Library/Frameworks/Mono.framework/Versions/1.1.13.2/lib/pkgconfig/../..
clarus:~ sctemme$ pkg-config --variable=libdir mono
/Library/Frameworks/Mono.framework/Versions/1.1.13.2/lib/
pkgconfig/../../lib
clarus:~ sctemme$ which mono
/usr/bin/mono
clarus:~ sctemme$ ls -l /usr/bin/mono
lrwxr-xr-x 1 root wheel 48 Feb 18 2006 /usr/bin/mono -> /Library/
Frameworks/Mono.framework/Commands/mono
> Can you also verify whether the following files/directories exist:
>
> $prefix/bin/mono
clarus:~ sctemme$ ls -l `pkg-config --variable=prefix mono`/bin/mono
-rwxr-xr-x 1 root wheel 4539848 Jan 24 2006 /Library/Frameworks/
Mono.framework/Versions/1.1.13.2/lib/pkgconfig/../../bin/mono
> $prefix/lib/mono/1.0 <= this probably won't exist
The above is a regular file so, no.
If there is anything else I can do to help, please let me know.
S.
--
sctemme@apache.org http://www.temme.net/sander/
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF