checking for gcc

Thomas De Contes d.l.tDeContes at free.fr
Sat May 2 06:48:31 PDT 2009


Le 26 avr. 09 à 22:27, Ryan Schmidt a écrit :

>
> On Apr 26, 2009, at 09:31, Thomas De Contes wrote:
>
>> Le 21 mars 09 à 00:52, Ryan Schmidt a écrit :
>>
>>> On Mar 20, 2009, at 17:53, Thomas De Contes wrote:
>>>
>>>> Le 16 mars 09 à 00:05, Ryan Schmidt a écrit :
>>>>
>>>>> On Mar 15, 2009, at 17:36, Thomas De Contes wrote:
>>>>>
>>>>>> i updade MacPorts, and at the step "port upgrade outdated" it  
>>>>>> always sets
>>>>>> checking for gcc... /usr/bin/gcc-4.0
>>>>>>
>>>>>> whereas /usr/bin/gcc-4.0 does not exist and /usr/bin/gcc  
>>>>>> points on gcc-3.3
>>>>>>
>>>>>>
>>>>>> what is the problem ?
>>>>>
>>>>> /usr/bin/gcc-4.0 should exist, and /usr/bin/gcc should point to  
>>>>> it, on Tiger and later.
>>>>
>>>> ok
>>>> if /usr/bin/gcc-4.0 exists but /usr/bin/gcc does not point to  
>>>> it, it's not right ?
>>>
>>> If /usr/bin/gcc-4.0 exists but /usr/bin/gcc points to gcc-3.3  
>>> then you have most likely used the gcc_select program to select  
>>> gcc 3.3.
>>
>> i think it can happen if i install devtools + gcc-3.3, and then i  
>> add gcc-4.0
>> to avoid any pb of this kind, i reinstalled devtools + gcc-4.0 at  
>> the same time
>
> I didn't think it was possible to install Xcode without gcc 4.0.

yes !


Xcode 2.4.1 :

no component is not unactivatable
and graphic tools, gcc-3.3, and gcc-4.0 are 3 different components

so it's possible to install graphic tools but neither gcc-3.3 nor  
gcc-4.0
(although i don't think we can do a lot of thing as is)
or opposite ...


Xcode 2.5 (i just downloaded it) :

one component is not unactivatable,
and seeing at files (apple-i), it seems to install graphic tools and  
gcc-3.3, but not gcc-4.0

and there is a "command line tools" component which is unactivatable,  
it seems to install gcc-4.0



>>> This should not affect the majority of ports since MacPorts tells  
>>> ports to use /usr/bin/gcc-4.0 by default on Tiger and later.
>>
>> ok :-)
>>
>>> Specific ports may override this as needed. For example some very  
>>> old software must compile with gcc-3.3 because gcc-4.0 is too  
>>> new; in this case, those ports indicate this requirement and  
>>> MacPorts allows them to use gcc-3.3 instead.
>>
>> do you think i should keep gcc-3.3 ?
>> could some recent software depend on some very old software ?
>
> I forget what kind of computer you have.

both

> As far as I know the gcc 3.3 that comes with Xcode can only build  
> PowerPC programs. Either that, or it cannot run on Intel Macs at  
> all. Either way, it won't be useful for building dependencies on  
> Intel Macs.

thanks
anyway, with the last devtools, gcc 3.3 is imposed



>>>>> What OS version do you have? What version of Xcode?
>>>>
>>>> checking Mac OS X version... 10.4.11
>>>> checking Xcode version... 2.4.1
>>
>>
>>
>>>> btw,
>>>>
>>>> why does it work fine to build MacPorts itself, with gcc 3.3,  
>>>> and not to build software ?
>>>
>>> Port authors have limited resources with which to test ports.  
>>> Usually people only have a single Mac, running either Leopard or  
>>> Tiger, with either an Intel or PowerPC processor. This means most  
>>> port authors are only testing on 1/4 of the supported systems.  
>>> Problems can crop up on the remaining 3/4 of the supported  
>>> systems the author did not test on.
>>>
>>> We do not want to increase the testing burden even further by  
>>> allowing users to compile ports with a different compiler than  
>>> the one the port author tested with. For this reason, MacPorts  
>>> instructs ports to ignore what the user has gcc_selected'ed and  
>>> instead to use a specific compiler on specific OS versions (3.3  
>>> on Panther, 4.0 on Tiger and Leopard). Individual ports can  
>>> override this if it's necessary for those ports, but users are  
>>> not supposed to override this.
>>
>> i fully (i think) understand this :-)
>>
>> and i see 2 options :
>>
>> 1
>> don't constraint anyone to use /usr/bin/gcc-4.0 and nothing else
>> of course, you support only /usr/bin/gcc-4.0 and nothing else, and  
>> port authors don't have any more test to make
>> just, you don't restrict it "physically" :-)
>> and you could write a big big warning at time of building MacPorts  
>> itself
>>
>> 2
>> once i've understood "the mechanism", i was surprised that  
>> building MacPorts itself worked fine, without even a warning !
>> i would expect that MacPorts refuse to build, saying it need /usr/ 
>> bin/gcc-4.0 (even if it doesn't need it for itself, regarding to  
>> the default settings for ports)
>>
>>
>> the 1 is the best from my point of view (it's the most  
>> "adaptable"), but there is probably a lot of changes to do, for  
>> not enough advantages
>> but i think that the 2 is realist, what do you think about it ? :-)
>
> I do not want (1). I do not want users to change the compiler. I  
> can see no reason to do so. It can only cause problems -- problems  
> which some users will inevitably write to the list for help with,  
> thus increasing our burden to help people and reducing the time we  
> have available to help with other problems.

i fully understand :-)

>
> Regarding (2), MacPorts base does not complain about gcc 3.3 simply  
> because nobody has added code to do so. Actually, it should not  
> complain;  should just use /usr/bin/gcc-4.0 (on Tiger and Leopard)  
> regardless of what has been gcc_select'ed, but again nobody has yet  
> added code to do so. I do not know if there is any real problem  
> with compiling MacPorts base with gcc 3.3 on Tiger or Leopard.

with gcc 3.3, i don't think there is any real problem,

but when i put an other compiler which knows ada in my path, i get
configure: error: Could not locate a working Objective-C runtime.
so it would be nice to do it, so i won't have to change my path every  
time :-)

also, if /usr/bin/gcc-4.0 doesn't exist, it would be nice whether  
MacPorts doesn't compile,
if not, users don't understand why MacPorts compiles but not Ports ;-)

>
>
>>>> why does it say :
>>>> checking for gcc... /usr/bin/gcc-4.0
>>>> checking for C compiler default output... configure: error: C  
>>>> compiler cannot create executables
>>>> rather than sth like
>>>> checking for gcc... /usr/bin/gcc-4.0 not found
>>>> ?
>>>
>>> Here you are asking about the configure script of the port you  
>>> were trying to install. For questions about why that configure  
>>> script does what it does, you'll have to ask the authors of that  
>>> software
>>
>> ok
>> well, if building MacPorts itself gives an explicit error enough,  
>> not worry about building of ports :-)
>
> I don't quite understand what you say here. Building MacPorts  
> itself is a separate issue from building ports using MacPorts.


i just spoke about the case where /usr/bin/gcc-4.0 doesn't exist
(see above)

i find the error msg not explicit enough
but if there is a nice msg when compiling MacPorts, we won't try to  
compile Ports without /usr/bin/gcc-4.0 :-)


-- 
Téléassistance / Télémaintenance
http://www.portparallele.com/ThomasDECONTES/



More information about the macports-users mailing list