J. Christopher Six wrote:
I saw the same segfault on Novell linux Desktop and I got it to happen even when runningI bypassed use of the Makefile and was able to successfully build nant by directly issuing:
mono bin/NAnt.exe -f:NAnt.build build
Curiously, this is identical to the command that is invoked by running "make" under a non-WinNT environment.
I'm still uncertain why it was segfaulting under make, as I have a
fairly standard x86 Gentoo system configuration with kernel 2.6.8,
mono bin/NAnt.exe -f:NAnt.build build
so I don't think its a make issue. I also saw the build succeed at least once so it seems the segfault is maybe not consistently reproducible.
although I did compile the Native Posix Threading Library into glibcactually we'll be removing bin\nant and have the make file build a bootstrap NAnt from source. This will remove the need to have pre-built binaries in the source distro.
(and of course re-compiled all affected packages). There doesn't seem
to be any rationale (other than convention) for using "make" as a
front-end to NAnt.exe for the build. Perhaps this method should be
scrapped in favor of .bat and .sh scripts?
Anyhow, having successfully built nant I attempted a make-less install in a similar fashion:
mono bin/NAnt.exe install -D:install.prefix=/usr
Everything was going well until I encountered:
[exec] self-userdoc: [exec] [exec] [ndoc] Initializing... [exec] [ndoc] Merging XML documentation... [exec] [ndoc] Building mapping... [exec] [ndoc] Creating Task Index Page... [exec] [ndoc] Creating Type Index Page... [exec] [ndoc] Creating Filter Index Page... [exec] [ndoc] Creating Function Index Page... [exec] [ndoc] Generating Task Documents...
-- whereupon ndoc proceeded to munch 100% CPU for over an hour.
Interesting. Looking at the build file it should never build userdoc on linux
<target name="install" depends="install-windows, install-linux" />
<target name="install-windows" depends="userdoc" if="${platform::is-win32()}">
...
<target name="install-linux" depends="build" if="${platform::is-unix()}">
Could you run a small test build to verify that ${platform::is-win32()} is correctly returning false on your system ?
The reason we skip it on linux is because mcs does not support the /doc argument which generates the xml used by ndoc. However a patch for this will soon be applied to mono svn so we'll build it then.
That makes it even stranger that ndoc is taking so long when it doesn't have valid doc.xml to process - or maybe thats the reason. What does the final html doc look like ?
Ian
Mind you, this is under a 2 GHz Athlon XP and 1 GB DDR400 RAM. I allowed the process to continue (though not with infinite patience), and luckily the installation finally completed and nant appears to be functional. I'm wondering if the culprit is use of the pre-built ndoc binary under mono. If I get some time later I'll try swapping it with a locally built ndoc to see if that makes any difference.
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
Nant-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-users
