Re: which cctool on Darwin?

Re: which cctool on Darwin?

[Jack Howarth]

Geoff,
    Could you update the cctools (particularly the source version)
in infrastructure to the newer version? Both Fink and OpenDarwin
build odcctools packages to insure that a current cctools is
available for their g95 and gcc packages regardless of what Xcode
is installed. Currently fink is building gcc 4.2 snapshots (to
provide macintel gfortran compilers) using --disable-multilib
because of the buggy ld64 in the version of cctools currently
in infrastructure.
          Jack

Re: which cctool on Darwin?

[Geoffrey Keating]

[-- Attachment #1: Type: text/plain, Size: 1091 bytes --]


On 05/06/2006, at 6:09 PM, Jack Howarth wrote:

> Geoff,
>     Could you update the cctools (particularly the source version)
> in infrastructure to the newer version?

I see no reason to do this.

You can get the last released version of cctools at
<http://www.opensource.apple.com/darwinsource/DevToolsMay2006/>
along with much other open source.

> Both Fink and OpenDarwin
> build odcctools packages to insure that a current cctools is
> available for their g95 and gcc packages regardless of what Xcode
> is installed.

That's their choice, of course, but I wouldn't do that.  They run the  
risk that their cctools might be old and not capable of  
understanding, say, crt1.o.

> Currently fink is building gcc 4.2 snapshots (to
> provide macintel gfortran compilers) using --disable-multilib
> because of the buggy ld64 in the version of cctools currently
> in infrastructure.

There is no ld64 in any version of cctools.  There never has been.   
cctools only contains the 32-bit linker.  I do not intend to start  
providing ld64 updates unless I create a patch which requires one.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2408 bytes --]

Re: which cctool on Darwin?

[Shantonu Sen]

I built trunk with odcctools-20060608 (to be release soon), which is  
based on cctools-590.42.1 and ld64-47.2 from Xcode 2.3. I've posted my  
results:

Without MACOSX_DEPLOYMENT_TARGET set:
<http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg00488.html>

With MACOSX_DEPLOYMENT_TARGET=10.4 set:
<http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg00491.html>


The thousands of failures are because of <http://gcc.gnu.org/PR26792>,  
which is diligently being pursued by unassigned@gcc.gnu.org.  
Unassigned, how is that bug going? It's a P1 for 4.2.0, it would sure  
be nice to get a status update.

Shantonu

On Jun 6, 2006, at 9:44 AM, Jack Howarth wrote:

> Shantonu,
>     Thanks for the reply. I already figured out last night that
> I could use the odcctools cvs to generate a new odcctools tarball
> based on cctools-590.42.1. I was able to create an updated fink
> odcctools package using that tarball.
>     I am bothering with this issue because I have noticed that
> if I have fink sourced while I build gcc trunk manually from
> the tarball that I see a slew of g++ regressions. These regressions
> are identical to those reported by Bradley Lucier...
>
> http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg00221.html
>
> The regressions occur even if I build gcc trunk with the fink
> odcctools package deinstalled (so that the Xcode 2.3 cctools
> is used). Interestingly, if I build gcc trunk with fink not
> being sourced, the resulting build passes its g++ testsuite
> properly. Furthermore, I can source fink after gcc trunk is
> built and the g++ regressions don't show up. So the problem
> appears to be a conflict with something installed by fink
> that only occurs during the gcc trunk build itself.
>    Shantonu, what sort of testsuite results do you get for
> opendarwin when you build gcc trunk? It would be nice to get
> a handle on why some of us are seeing these odd g++ failures.
> In my case, they seem to be tethered to something installed
> by fink but I am having a difficult time pinning it down. At
> first I thought it might be the setting of MACOSX_DEPLOYMENT_TARGET
> but that should only be set when building packages using fink
> itself and not set just because fink is sourced.
>                         Jack
> ps From my conversation with Geoff, I believe with the latest
> cctools, we should be able to build gcc trunk on a G5 now
> without resorting to the --disable-multilib hack.

Re: which cctool on Darwin?

[Jack Howarth]

     I have finished a build of gcc trunk on Darwin with a fink package
of bison 2.3 installed and can confirm that the c++ regressions I saw
with bison 2.1 installed have disappeared. So there must be some problem
with bison 2.1 and gcc trunk (at least on Darwin).
               Jack

Re: which cctool on Darwin?

[Jack Howarth]

   I believe I may have discovered the component that was causing the
c++ regressions I was seeing on Darwin when fink was sourced. I have
found that after I deinstalled bison v2.1 installed by fink, I was
able to build gcc trunk on MacOS X 10.4 with fink sourced and still
pass the c++ testsuite properly. I have built bison v2.3 and will
see if that shows the same behavior as v2.1.
   Have there been any reports of problems with bison v2.1 and gcc
trunk?
          Jack

Re: which cctool on Darwin?

[Jack Howarth]

Shantonu,
    Thanks for the reply. I already figured out last night that
I could use the odcctools cvs to generate a new odcctools tarball
based on cctools-590.42.1. I was able to create an updated fink
odcctools package using that tarball.
    I am bothering with this issue because I have noticed that
if I have fink sourced while I build gcc trunk manually from
the tarball that I see a slew of g++ regressions. These regressions
are identical to those reported by Bradley Lucier...

http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg00221.html

The regressions occur even if I build gcc trunk with the fink
odcctools package deinstalled (so that the Xcode 2.3 cctools
is used). Interestingly, if I build gcc trunk with fink not
being sourced, the resulting build passes its g++ testsuite
properly. Furthermore, I can source fink after gcc trunk is
built and the g++ regressions don't show up. So the problem
appears to be a conflict with something installed by fink
that only occurs during the gcc trunk build itself.
   Shantonu, what sort of testsuite results do you get for
opendarwin when you build gcc trunk? It would be nice to get
a handle on why some of us are seeing these odd g++ failures.
In my case, they seem to be tethered to something installed
by fink but I am having a difficult time pinning it down. At
first I thought it might be the setting of MACOSX_DEPLOYMENT_TARGET
but that should only be set when building packages using fink
itself and not set just because fink is sourced.
                        Jack
ps From my conversation with Geoff, I believe with the latest
cctools, we should be able to build gcc trunk on a G5 now
without resorting to the --disable-multilib hack.

Re: which cctool on Darwin?

[Shantonu Sen]

Building cctools from source is like stabbing yourself in the kidney.  
You should use darwinbuild if you want to build the Apple-provided  
source only, or use odcctools if you want additional portability  
patches to build on multiple OSes and versions and have relocatable -- 
prefix support.

I've already imported Apple cctools-590.42.1 and Apple ld64-47.2 into  
odcctools CVS, and will release a snapshot after some more work.

Shantonu

On Jun 5, 2006, at 7:08 PM, Geoffrey Keating wrote:

>
> On 05/06/2006, at 6:55 PM, Jack Howarth wrote:
>
>> Geoff,
>>    Okay. I downloaded the cctools-590.42.1.tar.gz and attempted to  
>> build
>> it using the same fink packaging script used for odcctools. However  
>> I get
>> a build failure of...
>>
>> cc -O -g -I../../include -Wall -Wno-long-double -no-cpp-precomp - 
>> fno-builtin-round - 
>> D_MACH_I386_THREAD_STATUS_FPSTATE_LEGACY_FIELD_NAMES_ - 
>> D_ARCHITECTURE_I386_FPU_FPSTATE_LEGACY_FIELD_NAMES_  -static -DRLD - 
>> DSA_RLD -fno-builtin -finline -fno-keep-inline-functions -fsigned- 
>> bitfields -force_cpusubtype_ALL -msoft-float -nostdinc -I/System/ 
>> Library/Frameworks/Kernel.framework/PrivateHeaders/libsa -I/System/ 
>> Library/Frameworks/Kernel.framework/PrivateHeaders -I/System/ 
>> Library/Frameworks/Kernel.framework/Headers/libsa -I/System/Library/ 
>> Frameworks/Kernel.framework/Headers/bsd -I/System/Library/ 
>> Frameworks/Kernel.framework/Headers -DKERNEL -DKERNEL_PRIVATE - 
>> DAPPLE -DNeXT -DLIBSA_PRIVATE -c \
>>         -MD -dependency-file ./get_toc_byte_sex.d \
>>         -o ./get_toc_byte_sex.o ../get_toc_byte_sex.c
>> ../get_toc_byte_sex.c:25:16: error: ar.h: No such file or directory
>> ../get_toc_byte_sex.c: In function 'get_toc_byte_sex':
>>
>> which has been apparently been reported on the darwin lists without
>> replies...
>>
>> http://lists.apple.com/archives/darwin-userlevel/2006/Jan/msg00016.html
>>
>> Any suggestions for working around this problem?
>
> You probably need to have Xcode 2.3 installed to build this version  
> of cctools.  You may also need to use the 10.4u SDK or be working on  
> an Intel machine (My installation of Xcode 2.3 has an ar.h in at  
> least /Developer/SDKs/MacOSX10.4u.sdk/usr/include/ar.h).
>

Re: which cctool on Darwin?

[Geoffrey Keating]

