[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pkg/43230 (pkgsrc (2010Q1) package lang/mono does not compile)
The following reply was made to PR pkg/43230; it has been noted by GNATS.
From: Wolfgang Stukenbrock <Wolfgang.Stukenbrock%nagler-company.com@localhost>
Cc: Mihai Chelaru <kefren%NetBSD.org@localhost>,
Subject: Re: pkg/43230 (pkgsrc (2010Q1) package lang/mono does not compile)
Date: Mon, 03 May 2010 12:26:54 +0200
- this time the full reply list - I've took the wrong mail for reply the
first time ...
The problem was related to the fact that the kernel has no SYSV-ipc in
it. We've found the time to setup an other kernel and reboot the system.
The problem is gone now.
Sorry for the noise here ...
But it would have been a real great idea to check the availability of
SYSV-ipc on the system in configure!
Configure should not check only for the availability of some header
files - I assume it has done this ...
I think you can close this report.
Perhaps the availability check could added to congfigure in the next
version. It would be great.
Wolfgang Stukenbrock wrote:
> in general yes, but I currently don't know what to do exactly to get the
> trace. (or do you just mean a backtrace in gdb from the core file?)
> I'v found a core file mono.core in
> /usr/pkgsrc/lang/mono/work/mono-2.6.1/mcs - sorry I've overlooked this
> before, but some core-dumps are "normal" for several packages during
> compilation ...
> The script in "runtime/_tmpinst/bin/mono" seems to be the one called:
> #! /bin/sh
> export MONO_CFG_DIR MONO_SHARED_DIR PATH
> exec "$r/libtool" --mode=execute "$r/mono/mini/mono" --config
> "/usr/pkgsrc/lang/mono/work/mono-2.6.1/runtime/etc/mono/config" "$@"
> The binary that belongs to the core file seems to be the one from
> gdb says that it is semget() that is missing. OK - that may be the
> problem - on both systems I've tried to compile mono no SYSV-ipc is
> configured. (I avoid the SYSV-ipc in the kernel until I realy need it
> due to the problems with the resouce management in it.)
> It will take some time to retry with an other kernel because the System
> is in productive use here ..
> I come back as soon as possible with the results, but I think that would
> be the problem. I think it will be in 1 ore two days.
> W. Stukenbrock
> Mihai Chelaru wrote:
>> On Fri, 2010-04-30 at 17:00 +0000,
>> Wolfgang.Stukenbrock%nagler-company.com@localhost wrote:
>>>  Bad system call (core dumped) MONO_PATH=3D".//cl...
>> Can you obtain a trace from this core ?
Main Index |
Thread Index |