On Sun, Apr 14, 2019 at 06:42:56PM -0700, Mike Larkin wrote: > On Sun, Apr 14, 2019 at 02:34:05PM -0600, Theo de Raadt wrote: > > Christian Weisgerber <na...@mips.inka.de> wrote: > > > > > By my count there remain five ports than can ONLY be built with > > > base-gcc: > > > > > > audio/festival/core > > > devel/ti-msp430gcc > > > editors/TeXmacs > > > multimedia/avidemux > > > sysutils/firmware/vmm > > > > > > These ports are living on borrowed time. base-gcc WILL go away, > > > and possibly sooner than you think, so they will need to move to > > > clang or ports-gcc or they will die. > > > > Yep. All hands on deck... > > > > I tried for most of the afternoon to fix vmm-firmware. I made a little > progress but now I'm stumped. > > Using ports-gcc 4.9.4, some of the 16 bit real mode binaries get built > as x86_64, which results in a bunch of problems linking. I fiddled with > the makefile for a while and then based on a comment in the ports Makefile > that FreeBSD is building this with gcc8, I upgraded to ports gcc 8.3. > > That got a little further (things get compiled in the right mode now) but > it still fails to link the 16 bit part of the ROM. The way this appears > to work is that it tries to fit things together really tightly using a > python script that analyses all the .o files and produces a link script that > is used to link the rom. The problem seems to be in that python scrip/link > script; it emits directives that make sections overlap with each other. I > enabled some of the commented out debugging and from what I can tell, the > part of the .py script that is placing the "fixed sections" seems to be > doing the right thing, and later phases don't know about those and end > up placing things on top of each other. > > Since the .py script gets its inputs by reading the symbol tables of the > various .o files, it's clearly the case that the compiler is outputting > something different. I just couldn't find what it was and realized that > I was in over my head. Maybe with the above information, someone can > make further progress. > > -ml > >
FWIW sthen says gcc 8.3 works for him, so I'll drop this. -ml
