pkgbuild

Hi Milan,

On Thu, 2011-10-06 at 21:28 +0200, Milan Jurik wrote:
> I know there was discussion about it already without conclusion. OI
> moved to hierarchical IPS package names. S11 seems to be released soon.
> I think it is time to use IPS_Package_Name in spec files. For myself I
> start to add them to specs I am updating.
> 
> I am fully aware it can lead to package names conflicts. But SFE was
> always something on top of the system. In worst case public SFE IPS
> repos will republish some empty packages if there will be conflict.

I think this is a sensible move.

Might I suggest that you also add a Group name when you add
IPS_package_name? That way, packages will be easier to find in the
graphical Package Manager.

The file defining IPS package names used by the OpenIndiana SFE
repository can be found here:

http://hg.openindiana.org/projects/sfe/oi-sfe-tools/file/565e0daa124c/packages.xmlt

It would be nice if IPS package names defined in specs and those defined
in that file could be kept consistent.

Best regards,

Alex

Hi Alex,

Alex Viskovatoff píše v čt 06. 10. 2011 v 15:54 -0400:
> Hi Milan,
> 
> On Thu, 2011-10-06 at 21:28 +0200, Milan Jurik wrote:
> > I know there was discussion about it already without conclusion. OI
> > moved to hierarchical IPS package names. S11 seems to be released soon.
> > I think it is time to use IPS_Package_Name in spec files. For myself I
> > start to add them to specs I am updating.
> > 
> > I am fully aware it can lead to package names conflicts. But SFE was
> > always something on top of the system. In worst case public SFE IPS
> > repos will republish some empty packages if there will be conflict.
> 
> I think this is a sensible move.
> 
> Might I suggest that you also add a Group name when you add
> IPS_package_name? That way, packages will be easier to find in the
> graphical Package Manager.
> 

you are trying to overload my brain :-)

> The file defining IPS package names used by the OpenIndiana SFE
> repository can be found here:
> 
> http://hg.openindiana.org/projects/sfe/oi-sfe-tools/file/565e0daa124c/packages.xmlt
> 
> It would be nice if IPS package names defined in specs and those defined
> in that file could be kept consistent.
> 

I am trying, I am trying :-)

> Best regards,
> 
> Alex
> 

Best regards,

Milan

[I found a typo "gcc" instead "gnu", see below the 
correct word "gnu" - marked with ***, please discard 
the previous mail]

Hi Milan,

thanks for having a look at this experimental version :)
I'll try to narrow down what the SFE default should be.

I came to the view that we (SFE) have one new feature
ready for use and only one important question left to 
answer and a recommendation.


Feature, long term, ready for use:

    these directories does SFE want as location for 
    libgcc_s.so.1 and libstdc++.so.6 :
      /usr/gcc/<major.minor>/lib/

    and if not found in the directory above, then a 
    potentially upgraded runtime version is in place
    and available as symbolic links here:
      /usr/gcc/lib/

    the runtime for *our* packages compiled with this new
    gcc package does not longer need to live in a public
    directory. For old binaries, see symlinks right below.

Question:
    for how long does SFE want to maintain "compatibility"
    symbolic links for gcc runtime e.g. in 
       /usr/gnu/lib/libgcc_s.so
           -> /usr/gcc/<major.minor>/lib/libgcc_s.so

    We could tag the gcc runtime location /usr/gnu/lib as
                                               *** 
    deprecated but still provide the gcc-runtime-libs for
    4.5.x and 4.6.x, and for e.g. gcc 4.7 stop delivering
    those symlinks.

    Who is using runtime libraries in old locations like
    /usr/gnu/lib/ (or /usr/lib/) ? Those should be only
    SFE packages compiled with old gcc without the new 
    configuration.
    Workaround: Recompile the packages, or make symbolic
    links locally in /usr/gnu/lib or run the binaries 
    with LD_LIBRARY_PATH pointing to e.g. the new permament
    location /usr/gcc/lib. All this hits users only at the
    thime when we stop providing symlinks to the runtime 
    in /usr/gnu/lib.


Providing good defaults.

    For SFE I think we could keep the symbolic links for the
    compilers in /usr/gnu/bin for a while longer. The gcc-
    runtime-libs in /usr/gnu/lib sould be retired earlier, as
    only not yet recompiled packages or binaries compiled on 
    other gcc configurations do need them.

    I hope that *no* distribution gets into the idea to
    provide symbolic links /usr/gnu/bin/gcc and /usr/gnu/bin/g++ !


Recommendations.

    spec files could use 
       CC=/usr/gnu/bin/gcc 
    or 
       CC=gcc
       PATH=/usr/gcc/bin:$PATH

       to be sure to use a SFE provided gcc compiler binary.
    Once the majority of users has the new gcc packages, then
    spec files can start using CC=/usr/gnu/bin/gcc similar
    to what we do with studio compilers.

    BuildRequires: SFEgcc           (preferred)
    Requires: SFEgcc-runtime
      or
    BuildRequires: SFEgcc-46        (if code needs 4.6.x)
    Requires: SFEgcc-runtime-46
      or
    BuildRequires: SFEgcc-45        (if code needs 4.5.x)
    Requires: SFEgcc-runtime-45

Warning:

    Using CC=gcc might lead to different results on different
    distros, as you can't be sure to not stumble over e.g.
    S11 provided gcc 4.5.x or gcc 3.4.3 as /usr/bin/gcc 
    (depending on PATH *and* distro release).
    The spec file then needs logic to depend on the correct
    runtime packages. 


All the above is SFE centric and tries to stay safely away 
from what the distros provide.

A distro may tweak the spec file and add more symbolic links
to the compiler binaries, but this should always be done in
a way that doesn't break SFE spec files. In particular the
spec files should not rely on stuff the distro has added.
This is only to please the users outside of the SFE use 
and make it little bit more like a Linux (or something).


Regards,
Thomas


