You are here

Update to the GNU gcc spec file experimental/SFEgcc-runpath.spec

Update: I put together a condensed set of notes for a distribution to make up a nice gcc configuration here:
Update: As of end of December 2011 the new setup for gcc described below has been released from experimental a long time ago - and no known bugs yet.
Unfortunatly the OS-Distro provided gcc-4 series compilers still do not follow this approach.
OpenCSW uses now uses the same good search method for and for all binaries compiled with theyr compiler.

Date: Fri, 23 Sep 2011 20:13:54 +0200
From: Thomas Wagner
Subject: Re: [SFE-devel] SFEgcc w/o hardcoded runpath,
overhaul include/*inc to conditionally add -R/usr/gnu/lib

[sorry for the long text, please take a coffee and read on]

Hi All,

things have settled a bit now, the experimental/SFEgcc-runpath.spec
does fine so far on a Solaris11 build 170. Other releases and
platforms are encouraged to test *now*. Remember to remove the
SFEgcc + SFEgccruntime before compiling the new version to avoid
runing into problems (e.g. have old gcc 4.5.3)

About experimental/SFEgcc-runpath.spec:
New package names added
The latest change was reorganizing the symbolik links to be
contained in the well known package names SFEgcc and SFEgccruntime.
This enables all customer packages compiled with earlier SFEgcc
to still find the runtime in /usr/gnu/lib/*
(Some day in the future I would like to retire the symlinks
in /usr/gnu/lib/* pointing to the runtime in /usr/gcc/4.6/lib.
But not now.
To be have permanent support for the idea of cross-version
runtime libs the private directory /usr/gcc/lib is now defined.
If you don't care much on the runtime version, your program
just can find a recent runtime there. A default and searched
first and preferred location for the runtime is /usr/gcc/4.6/lib/.

New is package SFEgcc-46 and SFEgccruntime-46 which contain
all the files in the somewhat private and well known directory
/usr/gcc/4.6/ and below.

You can think of future updates to SFEgcc, say version 4.7, and
this can be installed as well in parallel. Only the symbolic
links delivered by version 4.7 of SFEgcc and SFEgccruntime
would then point to files in the new directory /usr/gcc/4.7/ .
Old programs would then run the updated runtime libs 4.7.
(distro builders or personal repos:
A copy of future 4.7 spec file used as version 4.6 would
continue to deliver SFEgcc 4.6 files and the package with
the symlinks would be overwritten by subsequently published
4.7 version packages of the same name and this is installed
by default then) (or a smarter solution then that)

About the symlinks (locations are set at compile time)

You can now predefine inside the spec file where on the disk
the symlinks should go (runtime and the compiler).
The current SVN version of the spec does place symlinks into
and as well into
This list can be extended, but be aware that all those symlinks
are put into one single package name SFEgcc and SFEgccruntime
respectively. No separate packages for the different locations
from listed above (for now).

If you want to experiment with additional locations, run the
whole build process once, then right after that make your
new locations to the spec file and do another install/packetize
cycle like described below.
call pkgbuild to do another install to /var/tmp/pkgbuid*/* :

pkgbuild --short-circuit -bi experimental/SFEgcc-runpath.spec

check results with find /var/tmp/pkgbuild*/SFEgcc* -type l

next do a fresh publishing to the repo:
pkgbuild --short-circuit -bb experimental/SFEgcc-runpath.spec

use the package:
pfexec pkg install SFEgcc
test results

remove packages again, note you have 4 packages now
pfexec pkg uninstall SFEgcc SFEgcc-46 SFEgccruntime SFEgccruntime-46

Check contents and dependencies by reading the packages' contents
pkg contents -r -m SFEgccruntime | less

Linker to be used

I changed ld-wrapper to /usr/bin/ld, just to be sure if a user doesn't
run with CBE installed, the Solaris linker is still be found.
/opt/*bld/bin/ld-wrapper inserts a few switches which might make
sense on Solaris. It is possile that out include/*inc files already
contain similar stuff, to we only loose switches in rare special
situations. This is not yet verified. Volunteers?

md_exec_prefix gcc specs

At the moment this points not longer to /usr/ccs (/bin). Instead I placed
/usr/gcc there but I'm not totally sure which setting is better with
the recent changes we've seen in Solaris 11 EA where /usr/ccs/bin is now
a complete set of /usr/bin due to being just a symlink now. There is no
longer a well selected subset (around 45) of Solaris related tools needed for
compiling, instead the whole >2000 binaries known as /usr/bin/ are
now reached via /usr/ccs/bin/ symlink.

md_exec_prefix is a place where gcc searches refardless of $PATH
for some system tools like "ld".
Try this:
gcc -print-prog-name=ld

Maybe you can just ignore this and let others care :)

note on finding runtime libs

again, the experimental/SFEgcc-runpath.spec already contained
a patch so that the gcc runtime is always found properly even
if no and is anywhere in the
linker's standard search locations (/lib:/usr/lib) or optional
directories (/usr/gnu/lib:/usr/sfw/lib and the like).

Binaries compiled with this special gcc do find theyr runtime
due to the extra code in the macro shown with

/usr/gcc/4.6/bin/gcc -dumpspecs | ggrep -A2 link_libgcc
%{m64:-R /usr/gcc/4.6/lib/amd64:/usr/gcc/lib/amd64 %D}%{!m64:-R /usr/gcc/4.6/lib:/usr/gcc/lib %D}

I want to say thanks to the pkgsrc people or whoever found
out about this setting. It just solved the problem to find
the runtime always where *we* want it to be found. It works
so elegantly. I just had to find the right macro syntax to
switch between 32/64 bit.

A binary compiled with this gcc should be robust against a
distro provided runtime lib of the same name in many cases.

Still to be verified is, if we need to specify an extra
-R/usr/gcc/lib in out spec files in a special case. This
is if there is another directory containing (accidentially)
another copy of the gcc runtime libraries.
In the example this is /eleswhere/lib containing as well
a gcc runtime lib. The spec file contains an added
-R /elsewhere/lib which *might* leads to searching for the
runtime libs in this path: /elsewhere/lib:/usr/gcc/4.6/lib:/usr/gcc/lib
I found no solution to really force the link_libgcc
location be *ever* the very first one in search order.
The Solution for this rare cases is:
The *FLAGS setting would then be -R/usr/gcc/lib:/elsewhere/lib
to visit the gcc runtime we want first, then the rest.

If we are in luck, other distros might just adopt this setting
of link_libgcc and we can live in a trouble free world with
*not a single* gcc runtime in /lib:/usr/lib - and still have
each binary find what it expects, its very own runtime it
was compiled against, or a more recent one which is still
under SFE control in e.g. /usr/gcc/lib.
This should end the "mix the runtime and get in troubles"
era with gcc.

Well, I'll end for now with this news. In any case please
ask if you have questions or want to express optinions,
please do. But please, try a little serious research before
expressing objections.
It was a lot work for research and testing put into this
new settings, and from my view this looks very well.
If not, then this maybe means I should talk more about
the reasons behind something looking odd to you.


Add new comment

Filtered HTML

  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
By submitting this form, you accept the Mollom privacy policy.

User login

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer