Switch from .So to .pico for object files compiled with -fpic
ClosedPublic
Actions

Authored by marcel on Sep 16 2016, 8:26 PM.

Details

Reviewers

sjg
marcel
bdrewery

Commits

rS306300: When MAKEOBJDIRPREFIX points to a case-insensitive file system, the
rS306297: When MAKEOBJDIRPREFIX points to a case-insensitive file system, the

Summary

The .So extension clashes with the .so extension used for shared libraries on file systems that are case-insensitive. Change to .pico instead. This matches what NetBSD uses. A full buildworld and buildkernel (default options) succeeds over NFS onto a case-sensitive file system.

Diff Detail

Repository

rS FreeBSD src repository - subversion

Lint

Lint Skipped

Unit

Tests Skipped

Build Status

Buildable 5172
Build 5294: CI src build	Jenkins

Event Timeline

marcel updated this revision to Diff 20393.Sep 16 2016, 8:26 PM

marcel retitled this revision from to Which from .So to .pico for object files compiled with -fpic.

marcel updated this object.

marcel edited the test plan for this revision. (Show Details)

marcel added reviewers: sjg, bdrewery.

marcel set the repository for this revision to rS FreeBSD src repository - subversion.

Herald added subscribers: emaste, imp. · View Herald TranscriptSep 16 2016, 8:26 PM

In future please upload with context, as described in https://wiki.freebsd.org/action/show/Phabricator.
Could we incorporate a description of the special extensions (.po / .pico) into bsd.README as NetBSD has?

gnu/lib/libgcc/Makefile
261	Should this be `${T}_OBJS_PIC` and similar questions below?

Interesting, it looks like NetBSD used to use .so for PIC objects which seems even more error-prone.

marcel retitled this revision from Which from .So to .pico for object files compiled with -fpic to Switch from .So to .pico for object files compiled with -fpic.Sep 16 2016, 9:23 PM

marcel updated this object.

I can document .po, .pico, etc but prefer to do so in a separate commit. The need for such documentation isn't created by this change, but has always been there. I'll do a followup commit (plus email to @current, etc) after this change is approved.

gnu/lib/libgcc/Makefile
261	Maybe; possibly. One can argue either way, which probably means that it should be a separate commit if we want to go that route. To me it feels a little unnecessary, but can do it if you (or others) feel strongly about it.