On Tue, Sep 27, 2011 at 09:56:15PM +0200, Milan Jurik wrote:
> Hi Thomas,
> 
> introduction of /usr/gcc/lib is good solution. Thank you for making it.
> And as always, we can backout it if it will be necessary ;-)
> 
> But, please, clean up SFEgcc-runpath.spec before you will promote it to
> SFEgcc because it is unmaintainable to have so many build options.
> 
> Best regards,
> 
> Milan
> 
> Thomas Wagner píše v Út 27. 09. 2011 v 17:33 +0200:
> > Hi all,
> > 
> > if you have time for a review, I would ask you to give a 
> > short or long feedback until end of the week. 
> > 
> > I plan to make the changes into the regular SFEgcc 
> > if there are no stoppers found.
> > I'll make a copy for 4.5.3 version at the same time.
> > 
> > On the other hand, the changes are compatible with what
> > we have now in SFEgcc, so only later on if we start 
> > removing /usr/gnu/lib/<gcc-runtimelibs> the programs
> > compiled with older gcc might need a simple recompile/
> > packaging to use the new technique to always find the 
> > runtime.
> > 
> > In short, the main change is that we can get rid of
> > /usr/gnu/lib/<gcc-runtimelibs> and /usr/lib/<gcc-runtimelibs>
> > completely and stay safe with our SFE packages, regardless 
> > what weird ways gcc from each distro goes.
> > 
> > In parallel I'll ask Rainer Orth if he has news from the
> > gcc side for a long-term solution for finding the runtime libs.
> > 
> > Thanks much
> > Thomas
> > 
> > On Fri, Sep 23, 2011 at 08:13:54PM +0200, Thomas Wagner wrote:
> > > [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/<lib|bin> 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 
> > >    /usr/gcc/<lib|bin> 
> > > and as well into
> > >    /usr/gnu/<lib|bin>. 
> > > 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
> > > entirely:
> > >  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 libgcc_s.so.1 and libstdc++.so.6 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
> > > *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.
> > > 
> > > Regards,
> > > Thomas
> > > 
> > > 
> > > On Wed, Sep 14, 2011 at 12:14:57AM +0200, Thomas Wagner wrote:
> > > > Hi All,
> > > > 
> > > > small update after a little vacation.
> > > > 
> > > > I have now an experimental SFEgcc.spec and small patches to 
> > > > get the solaris configs adjusted.
> > > > 
> > > > What in the experimental spec file works now is, that a gcc or
> > > > g++ compiled binary now really finds its libgcc_s.so.1 and
> > > > libstdc++.so.6 on its own, without having to specify any
> > > > -R/path/to/lib/lib<gcc|stdc++>. 
> > > > This enables a "plain" gcc or g++ run without and switches
> > > > and still find the runtime even if it is stored in a 
> > > > non-default place to be out of reach of other software
> > > > which should not find is.
> > > > This spec make the gcc runtime libs be searched in 
> > > > /usr/gcc/4.6/lib and /usr/gcc/lib (new, thought as a new
> > > > default place for them).
> > > > 
> > > > A separate change is, that there is no hardcoded -R /usr/gnu/lib 
> > > > any more, this enables us to freely specify to include this
> > > > formerly ever-hardcoded /usr/gnu/lib path for searching 
> > > > all sorts of librares or leave it out completely.
> > > > Andditionally we get back more choice in specifing in which 
> > > > odering the "***/lib" directores are searched.
> > > > (e.g. /usr/lib:/usr/gnu/lib to find Solaris native libs first,
> > > > or think of other combinations. *) small exception see below )
> > > > 
> > > > I have one more experiment to do, this is testing if we can
> > > > re-establish a small fraction of the old gcc-03*diff patch,
> > > > but now with hardcoding /usr/gcc/4.6/lib:/usr/gcc/lib into
> > > > the binaries to search for the runtime libs. This would still
> > > > avoids having all-purpose /usr/gnu/lib even if we don't want
> > > > the other libs from there. And more imporant, we can really
> > > > make sure that other libgcc_s.so.1 and libstdc++.so.6 do 
> > > > never slip in and get found before our well-known-tested-good
> > > > own SFEgccruntime libs.
> > > > 
> > > > 
> > > > I'll try to make the experimental SFEgcc with the new patches
> > > > available until end of this week (Friday or Saturday).
> > > > If someone is impatient, drop me a mail and I'll quickly make
> > > > a tarball of the files for you.
> > > > I want to compile a few representative SFE specs and if this
> > > > doen't present any problems, we can discuss if this is the
> > > > way for SFE to go in gcc-4.x.x settings.
> > > > 
> > > > Regards,
> > > > Thomas
> > > > 
> > > > 
> > > > *) exception is currently, that gcc doesn't allow to place
> > > > the runtime libs directory in any case as the *first* directory
> > > > to include. I'll see if a patch like the old gcc-03-*diff
> > > > can force the gcc runtime libs directory to be search always
> > > > first, regardless what the user puts in his -R/path/to/lib.
> > > > Today the runtime libs directory might be prepended by the
> > > > path from -R, e.g. /path/to/lib:/usr/gcc/4.6/lib:/lib/usr/lib
> > > > This is as long the system is not pulluted by other libgcc_s.so.1
> > > > and libstdc++.so.6 library files
> > > > 
> > > > On Fri, Sep 02, 2011 at 10:59:49PM +0200, Thomas Wagner wrote:
> > > > > Just a quick question, what is what we really want to achieve?
> > > > > 
> > > > > Is this having a gcc compiled binary just find the gcc own libraries?
> > > > > Nothing else?
> > > > > 
> > > > > In this case we could save all the side effects with a hard
> > > > >  -R/usr/gnu/lib  (and others)
> > > > > applied to all sorts of binaries/libraries who not necessarily need it.
> > > > > 
> > > > > pkgsrv does solve this different then us, as it seems. 
> > > > > If we follow, this would be to add -R/usr/gnu/lib 
> > > > > *only* to libgcc_s.so and libstdc++.so (gcc libs)
> > > > > 
> > > > > pkgsrc uses a patch which makes gcc output this:
> > > > > (pkgsrv's version of) GCC 3.4.6 reports via   
> > > > > 
> > > > > gcc -dumpspecs | ggrep -A2 link_libgcc
> > > > >  *link_libgcc:
> > > > >  %D -R /usr/pkgsrc/20101105/gcc34/lib
> > > > > 
> > > > > A patch like this is used by pkgsrc:
> > > > > http://mail-index.netbsd.org/pkgsrc-bugs/2011/08/18/msg043988.html
> > > > > or
> > > > > http://cvsweb.se.netbsd.org/cgi-bin/bsdweb.cgi/pkgsrc/lang/gcc34/patches/patch-cc?rev=1.1;content-type=text%2Fx-cvsweb-markup
> > > > > 
> > > > > 
> > > > > all our gcc variants (3.x.x, all sorts 4.x.x) do print only 
> > > > > *link_libgcc:
> > > > > %D
> > > > > 
> > > > > We currently force not only the gcc libs to have this runpath,
> > > > > we force all binaries/libs to use this runpath, kind of using
> > > > > nuclear bomb to kill a beatle or a bug. :-) :-)
> > > > > 
> > > > > If I find time, I'll replay my testbed for the topic and see
> > > > > if the svn-current gcc-03-gnulib.diff (not forcing -R/usr/gnu/lib...)
> > > > > and another patch worked after the pkgsrc example does give us
> > > > > a gcc which compiles binaries and just finds it's own libraries,
> > > > > but not forces the old long runpath into every binary/library.
> > > > > 
> > > > > Regards,
> > > > > Thomas
> > > > > 
> > > > > 
> > > > > On Thu, Sep 01, 2011 at 04:26:18PM +0200, Thomas Wagner wrote:
> > > > > > 
> > > > > > Hi all,
> > > > > > 
> > > > > > we had a change to SFEgcc recently where patch gcc-03-gnulib.diff
> > > > > > in the old revision just replayed what the original gcc 3.x.x from
> > > > > > Sun/Oracle did, this was hardcoding the library runpath to be
> > > > > > /lib:/usr/lib:/usr/gnu/lib and so on. I think this is not ideal
> > > > > > to hardcode the runpath just for a few benefits of not having 
> > > > > > to specify runpaths when compiling/linking software.
> > > > > > 
> > > > > > GCC according to theyr website says it explicitly does not add
> > > > > > any runpath and more let the full choice up to the user and what
> > > > > > he thinks the runpath should be. I believe this comes from the
> > > > > > cross-compiling world gcc supports. It might help as well in
> > > > > > difficult situations where we have one library name for more
> > > > > > then one version/variant of a lib on one system.
> > > > > > 
> > > > > > <history>
> > > > > > A quick look on the history: The patch gcc-03-gnulib.diff was
> > > > > > changed to not longer hardcode the runpath. Reason was that 
> > > > > > we've been unable to place /usr/g++/lib at the very beginning 
> > > > > > of the runpath which was needed for QT (gcc/g++) for some 
> > > > > > programs. 
> > > > > > So the change to the compiler was done and tested and it worked.
> > > > > > Later on it revealed that the runtime lib searchpath wasn't
> > > > > > wrong because of gcc, it was a bad default in the qmake macros
> > > > > > of QT on solaris where the switch -W,-R, was set ( I think 
> > > > > > this is from GNU-LD versus Sun-LD). A change to that macro 
> > > > > > changed this to just "-R" and the root cause for the wrong
> > > > > > runpath was removed.
> > > > > > 
> > > > > > Now we still have the gcc being sane, clean, without the runpath
> > > > > > hardcoded. I personally would like to leave it in this state,
> > > > > > but there is a little downside with this. Now our spec files
> > > > > > need to specify -R/usr/gnu/lib themselves to find the gcc
> > > > > > compiler runtime, because gcc doesn't do it for us hardcoded
> > > > > > any more.
> > > > > > </histroy>
> > > > > > 
> > > > > > 
> > > > > > I had a talk with herzen on IRC and it looks like we could keep
> > > > > > the brave gcc without hardcoded runpath and change one or two
> > > > > > of our include files according to this meta code:
> > > > > > 
> > > > > > maintainer sets in his spec file:
> > > > > > %include Solaris.inc
> > > > > > %define cc_is_gcc 1
> > > > > > %include base.inc
> > > > > > (optionally: %include arch64.inc)
> > > > > > 
> > > > > > #we could change those of the include files responsible for setting
> > > > > > #LDFLAGS and CFLAGS
> > > > > > %if cc_is_gcc
> > > > > >   set extra %{_ldflags} to insert -R/usr/gnu/lib -L/usr/gnu/lib
> > > > > >   set extra %{gcc_optflags} to insert -R/usr/gnu/lib -L/usr/gnu/lib
> > > > > > %endif
> > > > > > 
> > > > > > This way, through the include files, we would not have a lot changes
> > > > > > to existing spec files but still get the /usr/gnu/lib into the runpath.
> > > > > > Some spec files would need to now set %define cc_is_gcc 1 and
> > > > > > re-include the base.inc/other_inc_files.
> > > > > > (Note, gcc4 programs need some gcc runtime libs, and those live in
> > > > > > /usr/gnu/lib, e.g. libgcc*, libstc++* )
> > > > > > 
> > > > > > In case we have a complicated situation with the order of the libs
> > > > > > searchpath/runpath, then a gcc free of any hardcoded runpath might
> > > > > > help to get the libs searched in the order the maintainer needs
> > > > > > them. In this case, the user can re-define the CFLAGS/LDFLAGS to 
> > > > > > have all the flags locally and not using the include files presets.
> > > > > > 
> > > > > > 
> > > > > > The above draws the idea, comments welcome. We could make an example
> > > > > > implementation to see if it works.
> > > > > > 
> > > > > > Regards,
> > > > > > Thomas
> > > > > > 
> > > > > > PS: some might be in favour of replicating in SFEgcc what gcc 3.x.x 
> > > > > > does (hardcode runpath), some might want SFEgcc go back to the same 
> > > > > > hardcoded runpath, some don't. As well there are thoughs if Studio 
> > > > > > compilers do hardcode a runpath as well, this is to be tested with 
> > > > > > simple helloworld.c and see if that is really the case and which 
> > > > > > paths are in runpath with Studio. dump -Lv helloworld  or a call to
> > > > > > elfdump -d helloworld  shows the runpath.
> > > > > > 
> > > > > > PS2: those who not have recompiled SFEgcc after around SVN version
> > > > > > from revision r3713 / 2011-08-16 10:37:16 +0200  do still place
> > > > > > hardcoded runpaths into the resulting packages.
> > > > > > 
> > > > > >  ~/spec-files-extra svn log patches/gcc-03-gnulib.diff 
> > > > > > ------------------------------------------------------------------------
> > > > > > r3713 | tom68 | 2011-08-16 10:37:16 +0200 (Tue, 16 Aug 2011) | 2 lines
> > > > > > 
> > > > > > SFEgcc.spec, gcc-03-gnulib.diff: rework RUNPATH to give user all choices
> > > > > > 
> > > > > > ------------------------------------------------------------------------
> > > > > > r3246 | jurikm | 2011-03-04 23:16:03 +0100 (Fri, 04 Mar 2011) | 3 lines
> > > > > > 
> > > > > > SFEgcc.spec: RUNPATH enforced to contain /usr/gnu/lib, libs symlinked to /usr/gnu/lib
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > -- 
> > > > > > Thomas Wagner
> > > > > > +49-171-6135989  http://www.wagner-net.net
> > > > > > 
> > > > > > ------------------------------------------------------------------------------
> > > > > > Special Offer -- Download ArcSight Logger for FREE!
> > > > > > Finally, a world-class log management solution at an even better 
> > > > > > price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> > > > > > download Logger. Secure your free ArcSight Logger TODAY!
> > > > > > http://p.sf.net/sfu/arcsisghtdev2dev
> > > > > > _________________________________________________________________
> > > > > > SFE-devel mailing list - Pkgbuild-sfe-devel@...
> > > > > > http://pkgbuild.wiki.sourceforge.net/SFE
> > > > > > https://lists.sourceforge.net/lists/listinfo/pkgbuild-sfe-devel
> > > > > > 
> > > > > 
> > > > > -- 
> > > > > -- 
> > > > > Thomas Wagner
> > > > > 
> > > > > ------------------------------------------------------------------------
> > > > > Service rund um UNIX(TM),     Wagner Network Services, Thomas Wagner
> > > > > Solaris(TM), Linux(TM)        Eschenweg 21, 89174 Altheim, Germany
> > > > > Novell(TM), WindowsNT(TM)     TEL: +49-731-9807799, FAX: +49-731-9807711
> > > > > Telekommunikation, LAN,       MOBILE/CELL: +49-171-6135989
> > > > > Internet-Service, Elektronik  EMAIL: wagner@...
> > > > > 
> > > > > ------------------------------------------------------------------------------
> > > > > Special Offer -- Download ArcSight Logger for FREE!
> > > > > Finally, a world-class log management solution at an even better 
> > > > > price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> > > > > download Logger. Secure your free ArcSight Logger TODAY!
> > > > > http://p.sf.net/sfu/arcsisghtdev2dev
> > > > > _________________________________________________________________
> > > > > SFE-devel mailing list - Pkgbuild-sfe-devel@...
> > > > > http://pkgbuild.wiki.sourceforge.net/SFE
> > > > > https://lists.sourceforge.net/lists/listinfo/pkgbuild-sfe-devel
> > > > > 
> > > > 
> > > > -- 
> > > > -- 
> > > > Thomas Wagner
> > > > 
> > > > ------------------------------------------------------------------------
> > > > Service rund um UNIX(TM),     Wagner Network Services, Thomas Wagner
> > > > Solaris(TM), Linux(TM)        Eschenweg 21, 89174 Altheim, Germany
> > > > Novell(TM), WindowsNT(TM)     TEL: +49-731-9807799, FAX: +49-731-9807711
> > > > Telekommunikation, LAN,       MOBILE/CELL: +49-171-6135989
> > > > Internet-Service, Elektronik  EMAIL: wagner@...
> > > > 
> > > > ------------------------------------------------------------------------------
> > > > BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
> > > > Learn about the latest advances in developing for the 
> > > > BlackBerry&reg; mobile platform with sessions, labs & more.
> > > > See new tools and technologies. Register for BlackBerry&reg; DevCon today!
> > > > http://p.sf.net/sfu/rim-devcon-copy1 
> > > > _________________________________________________________________
> > > > SFE-devel mailing list - Pkgbuild-sfe-devel@...
> > > > http://pkgbuild.wiki.sourceforge.net/SFE
> > > > https://lists.sourceforge.net/lists/listinfo/pkgbuild-sfe-devel
> > > > 
> > > 
> > > -- 
> > > -- 
> > > Thomas Wagner
> > > 
> > > ------------------------------------------------------------------------
> > > Service rund um UNIX(TM),     Wagner Network Services, Thomas Wagner
> > > Solaris(TM), Linux(TM)        Eschenweg 21, 89174 Altheim, Germany
> > > Novell(TM), WindowsNT(TM)     TEL: +49-731-9807799, FAX: +49-731-9807711
> > > Telekommunikation, LAN,       MOBILE/CELL: +49-171-6135989
> > > Internet-Service, Elektronik  EMAIL: wagner@...
> > > 
> > > ------------------------------------------------------------------------------
> > > All of the data generated in your IT infrastructure is seriously valuable.
> > > Why? It contains a definitive record of application performance, security
> > > threats, fraudulent activity, and more. Splunk takes this data and makes
> > > sense of it. IT sense. And common sense.
> > > http://p.sf.net/sfu/splunk-d2dcopy2
> > > _________________________________________________________________
> > > SFE-devel mailing list - Pkgbuild-sfe-devel@...
> > > http://pkgbuild.wiki.sourceforge.net/SFE
> > > https://lists.sourceforge.net/lists/listinfo/pkgbuild-sfe-devel
> > > 
> > 
> > -- 
> 
> 
> 
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _________________________________________________________________
> SFE-devel mailing list - Pkgbuild-sfe-devel@...
> http://pkgbuild.wiki.sourceforge.net/SFE
> https://lists.sourceforge.net/lists/listinfo/pkgbuild-sfe-devel
> 