[-- Attachment #1: Type: text/plain, Size: 1701 bytes --]


On 05/06/2006, at 6:55 PM, Jack Howarth wrote:

> Geoff,
>    Okay. I downloaded the cctools-590.42.1.tar.gz and attempted to  
> build
> it using the same fink packaging script used for odcctools. However  
> I get
> a build failure of...
>
> cc -O -g -I../../include -Wall -Wno-long-double -no-cpp-precomp - 
> fno-builtin-round - 
> D_MACH_I386_THREAD_STATUS_FPSTATE_LEGACY_FIELD_NAMES_ - 
> D_ARCHITECTURE_I386_FPU_FPSTATE_LEGACY_FIELD_NAMES_  -static -DRLD - 
> DSA_RLD -fno-builtin -finline -fno-keep-inline-functions -fsigned- 
> bitfields -force_cpusubtype_ALL -msoft-float -nostdinc -I/System/ 
> Library/Frameworks/Kernel.framework/PrivateHeaders/libsa -I/System/ 
> Library/Frameworks/Kernel.framework/PrivateHeaders -I/System/ 
> Library/Frameworks/Kernel.framework/Headers/libsa -I/System/Library/ 
> Frameworks/Kernel.framework/Headers/bsd -I/System/Library/ 
> Frameworks/Kernel.framework/Headers -DKERNEL -DKERNEL_PRIVATE - 
> DAPPLE -DNeXT -DLIBSA_PRIVATE -c \
>         -MD -dependency-file ./get_toc_byte_sex.d \
>         -o ./get_toc_byte_sex.o ../get_toc_byte_sex.c
> ../get_toc_byte_sex.c:25:16: error: ar.h: No such file or directory
> ../get_toc_byte_sex.c: In function 'get_toc_byte_sex':
>
> which has been apparently been reported on the darwin lists without
> replies...
>
> http://lists.apple.com/archives/darwin-userlevel/2006/Jan/ 
> msg00016.html
>
> Any suggestions for working around this problem?

You probably need to have Xcode 2.3 installed to build this version  
of cctools.  You may also need to use the 10.4u SDK or be working on  
an Intel machine (My installation of Xcode 2.3 has an ar.h in at  
least /Developer/SDKs/MacOSX10.4u.sdk/usr/include/ar.h).


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2408 bytes --]

Re: which cctool on Darwin?

[Jack Howarth]

Geoff,
   Okay. I downloaded the cctools-590.42.1.tar.gz and attempted to build
it using the same fink packaging script used for odcctools. However I get
a build failure of...

cc -O -g -I../../include -Wall -Wno-long-double -no-cpp-precomp -fno-builtin-round -D_MACH_I386_THREAD_STATUS_FPSTATE_LEGACY_FIELD_NAMES_ -D_ARCHITECTURE_I386_FPU_FPSTATE_LEGACY_FIELD_NAMES_  -static -DRLD -DSA_RLD -fno-builtin -finline -fno-keep-inline-functions -fsigned-bitfields -force_cpusubtype_ALL -msoft-float -nostdinc -I/System/Library/Frameworks/Kernel.framework/PrivateHeaders/libsa -I/System/Library/Frameworks/Kernel.framework/PrivateHeaders -I/System/Library/Frameworks/Kernel.framework/Headers/libsa -I/System/Library/Frameworks/Kernel.framework/Headers/bsd -I/System/Library/Frameworks/Kernel.framework/Headers -DKERNEL -DKERNEL_PRIVATE -DAPPLE -DNeXT -DLIBSA_PRIVATE -c \
        -MD -dependency-file ./get_toc_byte_sex.d \
        -o ./get_toc_byte_sex.o ../get_toc_byte_sex.c
../get_toc_byte_sex.c:25:16: error: ar.h: No such file or directory
../get_toc_byte_sex.c: In function 'get_toc_byte_sex':

which has been apparently been reported on the darwin lists without
replies...

http://lists.apple.com/archives/darwin-userlevel/2006/Jan/msg00016.html

Any suggestions for working around this problem?
            Jack

Re: which cctool on Darwin?

[Geoffrey Keating]

[-- Attachment #1: Type: text/plain, Size: 476 bytes --]


On 05/06/2006, at 2:58 PM, Jack Howarth wrote:

> Geoff,
>    Would the ld64 in the cctools of Xcode 2.3 happen to resolve
> PR 27121?
>            Jack

27121 was originally reported as a bug which can only be resolved by  
cctools, not ld64 which is not part of cctools.  I see there was some  
additional commentary added to that bug after it was closed, trying  
to report a different issue.

However, yes, the ld64 in Xcode 2.3 will resolve the newly-reported  
problem.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2408 bytes --]

Re: which cctool on Darwin?

[Jack Howarth]

Geoff,
   Would the ld64 in the cctools of Xcode 2.3 happen to resolve
PR 27121?
           Jack

Re: which cctool on Darwin?

[Geoffrey Keating]

[-- Attachment #1: Type: text/plain, Size: 297 bytes --]


On 05/06/2006, at 1:44 PM, Jack Howarth wrote:

>     I noticed that Xcode 2.3 seems to have a cctools with a higher
> version that that in the infrastructure directory at the gcc ftp
> site. Should we be using the Xcode 2.3 version instead of that
> 20060413 copy for building gcc trunk?

Yes.


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2408 bytes --]

which cctool on Darwin?

[Jack Howarth]

    I noticed that Xcode 2.3 seems to have a cctools with a higher
version that that in the infrastructure directory at the gcc ftp
site. Should we be using the Xcode 2.3 version instead of that
20060413 copy for building gcc trunk?
           Jack