FWIW I am OK with jca's diff and intend to commit it on Monday if
nothing else is worked out beforehand.
On 2018/12/01 10:11, Landry Breuil wrote:
> On Tue, Nov 27, 2018 at 12:45:36PM +0100, Jeremie Courreges-Anglas wrote:
> > On Tue, Nov 06 2018, Stuart Henderson <stu@spacehopper.org> wrote:
> > > On 2018/11/06 11:11, John Gould wrote:
> > >> Hello, I am trying to build parts of xfce4 and some kde4 applications on
> > >> 6.4 current on sparc64.
> > >> Although these applications worked or were available from packages on 6.3 I
> > >> am having no
> > >> luck on 6.4. I have several sparc machines here all doing nothing! Can
> > >> someone please help me with this or am I wasting my time? I've included a
> > >> dmesg below and some of the output of a recent build.
> > >>
> > >> Kind regards John
> > >>
> > >> /usr/ports/pobj/llvm-6.0.1/llvm-6.0.1.src/tools/lldb/include/lldb/Host/Editline.h:49:19:
> > >> fatal error: codecvt: No such file or directory
> > >>
> > >> #include <codecvt>
> > >>
> > >> ^
> > >
> > > This is exactly the reason why these are not available in packages on
> > > 6.4. The patch below for devel/llvm should get things unblocked though I
> > > don't know if it will help get you as far as the ports you're really
> > > interested in.
> >
> > Thanks. Diff refreshed for -current, successfully tested on sparc64
> > (and amd64).
> >
> > IMO this has been broken since too long already. I'd like us to fix
> > what we can now instead of waiting for a switch to gcc 6 in the upcoming
> > weeks/months/releases. Stuart, if you want to commit this, ok jca@
>
> Brad, you're still listed as the maintainer of devel/llvm, and you proxy
> commits to it via sthen@ and ajacoutot@, so i understand that you still
> work on it. devel/llvm has been broken on sparc64 (and maybe macppc,
> we'll see) since you rushed the 'enable lldb' bits before 6.4, which
> resulted in the low amount of sparc64 release packages for 6.4, and that
> affects actual users of the platform.
>
> I've loudly complained about it, sthen@ proposed a variation of the diff
> below that i've successfully tested in one of the past bulks, and i
> think you know it.
>
> Now, i know that "switching to gcc6" also fixes it, but it requires more
> work before being a short-time goal, so to unblock the situation, will
> you step up and give your opinion on jca@'s diff so that we can move
> forward ?
>
> I'm starting a sparc64 bulk without any diff. As a result, it wont have
> llvm & any of the packages depending on it, which i think is better:
> If llvm is available, all c++ ports end up depending on gcc (for
> libstdc++) *and* llvm because many (340-so) ports have
> COMPILER=base-clang ports-clang ports-gcc which is deeply wrong, but
> this has to be fixed separately from the lldb issue. For which as
> MAINTAINER, you have to step up.
>
> Thanks.
>
> Landry
>
Saturday, December 01, 2018
statethreads crashes in ld on 6.4
statethreads (http://state-threads.sourceforge.net/) crashes on
OpenBSD 6.4/amd64 (release) with an error in ld (see below); it
works fine on previous OpenBSD versions. Do I have to set some
"special" cc/ld options to make this work? Or are patches to
statehreads required (there doesn't seem to be a port for it,
otherwise I would try that)?
#0 0x00000c0b0980db08 in _dl_bind (object=0xc0a85cff400, index=)
from /usr/libexec/ld.so
(gdb) where
#0 0x00000c0b0980db08 in _dl_bind (object=0xc0a85cff400, index=)
from /usr/libexec/ld.so
#1 0x00000c0b098080dd in _dl_bind_start ()
at /usr/src/libexec/ld.so/amd64/ldasm.S:108
#2 0x00000c08448058bc in st_accept (fd=0xc0a634981c0, addr=0xc0ae5a31dd0,
addrlen=0xc0ae5a31dcc, timeout=18446744073709551615)
at ../../mta/statethreads/io.c:258
#3 0x00000c0844802928 in handle_connections (arg=0x0)
at ../../../mta/statethreads/examples/server.c:880
#4 0x00000c0844803e4a in st_thread_create (start=0, arg=)
at ../../mta/statethreads/sched.c:329
#5 0x00000c0844801e38 in start_threads ()
at ../../../mta/statethreads/examples/server.c:855
#6 0x00000c0844800b17 in main (argc=6, argv=0x7f7ffffd4ec8)
at ../../../mta/statethreads/examples/server.c:266
(gdb) print *object
$2 = {obj_base = 13229648510976, load_name = 0xc0b0ee98d90 "./server",
load_dyn = 0xc0844a0dbc8, next = 0xc0a4aacb800, prev = 0x0,
load_base = 13229648510976, load_list = 0xc0a64e9c400, load_size = 2158592,
Dyn = {info = 0xc0a85cff440, u = {null = 0, needed = 1, pltrelsz = 1872,
pltgot = 0xc0844a0dd28, hash = 0xc0844908960, strtab = 0xc0844909650 "",
symtab = 0xc0844908c90, rela = 0xc0844909940, relasz = 1152,
relaent = 24, strsz = 748, syment = 24, init = 0, fini = 0,
soname = 0x0, rpath = 0x0, symbolic = 0, rel = 0x0, relsz = 0,
relent = 0, pltrel = 7, debug = 0, textrel = 0, jmprel = 13229649599936,
bind_now = 0, init_array = 0x0, fini_array = 0x0, init_arraysz = 0,
fini_arraysz = 0, runpath = 0x0, flags = 0, encoding = 0,
preinit_array = 0x0, preinit_arraysz = 0}}, relacount = 45,
relcount = 0, status = 5, phdrp = 0xc0844800040, phdrc = 10, obj_type = 2,
obj_flags = 2, buckets = 0xc0844908968, nbuckets = 97,
chains = 0xc0844908aec, nchains = 104, dynamic = 0x0, child_list = {
tqh_first = 0xc0ab8651740, tqh_last = 0xc0ab8651740}, grpsym_list = {
tqh_first = 0xc0aab280e40, tqh_last = 0xc0ad21a8bc0}, grpref_list = {
tqh_first = 0x0, tqh_last = 0xc0a85cff5c8}, refcount = 0, opencount = 1,
grprefcount = 0, load_object = 0xc0a85cff400, sod = {
sod_name = 13240289961776, sod_library = 0, sod_reserved = 0,
sod_major = 0, sod_minor = 0, sod_next = 0}, dev = 0, inode = 0,
tls_fsize = 0, tls_msize = 0, tls_align = 0, tls_static_data = 0x0,
tls_offset = 0, relro_addr = 13229650663352, relro_size = 2120,
grpsym_gen = 0, rpath = 0x0, runpath = 0x0, traced = 0}
$ ldd server
server:
Start End Type Open Ref GrpRef Name
0000004e8ca00000 0000004e8cc0f000 exe 1 0 0 server
00000051672ec000 00000051675db000 rlib 0 1 0 /usr/lib/libc.so.92.5
0000005183400000 0000005183400000 ld.so 0 1 0 /usr/libexec/ld.so
ld doesn't seem to be mentioned in errata64.html, so I guess there's
no relevant change for it.
The test program (as well as statethreds) is part of MeTA1 in case
someone can take a look at it.
OpenBSD 6.4/amd64 (release) with an error in ld (see below); it
works fine on previous OpenBSD versions. Do I have to set some
"special" cc/ld options to make this work? Or are patches to
statehreads required (there doesn't seem to be a port for it,
otherwise I would try that)?
#0 0x00000c0b0980db08 in _dl_bind (object=0xc0a85cff400, index=)
from /usr/libexec/ld.so
(gdb) where
#0 0x00000c0b0980db08 in _dl_bind (object=0xc0a85cff400, index=)
from /usr/libexec/ld.so
#1 0x00000c0b098080dd in _dl_bind_start ()
at /usr/src/libexec/ld.so/amd64/ldasm.S:108
#2 0x00000c08448058bc in st_accept (fd=0xc0a634981c0, addr=0xc0ae5a31dd0,
addrlen=0xc0ae5a31dcc, timeout=18446744073709551615)
at ../../mta/statethreads/io.c:258
#3 0x00000c0844802928 in handle_connections (arg=0x0)
at ../../../mta/statethreads/examples/server.c:880
#4 0x00000c0844803e4a in st_thread_create (start=0, arg=)
at ../../mta/statethreads/sched.c:329
#5 0x00000c0844801e38 in start_threads ()
at ../../../mta/statethreads/examples/server.c:855
#6 0x00000c0844800b17 in main (argc=6, argv=0x7f7ffffd4ec8)
at ../../../mta/statethreads/examples/server.c:266
(gdb) print *object
$2 = {obj_base = 13229648510976, load_name = 0xc0b0ee98d90 "./server",
load_dyn = 0xc0844a0dbc8, next = 0xc0a4aacb800, prev = 0x0,
load_base = 13229648510976, load_list = 0xc0a64e9c400, load_size = 2158592,
Dyn = {info = 0xc0a85cff440, u = {null = 0, needed = 1, pltrelsz = 1872,
pltgot = 0xc0844a0dd28, hash = 0xc0844908960, strtab = 0xc0844909650 "",
symtab = 0xc0844908c90, rela = 0xc0844909940, relasz = 1152,
relaent = 24, strsz = 748, syment = 24, init = 0, fini = 0,
soname = 0x0, rpath = 0x0, symbolic = 0, rel = 0x0, relsz = 0,
relent = 0, pltrel = 7, debug = 0, textrel = 0, jmprel = 13229649599936,
bind_now = 0, init_array = 0x0, fini_array = 0x0, init_arraysz = 0,
fini_arraysz = 0, runpath = 0x0, flags = 0, encoding = 0,
preinit_array = 0x0, preinit_arraysz = 0}}, relacount = 45,
relcount = 0, status = 5, phdrp = 0xc0844800040, phdrc = 10, obj_type = 2,
obj_flags = 2, buckets = 0xc0844908968, nbuckets = 97,
chains = 0xc0844908aec, nchains = 104, dynamic = 0x0, child_list = {
tqh_first = 0xc0ab8651740, tqh_last = 0xc0ab8651740}, grpsym_list = {
tqh_first = 0xc0aab280e40, tqh_last = 0xc0ad21a8bc0}, grpref_list = {
tqh_first = 0x0, tqh_last = 0xc0a85cff5c8}, refcount = 0, opencount = 1,
grprefcount = 0, load_object = 0xc0a85cff400, sod = {
sod_name = 13240289961776, sod_library = 0, sod_reserved = 0,
sod_major = 0, sod_minor = 0, sod_next = 0}, dev = 0, inode = 0,
tls_fsize = 0, tls_msize = 0, tls_align = 0, tls_static_data = 0x0,
tls_offset = 0, relro_addr = 13229650663352, relro_size = 2120,
grpsym_gen = 0, rpath = 0x0, runpath = 0x0, traced = 0}
$ ldd server
server:
Start End Type Open Ref GrpRef Name
0000004e8ca00000 0000004e8cc0f000 exe 1 0 0 server
00000051672ec000 00000051675db000 rlib 0 1 0 /usr/lib/libc.so.92.5
0000005183400000 0000005183400000 ld.so 0 1 0 /usr/libexec/ld.so
ld doesn't seem to be mentioned in errata64.html, so I guess there's
no relevant change for it.
The test program (as well as statethreds) is part of MeTA1 in case
someone can take a look at it.
Subscribe to:
Posts (Atom)