-- 
-- 
Thomas Wagner

------------------------------------------------------------------------
Service rund um UNIX(TM),     Wagner Network Services, Thomas Wagner
Solaris(TM), Linux(TM)        Eschenweg 21, 89174 Altheim, Germany
Novell(TM), WindowsNT(TM)     TEL: +49-731-9807799, FAX: +49-731-9807711
Telekommunikation, LAN,       MOBILE/CELL: +49-171-6135989
Internet-Service, Elektronik  EMAIL: wagner@...

Hi Thomas,

On Sat, 2011-10-01 at 22:35 +0200, Thomas Wagner wrote:
> Recommendations.
> 
>     spec files could use 
>        CC=/usr/gnu/bin/gcc 
>     or 
>        CC=gcc
>        PATH=/usr/gcc/bin:$PATH
> 
>        to be sure to use a SFE provided gcc compiler binary.
>     Once the majority of users has the new gcc packages, then
>     spec files can start using CC=/usr/gnu/bin/gcc similar
>     to what we do with studio compilers.

I am opposed to hardcoding the path of gcc. We did away with that when
specs started to move away from using gcc 3.4.3 and to use SFEgcc
instead. Since SFEgcc places symlinks to itself in /usr/gnu/bin
and /usr/gnu/bin is in front of /usr/bin in CBE's PATH; that lets SFE's
gcc get selected. I think hardcoding the path, as some specs do with
CC=/usr/sfw/bin/gcc, would be a step backward. That should only be done
when it is know that a given gcc cannot build something, for cases, for
example, when something builds with gcc 3.4.3 but not gcc 4.6.1.

