Hi Dave,
Le 28 juin 2005 à 13:08, Dave Vasilevsky a écrit :
Hi Michèle,
It seems you're a bit confused, understandable given the GCC
situation. Hopefully this mail can make things clearer, it's a bit
long so I've written it in sections. Also, you may want to read the
new section in the packaging manual: http://fink.sourceforge.net/
doc/packaging/compilers.php
I've translated it, so that I've read it, then re-read; then again. I
should probably read it again.
1. COMPILER NAMES
On a 10.4-transitional system, we want all C++ packages to use the
3.3 ABI if possible, so fink arranges that c++, g++, c++-3.3 and g+
+-3.3 are all the *same thing*. Fink also arranges by default that
CXX = g++-3.3 .
Ok, that's complete. It was not clear to me that c++ and g++ was the
same as c++-3.3 and g++-3.3.
Note that on 10.4 (non-transitional), c++, g++, c++-4.0 and g++-4.0
will all be the same thing, and CXX will be g++-4.0. In other
words, on both distributions you can just use c++, g++ or CXX
normally and the correct G++ version will be used.
OK.
So you see, SetCXX: c++ does nothing at all, it just uses the same
compiler as the normal CXX.
When is SetCXX useful then? Primarily if you have to force a
certain version, eg for a package that requires 3.3 you can use
SetCXX: g++-3.3. But unless this is truly necessary--and it usually
isn't--don't use it.
The SetCXX: c++ and SetCC: cc that you used in cssed accomplish
nothing, but they're also harmless. So you can leave them in or
remove them, it's up to you.
So, it was here till the beginning, could I remove it in all trees? I
mean this is already enough complicated for me, to put things that do
nothing.
2. THE GCC FIELD
The GCC field only very rarely affects the compilation of a
package. It currently does two things:
i. It tells Fink to make sure that gcc_select is on the most recent
value. This feature is pretty rarely encountered, not very
necessary anymore, and kind of confusing, so you can ignore it and
pretend you never read this. Stick your fingers in your ear and
sing "La la la, I can't hear you" :-)
ii. This is the important part. GCC informs developers that this
package uses C++, which is important to know for ABI transitions.
Fink may use this information at some time in the future, but
doesn't really use it yet.
That part was clear to me, maybe the only one :-)
So the GCC field is more descriptive than instructive. If your
package won't compile, changing the GCC field won't help, it's
about as effective as changing Homepage. Instead you use GCC just
to describe your package, to indicate that it uses C++ code.
One pretty quick way to test a package for C++ code is with the
script that I posted about yesterday. You can get it here:
http://cvs.sourceforge.net/viewcvs.py/*checkout*/fink/experimental/
vasi/scripts/gcc-field
and then run 'gcc-field cssed', and it will tell you that
"Everything looks OK!", which means cssed needs to keep the GCC:
3.3 field that it currently has, since it uses C++.
Thanks, I'll use it. I've already used the one Peter posted, and yes,
there's a difference.
3. LINKING C AND C++
One last reason you may be confused is that there is sometimes (but
not always) a bug that occurs when linking C++ and C code on
account of C++ using version 3.3 and C using version 4.0. When you
link C and C++ code together, you must use the C++ compiler since C
doesn't know about the stdc++ runtime library. But g++-3.3 (which
is the same as g++ and c++ for fink packages) doesn't know about
certain new gcc-4.0 features.
If your packages doesn't experience a problem linking C and C++
code together, then you don't have to worry about this. On the
other hand, if it does, you'll see this:
ld: Undefined symbols:
_fprintf$LDBLStub
...
In that case, you need to add -lSystemStubs to the compilation
command.
Happily, cssed doesn't show this bug, so you don't need this.
Oh, that's new to me.
4. CSSED
Just to recap...
Basically, cssed.info is fine as it is. It does indeed use C++
code, so you have to have GCC: 3.3, which is already there. It
doesn't have the SystemStubs bug, so you don't have to worry about
that.
It includes SetCXX: c++ and SetCC: cc, which basically do nothing,
so you can leave that in or take it out, either way is fine.
Hopefully this hasn't made things even more confusing, I hope it
makes our compiler situation more understandable. If there's still
anything that's not clear, please ask and I'll try to clarify.
No, it's perfectly clear now, many thanks.
PS: If it's ok with everyone, once gmane have archived this email,
I'll link to it from the Compilers page in the packaging manual.
Yes, please, very useful.
Cheers,
Michèle
<http://micmacfr.homeunix.org>
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel