Current-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: lang/mono6 fails build under -current
On Sun, May 17, 2020 at 09:58:49AM +0100, Chavdar Ivanov wrote:
> On Fri, 15 May 2020 at 22:44, <maya%netbsd.org@localhost> wrote:
> > I am failing to reproduce it on 9.99.61. Any other guesses for what
> > might be different on your setup?
>
> No idea. It is a laptop with i7-3820QM CPU and 20GB memory, following
> -current, both the OS and pkgsrc, with many pkg_rolling-replace under
> its belt. Perhaps it is time to reinstall it...
>
> I spun a new VM (XCP-NG pvhvm domU, with just 4 virtual CPUs and 2GB
> memory), extracted and updated pkgsrc as of yesterday, mono6 built
> fine and I was then able to install the package on the troubled
> system:
>
> $ mono --version
> Mono JIT compiler version 6.8.0.105 (tarball Sat May 16 22:47:11 BST 2020)
> Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors.
> www.mono-project.com
> TLS: __thread
> SIGSEGV: normal
> Notification: kqueue
> Architecture: amd64
> Disabled: none
> Misc: softdebug
> Interpreter: yes
> LLVM: supported, not enabled.
> Suspend: preemptive
> GC: sgen (concurrent by default)
>
> The thing is, while pkg_rolling-replace does simplify the gradual
> updates of packages, there are situations it can't deal with; e.g. 4-5
> days ago I updated and ran pkg_rolling-replace, which completed rather
> well, with only about 10 packages failing due to being obsoleted etc.;
> all the tex packages I have installed upgraded without a problem.
> Yesterday I did another update, this time rolling-replace rendered
> hundreds of failed upgrades among the tex packages. The reason (one of
> the reasons) turned out to be a new version of kpathsea - 6.3.2 -
> which now depends on mktexlsr package; this one has been split from
> kpathsea and contains a file - well, mktexlsr - which is also part of
> kpathsea-6.3.1; so mktexlsr can't be installed over kpathsea, and
> kpathsea can't be upgraded as mktexlsr is missing... And this was not
> the only problem.
As an unrelated but interesting side note, Mono is the only package I've
seen make a Xen-specific optimization.
mono_x86_emit_tls_get (guint8* code, int dreg, int tls_offset)
...
if (optimize_for_xen) {
x86_prefix (code, X86_GS_PREFIX);
x86_mov_reg_mem (code, dreg, 0, 4);
x86_mov_reg_membase (code, dreg, dreg, tls_offset, 4);
} else {
x86_prefix (code, X86_GS_PREFIX);
x86_mov_reg_mem (code, dreg, tls_offset, 4);
}
Home |
Main Index |
Thread Index |
Old Index