> 
>     BuildRequires: SFEgcc           (preferred)
>     Requires: SFEgcc-runtime
>       or
>     BuildRequires: SFEgcc-46        (if code needs 4.6.x)
>     Requires: SFEgcc-runtime-46
>       or
>     BuildRequires: SFEgcc-45        (if code needs 4.5.x)
>     Requires: SFEgcc-runtime-45
> 
> Warning:
> 
>     Using CC=gcc might lead to different results on different
>     distros, as you can't be sure to not stumble over e.g.
>     S11 provided gcc 4.5.x or gcc 3.4.3 as /usr/bin/gcc 
>     (depending on PATH *and* distro release).
>     The spec file then needs logic to depend on the correct
>     runtime packages.

Why don't we leave that problem to the distros? And if you want to be
nice to distros, please don't use CC=/usr/gnu/bin/gcc, since that breaks
specs on OpenIndiana, for example. (However, "BuildRequires: SFEgcc" is
fine, since the name "SFEgcc" gets mapped into the name of the native
gcc by the build system.)

> All the above is SFE centric and tries to stay safely away 
> from what the distros provide.
> 
> A distro may tweak the spec file and add more symbolic links
> to the compiler binaries, but this should always be done in
> a way that doesn't break SFE spec files. In particular the
> spec files should not rely on stuff the distro has added. 

What distros are you thinking of? Neither of the two distros I am
familiar with, Oracle Solaris 11 and OpenIndiana, build gcc using a
pkgbuild spec. They both use the userland make-based system.

I see no reason whatsoever why SFE specs should be written to use SFE's
gcc. SFE doesn't supply its own Sun Studio, and it got along fine for
years by using the system gcc 3.4.3. We recently started moving specs
over to use SFEgcc because Sun/Oracle was not shipping a recent gcc, but
now that Oracle ships gcc 4.5 and OpenIndiana ships gcc 4.6 (the runtime
ABIs of which should be compatible), I really don't see why we can't
return to the original practice of relying on the system gcc.

This is not to say that SFEgcc.spec should not be maintained. Quite the
contrary. One can expect that as new versions of gcc are released, the
SFE gcc spec will be updated to use the new version sooner than packages
provided by distributions are.

OpenIndiana is going to build its own gcc 4.6.1, and that will be the
standard compiler for the time being. I think you will see that it would
make no sense at all for packages in the OI SFE IPS repository to use
the SFEgcc runtime instead of the native OI gcc runtime, since the two
would be identical, except for their location. It would be extremely
confusing to users to find on their systems two different packages
providing exactly the same compiler and runtime libraries.

A hallmark of SFE has been to cohabit with system packages, and to adapt
to what the official distribution does. Forcing specs to use SFEgcc
instead of the native system gcc would be a grave violation of that well
established practice. Now that the two major distributions both provide
reasonably recent versions of gcc, there is no reason to write specs so
that they use SFEgcc instead.

Regards,
Alex

Hi Alex,

comments see inline :-)

On Sat, Oct 01, 2011 at 06:02:28PM -0400, Alex Viskovatoff wrote:
> Hi Thomas,
> 
> On Sat, 2011-10-01 at 22:35 +0200, Thomas Wagner wrote:
> > Recommendations.
> > 
> >     spec files could use 
> >        CC=/usr/gnu/bin/gcc 
> >     or 
> >        CC=gcc
> >        PATH=/usr/gcc/bin:$PATH
> > 
> >        to be sure to use a SFE provided gcc compiler binary.
> >     Once the majority of users has the new gcc packages, then
> >     spec files can start using CC=/usr/gnu/bin/gcc similar
> >     to what we do with studio compilers.
> 
> I am opposed to hardcoding the path of gcc. We did away with that when
> specs started to move away from using gcc 3.4.3 and to use SFEgcc
> instead. Since SFEgcc places symlinks to itself in /usr/gnu/bin
> and /usr/gnu/bin is in front of /usr/bin in CBE's PATH; that lets SFE's

Given that distros tend to deviate, SFE has to decide how to ensure
reliable/maintainable spec files and packages. This includes build
time settings and requirements for runtime libs and correct package
dependencies. One way to get maintainable and reliable spec files
is to use for SFE packages only SFE compilers and SFE runtime,
everything else is at risk to break later or be difficult to maintain.

The solution is cheap (install SFE compiler) and even survives several
upgrades of the OS without breaking SFE packages. It works across
different distributions. SFE sets those rules, a distro may decide
to provide an environment which exactly supports SFE, which would be
providing a compiler identical to what SFE provides and even the alias
package names to satisfy IPS. Identical is defined as having the new
symlinks in /usr/gcc/bin (or in transition phase as well in /usr/gnu/bin,
though marked deprecated and/or may move to mediated symlinks). And
this gcc must be preconfigured so that binaries always find the runtime
library in the right place (/usr/gcc/major.minor/lib:/usr/gcc/lib).

That way SFE spec files always find a well defined environment and
survive as may changes to the undelaying distribution as possible.
(Maintainability)

How does OI want to deal with the gcc-runtime and location for 
a symlink to the gcc binary (see 2 paragraphs above) ?

My recommendation: OI and S11 do whatever they want with theyr
gcc-4 series of compilers. SFE should stay away from distro
provided gcc-4 for it's own stability and maintainability
reasons and have the freedom to change and update them if 
needed.

This as well saves from problems with enterprise software on
distributions which rely on a runtime which is 1000% identical
to what the vendors sign off as being supported. It is not fun
to get into discussions if something is really identical or
not. Assumptions or telling it is compatible does not help in
those cases.

> gcc get selected. I think hardcoding the path, as some specs do with
> CC=/usr/sfw/bin/gcc, would be a step backward. That should only be done
> when it is know that a given gcc cannot build something, for cases, for
> example, when something builds with gcc 3.4.3 but not gcc 4.6.1.

Right, in case a specific compiler is needed, it has to be the full
path to the compiler (and be recorded as BuildRequires/Requires)

I thought on a pnm_macro like   %{pnm_gcc_default} containing
full paths to the compiler, as well as alternative macros like
%{pnm_gcc_46} and %{pnm_gcc_45} and %{pnm_gcc_34} / %{pnm_gcc_343}
 
> > 
> >     BuildRequires: SFEgcc           (preferred)
> >     Requires: SFEgcc-runtime
> >       or
> >     BuildRequires: SFEgcc-46        (if code needs 4.6.x)
> >     Requires: SFEgcc-runtime-46
> >       or
> >     BuildRequires: SFEgcc-45        (if code needs 4.5.x)
> >     Requires: SFEgcc-runtime-45
> > 
> > Warning:
> > 
> >     Using CC=gcc might lead to different results on different
> >     distros, as you can't be sure to not stumble over e.g.
> >     S11 provided gcc 4.5.x or gcc 3.4.3 as /usr/bin/gcc 
> >     (depending on PATH *and* distro release).
> >     The spec file then needs logic to depend on the correct
> >     runtime packages.
> 
> Why don't we leave that problem to the distros? And if you want to be
> nice to distros, please don't use CC=/usr/gnu/bin/gcc, since that breaks
> specs on OpenIndiana, for example. (However, "BuildRequires: SFEgcc" is
> fine, since the name "SFEgcc" gets mapped into the name of the native
> gcc by the build system.)

I don't want to deal with different distros if the price for having
an always consitent SFE world is for runtime only 5MBs and for
the compiler only 45MB binary packages.
And in case of switching gcc sources you need logic to require
the corred gcc-runtimepackage name as well.

And a distro would be well advised if they do not try to break
enterprise software. As a distro I would not want to build up 
inflexible contracting to a "guest" project on the system like 
SFE and OpenCSW and pkgsrc is.

 
> > All the above is SFE centric and tries to stay safely away 
> > from what the distros provide.
> > 
> > A distro may tweak the spec file and add more symbolic links
> > to the compiler binaries, but this should always be done in
> > a way that doesn't break SFE spec files. In particular the
> > spec files should not rely on stuff the distro has added. 
> 
> What distros are you thinking of? Neither of the two distros I am
> familiar with, Oracle Solaris 11 and OpenIndiana, build gcc using a
> pkgbuild spec. They both use the userland make-based system.
> 
> I see no reason whatsoever why SFE specs should be written to use SFE's
> gcc. SFE doesn't supply its own Sun Studio, and it got along fine for
> years by using the system gcc 3.4.3. We recently started moving specs
> over to use SFEgcc because Sun/Oracle was not shipping a recent gcc, but
> now that Oracle ships gcc 4.5 and OpenIndiana ships gcc 4.6 (the runtime
> ABIs of which should be compatible), I really don't see why we can't
> return to the original practice of relying on the system gcc.
> 
> This is not to say that SFEgcc.spec should not be maintained. Quite the
> contrary. One can expect that as new versions of gcc are released, the
> SFE gcc spec will be updated to use the new version sooner than packages
> provided by distributions are.

We have no other choice to maintain SFEgcc (4.6.1) because no distro 
provides what we think is right: Have the LINK_LIBGCC_SPEC set to
always find the runtime *and* do not poison the distro with a fixed
vendor dictated compiler version. We can add new versions, we always
find the right runtime independently of what the distro does.

Solaris provided for 20 years the freedom to choose a compiler freely.
And if you look at gcc-3.4.3 you had always the ability to omit this
version. This has changed now for S11 and OI, which both dictate a
single gcc-4.x.x version and not leaving room to let the user choose
his compiler and let him use different versions in parallel if the
need arises or one just want's to test in advance.

Again, a distro should not dictated a compiler version and if it does,
SFE should use it's own version to stay maintainable.


> OpenIndiana is going to build its own gcc 4.6.1, and that will be the
> standard compiler for the time being. I think you will see that it would
> make no sense at all for packages in the OI SFE IPS repository to use
> the SFEgcc runtime instead of the native OI gcc runtime, since the two

Reasons why it is better maintainable to use SFEgcc for all SFE packages,
see above. OpenCSW and pkgsrc (thanks for the LINK_LIBGCC_SPEC!) do it 
that way. Avoid short sighted dependencies to the distro. Just because
it works today does not justify to change spec files.

If a distro decides to rework a copy of the spec files repository, then
there must be ensured that this is a local change for that distro's copy
of SFE spec files.

> would be identical, except for their location. It would be extremely
> confusing to users to find on their systems two different packages
> providing exactly the same compiler and runtime libraries.
> 
> A hallmark of SFE has been to cohabit with system packages, and to adapt
> to what the official distribution does. Forcing specs to use SFEgcc
> instead of the native system gcc would be a grave violation of that well
> established practice. Now that the two major distributions both provide
> reasonably recent versions of gcc, there is no reason to write specs so
> that they use SFEgcc instead.

Looks different to me. The only distro provided gcc we used widely was 3.4.3.
The only gcc-4 compiler we used regularly was the SFE provided gcc. 
So if the ditros decide to make theyr own gcc, then SFE still wants to
be on the safe side and continue to use it's own SFEgcc and runtime
as for all those years before.
This is the recommendation because this can be tested by the maintainers.
I do not want to deal with outdated compilers just because the distro
doesn't want to upgrade or can't upgrade the compiler. Think 1 or 2
years ahead, SFE will be ever ahead of all distros. Don't introduce 
dependencies on a distro gcc today (it will be a downside tomorrow).

Regards,
Thomas

> 
> Regards,
> Alex
> 

-- 
-- 
Thomas Wagner

------------------------------------------------------------------------
Service rund um UNIX(TM),     Wagner Network Services, Thomas Wagner
Solaris(TM), Linux(TM)        Eschenweg 21, 89174 Altheim, Germany
Novell(TM), WindowsNT(TM)     TEL: +49-731-9807799, FAX: +49-731-9807711
Telekommunikation, LAN,       MOBILE/CELL: +49-171-6135989
Internet-Service, Elektronik  EMAIL: wagner@...

On Sun, 2 Oct 2011, Thomas Wagner wrote:
>
> The solution is cheap (install SFE compiler) and even survives several
> upgrades of the OS without breaking SFE packages. It works across

Not everyone will consider installing another compiler to be "cheap". 
Some people have a need for limited-footprint systems which can still 
do software development using the compiler of choice.

What ill effects will occur if libraries built by a non-SFE compiler 
are linked with libraries built using the SFE compiler?

The plan for a hard-coded run path seems like it might cause issues.

Bob
-- 
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

Hi Bob,

On Sun, Oct 02, 2011 at 11:04:33AM -0500, Bob Friesenhahn wrote:
>  On Sun, 2 Oct 2011, Thomas Wagner wrote:
> >
> > The solution is cheap (install SFE compiler) and even survives several
> > upgrades of the OS without breaking SFE packages. It works across
> 
>  Not everyone will consider installing another compiler to be "cheap". Some 
>  people have a need for limited-footprint systems which can still do software 
>  development using the compiler of choice.

Agreed, in a use case where you want to / have to minimize 
your systems.  The runtime is in either case with around 5MB 
small. The compiler (45MB) is needed only from one variant, 
either the SFE if you make spec-files or the distro provided.
So the question is more, have one or two times 5MB on the disk 
for the runtime. If you have SFEgcc as compiler, you usually 
discard the distro provided gcc-4 completely.
If you don't compile SFE packages and only run ready built
one, then this is only 5MB for the SFEgcc-runtime.

The path distros go at the moment is to force a single gcc
version.  This induces the problem that SFE can't easily
use a better compiler or just a version which works with
the provided sources.
And if we don't use LINK_LINGCC_SPEC to always find the 
correct runtime libs we can support, then SFE can't update
the SFEgcc independently of the distro. See for more com-
ments the file SFEgcc-runpath.spec and the corresponding 
patch headers.

Think 1 or 2 years ahead, then you might see that gcc maybe
found a more generic solution for the runtime libs then just
dumping them into /usr/lib/.
I expect the version of SFEgcc to be much higher then any
distribution provides at that time.
So please look ahead and let SFE do its own way independently
of any distribution. This independence is one of the strong
success factors for SFE.
 
>  What ill effects will occur if libraries built by a non-SFE compiler are 
>  linked with libraries built using the SFE compiler?

There are none. Try it out. If someone compiles with gcc-4
then he as well needs to provide correct runtime files.
The packaging system has to be used to ensure presence 
of prerequisites.
This is done in SFE by recording the dependency to the
correct runtime libraries package for *our* binaries.
If a system library is used, this other package takes 
care to have installed the right prerequisites.

 
>  The planfor a hard-coded run path seems like it might cause issues.

The opposite is the case, SFE needs a stable environment
and having the gcc runtime libs under control of SFE is an
important component of it, together with the compiler
under control of SFE. That way you get best results if
you use spec files on the varous distributions.
This keeps spec-files simple and reliable.

Note that not SFE introduced the new situation with gcc-4,
it was the distros and SFE tries to stay safe, regardless
what the distros bend inside theyr upgrade cycles.

If you see errors with the new variant of gcc, please
give detailed feedback. I did a huge amount of testing 
and the results are very good. If you find errors or 
problems, please share this information and we will look 
into them and see what the root cause is.

Instructions on how to test binaries regarding runtime libs
is contained in the spec-file and the patches.

Regards,
Thomas

> 
>  Bob
>  -- 
>  Bob Friesenhahn
>  bfriesen@..., http://www.simplesystems.org/users/bfriesen/
>  GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
> 

-- 
-- 
Thomas Wagner

------------------------------------------------------------------------
Service rund um UNIX(TM),     Wagner Network Services, Thomas Wagner
Solaris(TM), Linux(TM)        Eschenweg 21, 89174 Altheim, Germany
Novell(TM), WindowsNT(TM)     TEL: +49-731-9807799, FAX: +49-731-9807711
Telekommunikation, LAN,       MOBILE/CELL: +49-171-6135989
Internet-Service, Elektronik  EMAIL: wagner@...

On Sun, 2 Oct 2011, Thomas Wagner wrote:
>
>>  What ill effects will occur if libraries built by a non-SFE compiler are
>>  linked with libraries built using the SFE compiler?
>
> There are none. Try it out. If someone compiles with gcc-4
> then he as well needs to provide correct runtime files.
> The packaging system has to be used to ensure presence
> of prerequisites.

I am trying to think 1 or 2 years ahead.  If both the SFE compiler and 
the non-SFE compiler inject their own hard-coded run-path into the 
libraries, doesn't one of those compilers lose out in the end because 
the similar libraries will be picked up from the first directory which 
occurs in the run-path?

That said, as someone who has been building GCC under SunOS 5 since 
1992, I have experienced few problems with conflicts between GCC 
installations as long as the Sun linker is consistently used.  C++ ABI 
changes seem like the main issues which have occured.

At the moment I have eight versions of GCC installed on my Solaris 
system (ranging from 4.2.3 to 4.6.1) with the most recent version of 
each GCC runtime library (e.g. libgfortran.so.3) being brought in via 
symbolic links into the GCC install tree.  Old binaries depending on 
those libraries have continued to work fine.  Ever since libgcc_s.so 
was introduced, it has been named libgcc_s.so.1 on Solaris and I have 
not encountered any issue when upgrading.

Bob
-- 
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

Hi Bob,

what you are talking about different problems.

Regards,
Thomas


On Sun, Oct 02, 2011 at 01:52:34PM -0500, Bob Friesenhahn wrote:
>  On Sun, 2 Oct 2011, Thomas Wagner wrote:
> >
> >>  What ill effects will occur if libraries built by a non-SFE compiler are
> >>  linked with libraries built using the SFE compiler?
> >
> > There are none. Try it out. If someone compiles with gcc-4
> > then he as well needs to provide correct runtime files.
> > The packaging system has to be used to ensure presence
> > of prerequisites.
> 
>  I am trying to think 1 or 2 years ahead.  If both the SFE compiler and the 
>  non-SFE compiler inject their own hard-coded run-path into the libraries, 
>  doesn't one of those compilers lose out in the end because the similar 
>  libraries will be picked up from the first directory which occurs in the 
>  run-path?
> 
>  That said, as someone who has been building GCC under SunOS 5 since 1992, I 
>  have experienced few problems with conflicts between GCC installations as 
>  long as the Sun linker is consistently used.  C++ ABI changes seem like the 
>  main issues which have occured.
> 
>  At the moment I have eight versions of GCC installed on my Solaris system 
>  (ranging from 4.2.3 to 4.6.1) with the most recent version of each GCC 
>  runtime library (e.g. libgfortran.so.3) being brought in via symbolic links 
>  into the GCC install tree.  Old binaries depending on those libraries have 
>  continued to work fine.  Ever since libgcc_s.so was introduced, it has been 
>  named libgcc_s.so.1 on Solaris and I have not encountered any issue when 
>  upgrading.
> 
>  Bob
>  -- 
>  Bob Friesenhahn
>  bfriesen@..., http://www.simplesystems.org/users/bfriesen/
>  GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
> 

-- 
-- 
Thomas Wagner

------------------------------------------------------------------------
Service rund um UNIX(TM),     Wagner Network Services, Thomas Wagner
Solaris(TM), Linux(TM)        Eschenweg 21, 89174 Altheim, Germany
Novell(TM), WindowsNT(TM)     TEL: +49-731-9807799, FAX: +49-731-9807711
Telekommunikation, LAN,       MOBILE/CELL: +49-171-6135989
Internet-Service, Elektronik  EMAIL: wagner@...

On Sun, 2011-10-02 at 21:09 +0200, Thomas Wagner wrote:
> Hi Bob,
> 
> what you are talking about different problems.

Hi Thomas,

I don't think that you have convinced anyone that there is a problem to
which the solution is SFE packages exclusively using SFEgcc, instead of
a system provided gcc.

As the builder of SFE packages for OpenIndiana, I can assure you that
the OpenIndiana developers will not look kindly, and rightly so, to
oi-sfe delivering gcc 4.6.1 once OI itself does so natively. So in the
case of oi-sfe, SFE packages using SFEgcc is simply not an option.

OI will ship gcc 4.6 and Oracle Solaris will ship gcc 4.5. It is
possible that specs that build with one will not build with the other.
For example, when built with gcc 4.6, some specs require use of the
-fpermissive flag, which I expect that gcc 4.5 does not accept. A
solution to this problem would be to expect users of SFE running Oracle
Solaris to install SFEgcc, but not those running OI.

In the past, SFE has placed specs that distributions start to deliver
themselves at comparably recent versions into archive/, and stopped
bothering with them. gcc is a special case, so it doesn't make sense for
SFE to drop it, now that the distros provide recent versions of it. But
in insisting that SFE compete with distributions when it comes to gcc,
and forcing users to install it when they build any specs that use gcc,
you are trying to make SFE go on a path which it has avoided up until
now. As I said in my previous mail, a hallmark of SFE has been to
coexist with distribution packages, not to try to replace them.

In the past, you have insisted that choice should be left to users. Why
this abrupt about face?

Regards,
Alex

Hi Alex,

Answers inline :). Thanks for your answer. I think we can
make something good out if it.

On Sun, Oct 02, 2011 at 03:49:32PM -0400, Alex Viskovatoff wrote:
> On Sun, 2011-10-02 at 21:09 +0200, Thomas Wagner wrote:
> > Hi Bob,
> > 
> > what you are talking about different problems.
> 
> Hi Thomas,
> 
> I don't think that you have convinced anyone that there is a problem to
> which the solution is SFE packages exclusively using SFEgcc, instead of
> a system provided gcc.

About convinced, if I look at the replys then it looks like the
writers picked single issues and did not answer on the other 
arguments I'd written, only one +1 no -1? It is still encouraged to
go back and comment on each detail or place questions.
So one could say the important points of the proposal were ignored?
Was it too complicated, or were the readers just not deep enough
into the details? Or was it making sense and we can go ahead and
make SFEgcc a perfectly working compiler with ... advantages (read 
the proposal!)?
Did one single point of disagreement outshine all the advantages?

It would be so much better communication style to reply inline and
really give answers or questions related to the arguments.

If a reply just writes something different and against the proposal,
then we can not discuss the original arguments that way.

