re: Latest mips/evbmips observations

On Thu, 1 May 2014, matthew green wrote:
> if you see specific GCC 4.8 regressions vs. 4.5, please file PRs
> about each issue, so we can at least investigate them from the
> compiler POV.
I'll try. Right now I just have informal observations based on what
I remember from the last time I booted a gcc45-built system. I don't
get to try often as I'm actively using the system (under gnewsense Linux)
as a graphical terminal to my other systems.
Since I have all gcc48-built stuff locally, I'll see about grabbing a
gcc45-built release from the snapshot builds and check with that. Hmm.
I should get another SD card so I can switch local installs as easily
as switching NFS roots.
Reorganizing for proper context...
> > > X server: the undefined symbol issues seem to have been resolved, but
> > > now the server complains that it can't load the "int10" module, saying
> you probably don't want "int10" on non-x86, IIRC?
I believe this was mentioned before. It's not that I want "int10", but
that's how it's built by default. As macallan noted, something like
this shouldn't be fatal on a system where it doesn't apply. Or perhaps
some conditionals could be used to require/include the module only on
platforms where it makes sense?
The above was observed on a gcc45-built system. It may still be there
on a gcc48-built system, but the undefined symbol error below is probably
masking it (never gets far enough to complain about the missing module).
> > Once again failing due to an undefined symbol. Side effect of gcc48?
>
> > (==) Using default built-in configuration (12 lines)
> > (EE) Failed to load /usr/X11R7/lib/modules/drivers/siliconmotion_drv.so:
> > /usr/X11R7/lib/modules/drivers/siliconmotion_drv.so: Undefined symbol
> > "exaOffscreenF
> > ree" (symnum = 101)
> > (EE) Failed to load module "siliconmotion" (loader failed, 7)
> > (EE) No drivers available.
ISTR that a long, long time ago, the X server failed on evbmips-mips64el
due to some other undefined symbol, so that's what my "Once again" phrase
was expressing. This is what I see on a gcc48-built system, not the
missing module complaint from a gcc45-built system.
> > 'etcupdate' seems to be ignoring the "-a" and "-l" options, requiring
> > 'etcupdate' mangles the invocation of 'postinstall' at the end, somehow
> that seems strange. i don't tend to use etcupdate (just postinstall),
> can you confirm they're GCC 4.8 specific?
Hmm. I suppose 'etcupdate' is really only useful following a version-
spanning update and 'postinstall' is sufficient for routine updates
within the same version.
As above, I'll grab a gcc45-built release from the snapshot build
hosts and confirm behavior differences.
--
|/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X
|\ / jdbaker[snail]mylinuxisp[flyspeck]com OpenBSD FreeBSD
| X No HTML/proprietary data in email. BSD just sits there and works!
|/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645