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