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
1. COMPILER NAMESOn 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 .
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.
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.
2. THE GCC FIELDThe 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.
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++.
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. 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.
Toodles, DavePS: 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.
PGP.sig
Description: This is a digitally signed message part