Even this email does not cover the whole proposal, in my view
this email is about if SFE want's to use a distro provided gcc 
compiler or not?
>From the pure SFE point of view, SFE wants the features from the 
SFEgcc compiler and get working spec files regardless of the
undelaying distribution.
If a distribution wants to make an exception, then we still
want spec files giving a reliable result (...then a little logic needed).

> As the builder of SFE packages for OpenIndiana, I can assure you that
> the OpenIndiana developers will not look kindly, and rightly so, to
> oi-sfe delivering gcc 4.6.1 once OI itself does so natively. So in the
> case of oi-sfe, SFE packages using SFEgcc is simply not an option.
That a bit like OI forces SFE to do things OI like? 
Or is it an OI being huffy on not seeing honorring what they provide?
Why does no one just invent a OI package delivering /usr/gnu/bin/gcc ->
/usr/bin/gcc and everything is solved nearly perfect.
Put those links into a package of radom name and assign the legacy
package name SFEgcc and then OI injects its compiler into SFE spec files.
(That kind of suggestions do help many times more then just
counter against the proposal.)
 
> OI will ship gcc 4.6 and Oracle Solaris will ship gcc 4.5. It is
> possible that specs that build with one will not build with the other.

This is giving strong reasons to SFE to specify a known good 
compiler in the spec files, in my proposal this is a reason to 
say that this should be SFEgcc.spec. We can't leave out from 
the spec files the "(Build)Requires: <this-gcc-compiler>", so 
what do you suggest to keep the dependency loops closed.

SFE is not merried with OI. SFE can still make the reqiurement to
use the known-good compiler SFEgcc and require that and update that
at whenever it makes sense. If OI in it's own copy of SFE spec 
files decides to change the files to an OI variant, then this
is fine and gives no reason to make an OI developer angry. 
In times where OpenSolaris delivers an older gcc version, no one
was offended that SFE wanted it's own gcc-4 version.
And in this email thread, reasons are given why SFE doesn't want
the slow evolvement of a distro provided gcc. A distro can't just
change things at will without paying a price for that.
Comments on the argument in the proposal are still encouraged.
Keep in mind why SFE should look ahead and not just stick to what 
we get from a distribution today. Even this looking ahead can
be discussed in detail and not silently ignored again.

> For example, when built with gcc 4.6, some specs require use of the
> -fpermissive flag, which I expect that gcc 4.5 does not accept. A
> solution to this problem would be to expect users of SFE running Oracle
> Solaris to install SFEgcc, but not those running OI.

This relates to the question above, how should a spec file look like
to require the correct compiler package and which gcc-runtime.
We already know pnm_macros. I'm open to proposals, then we will
discuss this.
 
> In the past, SFE has placed specs that distributions start to deliver
> themselves at comparably recent versions into archive/, and stopped
> bothering with them.

Yes, /archive was invented by me as a place to keep stuff and not
blindly deleting them. The problem at that time was, that spec files
have been removed even before the replacement was shipped in a  
development release of the OS (sometimes 4 and more weeks delay).
And so today it is still the case, that spec files should only 
move very slowly into /archive. 
In my view, even today the spec files move much too early into /archive,
there are users out there still needing them.
But we can live with a too quick move much better then with deletes.
/archive tells users that there is something, but not actively
maintained at the moment. But it can rise from the dead :-)

> gcc is a special case, so it doesn't make sense for
> SFE to drop it, now that the distros provide recent versions of it. But

This exactly it what I'm writing againt. *Today* is the only point
in time disto builders think. Theyr development model supports only
that. But SFE is spanning a wide range of distributions and can't
make use of spec files written to mach a single distribution *and*
point in time.
SFEgcc might be a not so optimal example, as my proposal says that
SFE will in many cases want a much more fresh gcc then what a distro
provides. (Emotions tell different I know.)

> in insisting that SFE compete with distributions when it comes to gcc,
> and forcing users to install it when they build any specs that use gcc,
> you are trying to make SFE go on a path which it has avoided up until
> now.

It can be viewed from a user's perspective and from a maintainer's 
perspective. The Mainainter wants to be sure the environment is 
as stable and supportable as possible even if the distro replaces
runtime stuff. 
And the Maintainer might not even have the user's target distri-
bution installed to test the spec files there.

In the view of a user, he might save 5Megabytes of runtime. 
Not that much space. About a deeloper we need not care too much
if he can run a OI-gcc/S11-gcc and an SFE-gcc all at the same time.
The proposal is done in a way that supports this.

Interesting question, if you look closer at "why would SFEgcc 
be in a competition with a distro provided gcc". 
 - does SFEgcc contain important fixes?
 - is SFEgcc updated more frequently?
 - does SFEgcc solve a problem with runtime-package upgrades?
 - can't a distro integrate important fixes in her gcc package?
 - ...  this list to be enhanced
 - is somone offended by "drop in replacement"? 
   answer: it co-exists, it only *can* replace.

>  As I said in my previous mail, a hallmark of SFE has been to
> coexist with distribution packages, not to try to replace them.
Another point for the list above. In no way SFEgcc forcefully
replaces a distro related gcc. If you know about technical reasons 
why they can't co-exist, I would be happy to know.
 
> In the past, you have insisted that choice should be left to users. Why
> this abrupt about face?
In practise, the choice was *only* if there was a choice.
The idea was to not force a user with a poor internet
connection to pull 100MB gcc sources for low extra value.

In a bigger number of packages there is already "Required:"
to have SFEgcc(runtime) and CC=/usr/gnu/bin/gcc for
waek or hard reasons related to the specific spec files
(Multimedia, compile errors).
And this setting works regardless what the OS release provides.
An be honest, in the "old" world, our Build-Environment let
all those configure runs stumble into gcc-4 from SFEgcc in 
nearly all cases. So we aren't stopping choice, SFE does
ensure now to run into a compiler where SFE knows that it
works. And packages built with the new LINK_LIBGCC_SPEC
setting can't be disturbed by the distro for gcc-runtime
libs. This is maintainable in the view of SFE.


An important point is to see the big picture and decide the
right thins for the long term.
If OI and S11 are great platforms for our users and a 
simple SFEgcc as in the proposal can't harm any OS type.
So all envolved persons from SFE or a distro should not 
have a need for emotions involved. 

 
> Regards,
> Alex

Regards,
Thomas


--
+49-171-6135989  http://www.wagner-net.net

Thomas,

The problem here is that you have been telling people that they should
use CC=/usr/gnu/bin/gcc in specs instead of CC=gcc, even though the SFE
community, as opposed to yourself, never decided that this practice
should be adopted. As I said in my initial post, I think hardcoding the
path of gcc in specs is a bad idea. Selection of the gcc compiler should
be left to the environment.

For example, in a ChangeLog entry for 2011-09-14, you have written:

SFEosg.spec, SFEflightgear.spec, SFEdillo.spec, SFEsimgear20.spec:
back to SFE default compiler location /usr/gnu/bin/gcc

When was it decided that /usr/gnu/bin/gcc is the "SFE default compiler
location"? To repeat, as I recall what happened, when SFE specs started
using SFEgcc instead of gcc-3, that was accomplished by changing
CC=/usr/sfw/bin/gcc to simply CC=gcc. The SFE gcc got picked up
because /usr/gnu/bin is in front of /usr/bin in the PATH of the standard
build environment. It was never decided that this practice should be
abandoned and a new practice of hardcoding gcc's path, this time with a
different path, should be adopted instead.

This issue is independent of whether your experimental gcc should be
made SFEgcc.

Regards,
Alex

Hi,

I think this problem started few years ago already because some specs
are unable to work with SUNWgcc (aka GCC 3.4.3) and these specs have
hardcoded gcc path because /usr/gnu/bin was not in default CBE PATH I
think. 

But generally it is not necessary, the most of specs, which need to
hardcode GCC as their compiler toolchain, can work with default gcc,
including version 3.4.3. Full path should be hardcoded only if specific
gcc version is necessary.

Best regards,

Milan

