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
