Re: [Fink-devel] Help needed with g++ handling

[Michèle Garoche]

Le 29 juin 2005 à 19:31, Dave Vasilevsky a écrit :


Hi Michèle,

I'm glad my email was helpful to you.


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.




I'm honestly not sure why you put SetCC and SetCXX in cssed.info in  
the first place, so I don't know whether you should or should not  
remove them. It could be that some version of cssed coulnd't detect  
the compiler properly or something? *shrug*

Let's say that :-) ...


You'll have to try to remember.
because it's not likely to happen and I cannot find any trace of the  
very first info file I submitted.


At the moment, the version is unique in 10.3 and 10.4, except for  
dependencies on gettext. And I cannot test anymore on 10.2. So that  
I've just changed 10.3 and 10.4 trees.


Cheers,
Michèle





---
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

Re: [Fink-devel] Help needed with g++ handling

[Dave Vasilevsky]

Hi Michèle,

I'm glad my email was helpful to you.

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.


I'm honestly not sure why you put SetCC and SetCXX in cssed.info in  
the first place, so I don't know whether you should or should not  
remove them. It could be that some version of cssed coulnd't detect  
the compiler properly or something? *shrug*


You'll have to try to remember.

Dave

PGP.sig
Description: This is a digitally signed message part

Re: [Fink-devel] Help needed with g++ handling

[Michèle Garoche]

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





---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to fo

Re: [Fink-devel] Help needed with g++ handling

[Dave Vasilevsky]

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 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 .


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 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.


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,
Dave


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.




PGP.sig
Description: This is a digitally signed message part