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