Menu
▾
▴
#3828 gcc45-4.5.0-1000 with co-existing gcc45-compiler split-off
closed
5
2010-06-01
2010-04-27
No
The attached packaging is an extension of the previously proposed gcc45-4.5.0-1000 packaging. It implements the ability of gcc45 to co-exist with other gcc4x packages (after they have been updated in a similar fashion). The conflicting files from the current gcc4x packages has been moved into a new gcc45-compiler package which recreates them as symlinks. This packaging also adopts the use of a -fsf-4.X suffix so that the compilers are available in %p/bin via the main gcc4x package. The packaging has been tested by....
1) 'fink install gcc45' with the previous gcc45-4.5.0-1000 packaging installed.
2) 'fink install gcc46' to install the same packaging approach for a gcc46 snapshot (proving that gcc45 and gcc46) can co-exist.
3) 'fink install gcc45-compiler' and 'fink install gcc46-compiler' to verify that the default FSF gcc compiler can be switched with the
new packaging approach.
Note: I will post similar packaging for a gcc44-4.4.4-1000/gcc44-compiler-4.4-1 once the final FSF gcc 4.4.4 tarball is posted later this week.
Jack _ don't forget to copy here the update-alternatives stuff I put in libfffi
Users should not have to think of installing a different program when they miss a man file.
(And similarly for gdb-binutils_ a program is not functional w/o its .mo files!)
JF
Tested gcc45-4.5.0-1001 x86_64 variant with upgrade from gcc45-4.5.0-1000.
Implemented update-alternatives.
JF, Note that you should have...
PostInstScript: <<
update-alternatives --install %p/share/man/man3/ffi.3 ffi %p/share/man/man3/%N_ffi.3 60 \
--slave %p/share/man/man3/ffi_call.3 ffi_call.3 %p/share/man/man3/%N_ffi_call.3 \
--slave %p/share/man/man3/ffi_prep_cif.3 ffi_prep_cif.3 %p/share/man/man3/%N_ffi_prep_cif.3
<<
PreRmScript: <<
if [ $1 != "upgrade" ]; then
update-alternatives --remove ffi.3 %p/share/man/man3/%N_ffi.3
fi
<<
where name has the .3 suffix. At least this is how it is done in gst-plugins-base-0.10.info.
the "name" of the link is immaterial, as long as
the same name is used in all pkgs that use this link,
and in no other.
That's why I said you could just copy from libffi
(resp. binutils), just changing the priority.
JF
"name" is just the name of the link in %p/etc/alternatives,
never seen by a user except when he uses explicitly
the update-alternatives command
JF
Stupid questiions:
1) I have at the moment 2 gcc45's ..
one in my /sw32 dir and one in /sw32
I don't see the reason for all this ...
The 2 should be functionally equivalent, no ?
(ii.e., produce identical output for identical input)
In particular, the ouput of running test on either
should be identical ?
?
2) Another stupid question (motivated by my interest
in atlas, whose whole purpose is to build the basic algorithms
well tuned for the underlying machine): does (on intel)
"--march=native -mtune="native" really give the correct results ?
For instance, on my machine, I get from "syctl -A hw" :
hw.optional.x86_64: 1
hw.optional.sse4_2: 0
hw.optional.sse4_1: 1
hw.optional.supplementalsse3: 1
hw.optional.sse3: 1
hw.optional.sse2: 1
hw.optional.sse: 1
hw.optional.mmx: 1
hw.optional.floatingpoint: 1
(I know that output might not be completely reliable,
and a good test is better..)
E.g., does it detect the difference between
sse4_2 and sse4_1 ?
Or will it just just tune for "core2" , where
I might have to add further -m flags
for further distinctions , e.g. among those 2 ?
And, more generally, is there a way to check
how exactly it interprets "native" ?
3) This is really just for atlas, _ sorry _, but iI
guess this is the place where I might get reliable
answers ...
a) is there a way to have a 64bit fink with a powerPC (Gx)
machine; and what would be the corresponding
%m expansions ?
b) what would be flags corresponding to "native"
for ppc machines ?
Thanks a lot in advance !
Jean-Francois
JF,
The first question doesn't make any sense. You have mention /sw32 twice. With regard to tuning, the dirty little secret is that the generic costs outperforms the core2 costs in the Polyhedron benchmarks, etc. The CPU vendors donated these cost tables but haven't really enhanced them (such that generic is now faster on a whole). FYI, the default configuration on darwin has been bumped up to use -msse3 (like Apple's gcc-4.2 in Snow Leopard). As for 64-bit on powerpc, I don't think there is as much interest because (unlike on intel) there is a net performance loss (or at best a wash) in going from 32-bit to 64-bit. No register starvation relief to be gained there.
Switch from (>= %v-%r) to (= %v-%r). Synchronize update-alternative names with libffi.
1) Sorry _ the first question meant once /sw32 and the other time /sw64
2) "generic" outperforming "native" is terrible ..
I might understand for tuning _ but even for arch !
gcc can't make any use even of this ??
And even using "core2" rather than generic doesn't improve things ?
Why did they introduce it then ?
3) for 64bit on powerpc :
a) is there (or might there be there) such an option in fink ?
b) I'd guess it might depend on G4 vs G5 _ would that be the only (and exact) distinction ?
c) is there a way in fink to distinguish between the above (like %m evaluating to different things ?
(or I wouldn't care to run any other script to test...)
4) Independently, what would be the right tests to find the right "-m.." flags
simulating a real "native" on ppc machines ? (using sysctl etc...)
Cheers,
JF
In libffii , "ffi" is declared as master, with the 2 others as slaves.
(and there is obviously a good reason for doing so)
You declare things differently _ inconsistent declarations
is really looking for trouble, without reason !
Please fix !
JF
While 2 builds are still running in parallel, anorther small comment about packaging.
Concerning info files, I don't think you followed Dan Macks's advice, and it seems clear
to me the info files are broken.
E.g., any hyperlink from gcc-4.info will be to a non-existent cpp.info _ even w/o
considering the case of multiple co-existent gcc4X pkgs
There may be other solutions than the one he suggested _ e.g. involving a separate
"-doc" splitoff _ but it is crucial for info files that all hyperlinks work exactly as expected.
(And I don't mind if some info or man pages shadow Apple's; am quite used to use
the full pathname when I specifically want Apple's stuff.
It IS fink's policy to have the specified order for MANPATH and INFOPATH ! )
JF
PS: maybe discuss the details of this again with dmacks, since he clearly
thought about the issue ..
Don't want to do duplicate work.
My understanding is that the problem only exists when no gcc4x package remainsinstalled. In that case, perhaps the easy fix would be to add a PostRmScript for each gcc4x package that would execute...
infofiles="cpp gcc"
for infofile in $infofiles ; do
install-info ---infodir=%p/share/info -delete $infofile-4.info %p/share/info
done
infofiles="cp-tools cppinternals gccinstall gccint gcj gfortran libgomp"
for infofile in $infofiles ; do
install-info ---infodir=%p/share/info --delete $infofile.info %p/share/info
done
to purge out the ghost symlinks. I am not fond of the idea of overlapping the info files because it is not obvious to the user exactly which version of gcc's info file is being displayed. It still seems better to assume that users aren't total idiots and can puzzle out that gcc-fsf-4.x, etc will display the appropriate info page.
Opps, that should be....
nfofiles="cpp gcc"
for infofile in $infofiles ; do
install-info ---infodir=%p/share/info -delete $infofile-4.info
done
infofiles="cp-tools cppinternals gccinstall gccint gcj gfortran libgomp"
for infofile in $infofiles ; do
install-info ---infodir=%p/share/info --delete $infofile.info
done
Use exact update-alternatives from libffi. Fix accidental duplication of InfoDocs filenames.
Remove any attempt to rename info files and place them in the conflicting gcc45 package.
OK Peter _ and Jack,
I'll take the gcc stuff over if you want, and commit ASAP.
Please Jack, let us finish this _ why don't you just follow
D. Macks' advice, and use --infodir to put the info files in
%p/lib/gcc4.x/info
Then optionally the main pkg ("gcc4.x") could
(in order of "better and better"), either
a) add that dir to the user's INFOPATH
or
b) put in %p/share/info symlinks to the real info files
or
c) let the user manage the symlinks as a group
(i.e., a single master link, named eg "gcc_info")
via update-alternatives (with prio = 4x)
This last option seems dominant to me,
because it allows me to browse and compare
how some versions of gcc differ in some respect,
without having to switch my working gcc
[I know you have a reluctance to update-alternatives;
if you want I'll code it for you (and even the change in --infodir ...)]
As soon as that's fixed, I'll launch (on intel, 10.5, bith 32 and 64 bit)
a re-build + test _ and hope as many as possible others will do ! _,
and then, unless catastrophe, commit.
JF
One small additional comment, sorry ..
Going for such a structure, it helps a lot
(to speed up upgrading by users and other
pkgs) if the main pkg (the symlinks) is
called plainly say "gcc", w/o any versioning.
(Indeed, then a "selfupdate" makes them
automatically update their gcc pkg _
further, the name is free in fink's namespace,
so take it!)
To keep coexisting info files, it means then
that those have to be named eg as
gcc4x-compiler.info
and have the "gcc" pkg as a splitoff.
(cf eg already gettext-bin for an example).
In general such a refactoring may be a
big hassle, and require substantial
reworking of the info file, but in this
case you are lucky :
- all the work is done in "gcc4x-compiler"
- then a Splitoff gets you as now "gcc4x-shlibs"
- then in Spitoff2 (this is "gcc") you create
(in its InstallScript) all the symlinks to %N
Sorry _ but much better to think of such things
before rather than too late..
Best,
JF
gcc45 patch file
cloog 0.15.9-1 info file required for gcc45
Use --infodir=%p/lib/gcc4.5/info to store info files in gcc45-compiler package. Add update-alternatives to create symlinks to these from gcc45 package.
Will look at refactoring later. I have a day job.
Corrected the update-alternatives only to discover that we will have to explicitly index these info files from the post install script for them to be available. This is rapidly becoming absurd.