On Fri, Nov 08, 2024 at 07:12:54PM +0000, Stuart Henderson wrote: > On 2024/11/08 18:18, Jeremie Courreges-Anglas wrote: > > > - Cores don't seem to work. > > > Reading symbols from obj/bc... > > > [New process 310362] > > > > > > warning: Unexpected size of section `.reg2/310362' in core file. > > > > > > warning: Corrupted shared library list: 0x7e9ac000 != 0x0 > > > Core was generated by `bc'. > > > Program terminated with signal SIGQUIT, Quit. > > > > > > warning: Unexpected size of section `.reg2/310362' in core file. > > > #0 0x0c0fe087 in ?? () > > > > Ah, that's not nice. But is that a regression? If it is, I'll pop an > > i386 VM. > > Oh, good question. It's different but not really a regression. > So no worries about punting that for now.
Cool. That matches my dim memories, I think I've already read a similar report in the past. I might try to tackle that if no one beats me to it. My secret plan is to be able to commit this update during the hackathon if all architectures look clean, and restore the arm native bits when I get my hands back on my cubox machine. Unless someone else wants to beat me to that too. ;) > : i386.p; egdb bc bc.core > GNU gdb (GDB) 9.2 > Copyright (C) 2020 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > Type "show copying" and "show warranty" for details. > This GDB was configured as "i386-unknown-openbsd7.6". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>. > Find the GDB manual and other documentation resources online at: > <http://www.gnu.org/software/gdb/documentation/>. > > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from bc... > (No debugging symbols found in bc) > BFD: warning: /home/sthen/bc.core is truncated: expected core file size >= > 4477866, found: 1497480 > > warning: Couldn't find general-purpose registers in core file. > > warning: Couldn't find general-purpose registers in core file. > #0 <unavailable> in ?? () > > > > + --with-libgmp-type=shared \ > > ha! > > > -MAKE_FLAGS= V=1 LDFLAGS="${LDFLAGS}" > > +MAKE_FLAGS= V=1 LDFLAGS="-L${LOCALBASE}/lib ${LDFLAGS}" > > I know it was already there, but ports doesn't normally feed in > LDFLAGS from the environment/vars like it does for CFLAGS etc. > So I'd prefer to make it explicit i.e. just LDFLAGS="-L${LOCALBASE}/lib". Don't we need to have LDFLAGS respected for DEBUG=-g / DEBUG_PACKAGES to be useful? You're not the first one to express dislike for such tweaks, yet I find it puzzling. There's probably a lot of ports that don't respect LDFLAGS, but it comes in handy when we need to apply workarounds / tweaks / whatever. > (Surprised it didn't need to go to CONFIGURE_ENV but now I see > it's running configure a bunch of times in 'make build' too, > sounds about right for gnu software!). sigh :) -- jca