Alex Viskovatoff píše v Út 04. 10. 2011 v 18:57 -0400:
> Thomas,
> 
> The problem here is that you have been telling people that they should
> use CC=/usr/gnu/bin/gcc in specs instead of CC=gcc, even though the SFE
> community, as opposed to yourself, never decided that this practice
> should be adopted. As I said in my initial post, I think hardcoding the
> path of gcc in specs is a bad idea. Selection of the gcc compiler should
> be left to the environment.
> 
> For example, in a ChangeLog entry for 2011-09-14, you have written:
> 
> SFEosg.spec, SFEflightgear.spec, SFEdillo.spec, SFEsimgear20.spec:
> back to SFE default compiler location /usr/gnu/bin/gcc
> 
> When was it decided that /usr/gnu/bin/gcc is the "SFE default compiler
> location"? To repeat, as I recall what happened, when SFE specs started
> using SFEgcc instead of gcc-3, that was accomplished by changing
> CC=/usr/sfw/bin/gcc to simply CC=gcc. The SFE gcc got picked up
> because /usr/gnu/bin is in front of /usr/bin in the PATH of the standard
> build environment. It was never decided that this practice should be
> abandoned and a new practice of hardcoding gcc's path, this time with a
> different path, should be adopted instead.
> 
> This issue is independent of whether your experimental gcc should be
> made SFEgcc.
> 
> Regards,
> Alex

Hi Milan,

thanks for your answer.

One unresolved thing is, how to (Build)Require the correct
runtime package then, given the case we let spec files
choose whatever CC=gcc comes first in search path on that
specific platform.

Best Regards,
Thomas

On Wed, Oct 05, 2011 at 01:24:27PM +0200, Milan Jurik wrote:
> Hi,
> 
> I think this problem started few years ago already because some specs
> are unable to work with SUNWgcc (aka GCC 3.4.3) and these specs have
> hardcoded gcc path because /usr/gnu/bin was not in default CBE PATH I
> think. 
> 
> But generally it is not necessary, the most of specs, which need to
> hardcode GCC as their compiler toolchain, can work with default gcc,
> including version 3.4.3. Full path should be hardcoded only if specific
> gcc version is necessary.
> 
> Best regards,
> 
> Milan
> 
> Alex Viskovatoff píše v Út 04. 10. 2011 v 18:57 -0400:
> > Thomas,
> > 
> > The problem here is that you have been telling people that they should
> > use CC=/usr/gnu/bin/gcc in specs instead of CC=gcc, even though the SFE
> > community, as opposed to yourself, never decided that this practice
> > should be adopted. As I said in my initial post, I think hardcoding the
> > path of gcc in specs is a bad idea. Selection of the gcc compiler should
> > be left to the environment.
> > 
> > For example, in a ChangeLog entry for 2011-09-14, you have written:
> > 
> > SFEosg.spec, SFEflightgear.spec, SFEdillo.spec, SFEsimgear20.spec:
> > back to SFE default compiler location /usr/gnu/bin/gcc
> > 
> > When was it decided that /usr/gnu/bin/gcc is the "SFE default compiler
> > location"? To repeat, as I recall what happened, when SFE specs started
> > using SFEgcc instead of gcc-3, that was accomplished by changing
> > CC=/usr/sfw/bin/gcc to simply CC=gcc. The SFE gcc got picked up
> > because /usr/gnu/bin is in front of /usr/bin in the PATH of the standard
> > build environment. It was never decided that this practice should be
> > abandoned and a new practice of hardcoding gcc's path, this time with a
> > different path, should be adopted instead.
> > 
> > This issue is independent of whether your experimental gcc should be
> > made SFEgcc.
> > 
> > Regards,
> > Alex
> 
> 
> 
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _________________________________________________________________
> SFE-devel mailing list - Pkgbuild-sfe-devel@...
> http://pkgbuild.wiki.sourceforge.net/SFE
> https://lists.sourceforge.net/lists/listinfo/pkgbuild-sfe-devel
> 

-- 
-- 
Thomas Wagner

------------------------------------------------------------------------
Service rund um UNIX(TM),     Wagner Network Services, Thomas Wagner
Solaris(TM), Linux(TM)        Eschenweg 21, 89174 Altheim, Germany
Novell(TM), WindowsNT(TM)     TEL: +49-731-9807799, FAX: +49-731-9807711
Telekommunikation, LAN,       MOBILE/CELL: +49-171-6135989
Internet-Service, Elektronik  EMAIL: wagner@...

Hi Thomas,

nothing will change. (Build)Requires: SFEgcc(runtime) will stay in specs
were GCC 4.x.y is necessary, otherwise SUNWgcc should be there for
cc_is_gcc cases. Yes, it can complicate situations when somebody has
SFEgcc or different gcc-4.x preinstalled but that should not happen in
build systems with package distribution, these should use minimal OS
installation.

And if somebody needs something distro specific, he can use "sed" in his
local workspace.

Best regards,

Milan

Thomas Wagner píše v st 05. 10. 2011 v 14:32 +0200:
> Hi Milan,
> 
> thanks for your answer.
> 
> One unresolved thing is, how to (Build)Require the correct
> runtime package then, given the case we let spec files
> choose whatever CC=gcc comes first in search path on that
> specific platform.
> 
> Best Regards,
> Thomas
> 
> On Wed, Oct 05, 2011 at 01:24:27PM +0200, Milan Jurik wrote:
> > Hi,
> > 
> > I think this problem started few years ago already because some specs
> > are unable to work with SUNWgcc (aka GCC 3.4.3) and these specs have
> > hardcoded gcc path because /usr/gnu/bin was not in default CBE PATH I
> > think. 
> > 
> > But generally it is not necessary, the most of specs, which need to
> > hardcode GCC as their compiler toolchain, can work with default gcc,
> > including version 3.4.3. Full path should be hardcoded only if specific
> > gcc version is necessary.
> > 
> > Best regards,
> > 
> > Milan
> > 
> > Alex Viskovatoff píše v Út 04. 10. 2011 v 18:57 -0400:
> > > Thomas,
> > > 
> > > The problem here is that you have been telling people that they should
> > > use CC=/usr/gnu/bin/gcc in specs instead of CC=gcc, even though the SFE
> > > community, as opposed to yourself, never decided that this practice
> > > should be adopted. As I said in my initial post, I think hardcoding the
> > > path of gcc in specs is a bad idea. Selection of the gcc compiler should
> > > be left to the environment.
> > > 
> > > For example, in a ChangeLog entry for 2011-09-14, you have written:
> > > 
> > > SFEosg.spec, SFEflightgear.spec, SFEdillo.spec, SFEsimgear20.spec:
> > > back to SFE default compiler location /usr/gnu/bin/gcc
> > > 
> > > When was it decided that /usr/gnu/bin/gcc is the "SFE default compiler
> > > location"? To repeat, as I recall what happened, when SFE specs started
> > > using SFEgcc instead of gcc-3, that was accomplished by changing
> > > CC=/usr/sfw/bin/gcc to simply CC=gcc. The SFE gcc got picked up
> > > because /usr/gnu/bin is in front of /usr/bin in the PATH of the standard
> > > build environment. It was never decided that this practice should be
> > > abandoned and a new practice of hardcoding gcc's path, this time with a
> > > different path, should be adopted instead.
> > > 
> > > This issue is independent of whether your experimental gcc should be
> > > made SFEgcc.
> > > 
> > > Regards,
> > > Alex
> > 
> > 
> > 
> > ------------------------------------------------------------------------------
> > All the data continuously generated in your IT infrastructure contains a
> > definitive record of customers, application performance, security
> > threats, fraudulent activity and more. Splunk takes this data and makes
> > sense of it. Business sense. IT sense. Common sense.
> > http://p.sf.net/sfu/splunk-d2dcopy1
> > _________________________________________________________________
> > SFE-devel mailing list - Pkgbuild-sfe-devel@...
> > http://pkgbuild.wiki.sourceforge.net/SFE
> > https://lists.sourceforge.net/lists/listinfo/pkgbuild-sfe-devel
> > 
> 
> --