Re: build failure, GMP not available

[Shantonu Sen]

For what it's worth, I did a build on Mac OS X for Intel 10.4.8 last  
week, and had no problems building GMP 4.2.1 and mprf-2.2.0, with no  
special --target options. Maybe you have an old version of gmp in your  
default linker search path causing bad things to happen. I think if  
it's failing for you, you're doing something wrong. I see no evidence  
that either GMP or mainline GCC is broken on i686-darwin


I submitted the results of that build to gcc-testresults.

Shantonu

On Oct 30, 2006, at 11:49 AM, Geoffrey Keating wrote:



On 30/10/2006, at 10:34 AM, Daniel Berlin wrote:


4. Are you aware that the GMP home page says

[2006-05-04] GMP does not build on MacInteltosh machines. No fix
planned for GMP 4.x.

and indeed it does not appear to build correctly when configured on
my MacBook Pro?


Errr, well,
I have installed the version from macports on my macbook pro, and  
it works fine.

No new regressions in the gcc testsuite since the GMP patches.


I don't know what "macports" is.  When I download gmp-4.2.1 from ftp.gnu.org 
, the official GNU site, and run 'configure && make && make check',  
I get:


gcc -m32 -O2 -fomit-frame-pointer -mtune=pentium3 -march=pentium3 -o  
t-bswap t-bswap.o  ./.libs/libtests.a /Volumes/Data/build/ 
gmp-4.2.1/.libs/libgmp.a ../.libs/libgmp.a

/usr/bin/ld_classic: Undefined symbols:
_calling_conventions_ebp
_calling_conventions_ebx
_calling_conventions_edi
_calling_conventions_eflags
_calling_conventions_esi
_calling_conventions_fenv
_calling_conventions_retaddr
_calling_conventions_save_ebp
_calling_conventions_save_ebx
_calling_conventions_save_edi
_calling_conventions_save_esi

which I presume is the problem referred to.

Googling for 'macports gmp' leads me to  which suggests to me that maybe I should say 'configure -- 
host=none-apple-darwin'.  I'll try that.



Because of the severe nature of this problem (everything doesn't
build, multiple hosts affected), I'd like you to consider backing  
out

this patch until the problems are fixed.  I'll work on a patch which
just disables the check for Darwin.

Uh, what?

In this case, I have no idea what problems you are experiencing, as
the version of GMP/MPFR required works fine on macbook pro, AFAICT.


Do you see this error when you run 'make check'?


It's actually about time we got to using GMP in the middle end, and I
don't believe reverting a patch because some non-primary platforms
have a few pains here and there initially is the best course of
action.


I agree that it's nice to use GMP in the middle-end, but it raises  
significant portability issues.  It looks like there are workarounds  
for the x86-darwin problem, but surely there will be other problems  
on other platforms.  My greatest concern is bootstrapping.



Also, although I experience no regressions, i'll point out that there
is no automated tested for macintel darwin that posts to
gcc-testresults, which does not bode well for something you would  
like

to be a primary platform.


You are not seeing any posts because there has never been a  
successful build in the tester's environment.  Guess what the  
current problem is.

Re: build failure, GMP not available

[Shantonu Sen]

Ah, your "&&" did not indicate which command was failing.

You can work around the issue with CFLAGS="-fno-common", which you  
probably want to do anyway if this code is ever linked in statically  
into libgfortran or something. However, it's just the test code that  
has this issue.


You can also work around this by setting RANLIB="ranlib -c", so that  
the calling_convention_* symbols get put in the archive table of  
contents so that the Darwin linker loads the archive member on-demand  
from libtests.a


Shantonu

On Oct 30, 2006, at 5:42 PM, Geoffrey Keating wrote:



On 30/10/2006, at 5:31 PM, Shantonu Sen wrote:

For what it's worth, I did a build on Mac OS X for Intel 10.4.8  
last week, and had no problems building GMP 4.2.1 and mprf-2.2.0,  
with no special --target options. Maybe you have an old version of  
gmp in your default linker search path causing bad things to  
happen. I think if it's failing for you, you're doing something  
wrong. I see no evidence that either GMP or mainline GCC is broken  
on i686-darwin


Did you run 'make check'?  Did you get the line that caused the  
error I saw?

Re: Running ranlib after installation - okay or not?

[Shantonu Sen]

ranlib is required on Darwin after changing the timestamp of the  
archive.


Shantonu

On Aug 31, 2005, at 11:02 AM, Ian Lance Taylor wrote:


Gerald Pfeifer <[EMAIL PROTECTED]> writes:

We currently perform the following sequence of commands as part of  
the

installation (-m 444 being the default on current FreeBSD systems).

  install -m 444 ./libgcc.a /prefix/lib/gcc/i386-portbld- 
freebsd5.4/3.4.5/gcc/i386-portbld-freebsd5.4/3.4.5/
  ranlib /prefix/lib/gcc/i386-portbld-freebsd5.4/3.4.5/gcc/i386- 
portbld-freebsd5.4/3.4.5/libgcc.a


This works fine when running as root, but when doing an  
installation as

user, installation fails:

  ranlib: unable to copy file '/prefix/lib/gcc/i386-portbld- 
freebsd5.4/3.4.5/gcc/i386-portbld-freebsd5.4/3.4.5/libgcc.a'  
reason: Permission denied

  gmake[2]: *** [install] Error 1


I believe installing libraries with permissions 444 ought to be okay,
as is for ranlib to refuse working on files which are not writeable.

Does anyone disagree (and if not, have suggestions how to address  
this

in GCC)?


ranlib is basically never required on a modern system.  It is really
only needed if the archive is built with the S option to ar.

So I think the best way to address this is to not run ranlib.

Ian

Re: Running ranlib after installation - okay or not?

[Shantonu Sen]

If you do change how this is implemented in the config* files, please
make sure that you still support cross compiling to Darwin. In that
case, the runtime libraries for the target would still run into this  
issue,

because you'd be using the Darwin ranlib, even on a Linux build/host.

Shantonu

On Aug 31, 2005, at 12:28 PM, Ian Lance Taylor wrote:


Still, all this really means is that we should be host specific when
deciding whether or not to run ranlib.

In fact we are already host specific as to what flags we use.  On
Darwin we use -c, which we do not use on any other system.  Maybe we
should remove AC_PROG_RANLIB from configure.ac, and add something to
config.host instead.

Except that probably this has to get into libtool somehow or
something.  Hmmm.

Ian

Re: Running ranlib after installation - okay or not?

[Shantonu Sen]

i think Peter's point is:

if mode(archive) == 444
  if target == Darwin
Darwin ranlib will upgrade it to 644 anyway and succeed, and/or  
use a temp file and rename(2)

  else
ranlib isn't really needed anyway, so ignore the error
  fi
else
  ranlib should be used, and should succeed, but still, ignore errors
fi


On Sep 1, 2005, at 1:15 PM, Andrew Pinski wrote:



On Sep 1, 2005, at 4:10 PM, Joe Buck wrote:


On Thu, Sep 01, 2005 at 12:16:23PM +0900, Peter O'Gorman wrote:
I would suggest continuing to run ranlib after install, but not  
failing if

it does not work.


Won't you then get warning messages on Darwin every time someone  
tries
to use the installed library (since the symbol table timestamp  
will be

older than the file timestamp)?


It will not be a warning on darwin, it will be straight error as
Darwin's linker does not like the timestamp to be out of date at
all.

-- pinski

Re: Fishy build system: make_exports.pl called on darwin?

[Shantonu Sen]

You're making a lot of terrible assumptions and drawing several  
incorrect conclusions. xnu-792 is not the same as "darwin7.9.2", and  
no configure script in the last 6 years should be detecting a Mac OS  
X system as "ppc-apple-darwin" (it should be "powerpc-apple-darwin").


What is the output of
% uname -r
% type uname
% /usr/share/libtool/config.guess

If you have GNU coreutils installed, something bad may be happening.

Shantonu

On Oct 2, 2005, at 3:42 PM, Marcin Dalecki wrote:



On 2005-10-03, at 00:26, Andrew Pinski wrote:


6) Is this whining reporting significant information, for the
person that wants to fix the bug?



Well on the system in question ppc-apple-darwin-7.8.0 the perl  
script

in question simply doesn't work. Since there doesn't appear to be
much in the way of it inside acinclude.m4 it appears that setting
unconditionally enable_symvers inside the following:


I can confirm now that --disable-symvers worked fine on my system.

This perl script works just fine for me on powerpc-darwin7.9.0  I  
don't

see why are we piping the output to nm when it should be piping nm's
output to c++filt.

Also this perl script works fine on powerpc-darwin7.4.0 also.


Well to be a bit more precise I have the following at hand:

uname -a
Darwin dzc14.neoplus.adsl.tpnet.pl 8.2.0 Darwin Kernel Version  
8.2.0: Fri Jun 24 17:46:54 PDT 2005; root:xnu 792.2.4.obj~3/ 
RELEASE_PPC Power Macintosh powerpc


The configure scripting drama translates this in to:
ppc-apple-darwin7.8.0.

I'm not quite sure if this is correct since guessing the GCC  
version interpretation here I would expect this to came out as:


ppc-apple-darwin7.9.2

aka: Tiger darwin 10.4.2

A fairly plain system without any additional fink darwinports or  
similar packages. Perhaps this could be the cause that we have  
basically different nm programs in action here?

Re: regression hunt setup using Subversion

[Shantonu Sen]

if sysctl is present in the path, "sysctl hw.ncpu" might be useful as  
well. Seems to work on FreeBSD and Darwin, assuming you don't require  
granularity of whether those CPUs are HTT or not.


Shantonu

On Oct 21, 2005, at 12:27 PM, Janis Johnson wrote:


On Fri, Oct 21, 2005 at 03:14:47PM -0400, Andrew Pinski wrote:


On Oct 21, 2005, at 3:11 PM, Joseph S. Myers wrote:


The use of

ncpu=`grep '^processor' /proc/cpuinfo | wc -l`

seems Linux-specific; this looks like it should be in gcc-svn-env  
as a

default for the user to customise, rather than in bin/gcc-build-*.



I don't think it is Linux specific, it works on my openBSD box.  It
might
work on other OS's which have /proc on it too like Solaris.


I was afraid of this, which is why before I only submitted the  
toplevel

scripts for contrib/ and let people provide their own build scripts.
I'm happy to make things more portable, though, as long as people
provide suggestions like this; thanks.

Janis

Re: backslash whitespace newline

[Shantonu Sen]

You're forgetting something: GNU/Linux distros are built with  
thousands of lines of patches to support new/different gcc behavior.  
Thousands were added for the 2->3 transition, and thousands more for  
3->4. Please don't claim that all upstream programs in all  
distributions support gcc 3.4.4 and 4.0.2 without modification, and  
thus gcc is the standard by which portability is defined.


Shantonu

On Oct 25, 2005, at 9:33 PM, Joe Buck wrote:


On Tue, Oct 25, 2005 at 06:51:45PM -0700, Mike Stump wrote:

On Oct 25, 2005, at 5:40 PM, Joe Buck wrote:

1) a C++ comment



But case 1 is the nasty one, as users think they can put anything
in a comment.  A backslash at the end is likely to be an accident,
since just starting the next line with a // is easy enough.


Be interesting to see the results of a grep on a large software
base.  Does anyone have ready access to, say a linux distro handy?
Of all the hits I know about, none of them were an accident.


You're forgetting something: GNU/Linux distros are built with gcc,
and everyone is now using 3.x.  So there can't be buildable programs
that depend on behavior gcc doesn't support.  There can't be any
currently maintained programs for Linux or BSD that do.

Only users that have never used gcc 3.x could be depending on non-gcc
behavior.  Apple is free to do whatever, but please don't claim
that you're doing it for "portability" if you encourage your users
to write code that breaks with gcc 3.x shipped by folks other than
Apple.

Re: Status and rationale for toplevel bootstrap (was Re: Example of debugging GCC with toplevel bootstrap)

[Shantonu Sen]

Just to be clear, you're suggesting that if you have:

--build=powerpc-foo-bar --host=powerpc64-foo-bar --target=powerpc64- 
foo-bar


The user be able to specify something so that the build systems knows  
the build
machine can execute the host binaries, and a 4-stage bootstrap should  
occur?


Shantonu

On Jan 16, 2006, at 9:10 AM, Richard Kenner wrote:


I don't see how this is any different to boostrapping gcc with any
other system compiler. It's fairly common for the system  
compiler to
use a different ABI to the new gcc. Why is 32/64-bit any  
different?


It isn't any different, which is the whole point.  The point is that
what's being built is a compiler that's for a different host than we
tell configure that it's for: specificially it's a cross-compiler and
we're saying it's a native compiler.

The issue isn't what compiler *builds* the stage1 compiler, but  
what the
stage1 compiler *is*: if it's not for the same system as its  
target, it's
not a native compiler, but a cross-compiler and it doesn't make  
sense to

bootstrap cross-compiler (or, to be precise, if you do so, you need an
additional stage, so that compiler would become a "stage0" compiler).

Re: Status and rationale for toplevel bootstrap (was Re: Example of debugging GCC with toplevel bootstrap)

[Shantonu Sen]

OK, so you want people to do

./configure  --build=powerpc-foo-bar --host=powerpc-foo-bar -- 
target=powerpc64-foo-bar --prefix=$PWD/native64-compiler

make
make install
CC=$PWD/native64-compiler/bin/gcc /configure  --build=powerpc64-foo- 
bar --host=powerpc64-foo-bar --target=powerpc64-foo-bar

make  <>
rm -rf $PWD/native64-compiler

That would be really annoying for the same net effect, and something  
better managed by GCC's build machinery


Shantonu

On Jan 16, 2006, at 9:39 AM, Richard Kenner wrote:


Just to be clear, you're suggesting that if you have:

--build=powerpc-foo-bar --host=powerpc64-foo-bar -- 
target=powerpc64-foo-bar


The user be able to specify something so that the build systems  
knows

the build machine can execute the host binaries, and a 4-stage
bootstrap should occur?

Well, that's possible, but I'd really prefer to avoid dealing with
"bootstraps" of cross-compilers at all and stick to native  
compilers, so

no, I'm not really suggesting that.

Re: Results for 4.1.0 20060117 (prerelease) testsuite on powerpc-apple-darwin8.4.0 (-m64 results)

[Shantonu Sen]

I've posted a new version of odcctools (based on Apple's cctools and  
ld64 source) which should fix a few thousand of the failures.  
Instructions are at:




This is based on cctools-590.18 and ld64-26.0.81, which should be  
substantially similar to what you have, and since you can use -- 
prefix, you don't need to overwrite the Apple-provided tools.


Can you report how this changes things?

Shantonu

On Jan 18, 2006, at 9:21 AM, Bradley Lucier wrote:


http://www.math.purdue.edu/~lucier/gcc/test-results/4_1-2006-01-17.gz

(Too large to be accepted here.)

So I have a question.  I've installed the latest Xcode release, or,  
at least I think I did:


[lindv2:gcc/4.1/objdir64] lucier% gcc -v
Using built-in specs.
Target: powerpc-apple-darwin8
Configured with: /private/var/tmp/gcc/gcc-5250.obj~12/src/configure  
--disable-checking -enable-werror --prefix=/usr --mandir=/share/man  
--enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^ 
[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 -- 
build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 -- 
target=powerpc-apple-darwin8

Thread model: posix
gcc version 4.0.1 (Apple Computer, Inc. build 5250)
[lindv2:gcc/4.1/objdir64] lucier% ld -v
Apple Computer, Inc. version cctools-590.23.2.obj~17

and I was hoping that this might clear up a significant fraction of  
the 7,000+ 64-bit testsuite failures for 4.1 on powerpc-apple- 
darwin8.4.0.  But it appears this hasn't happened yet.


Does anyone wish to try yet again to drive it into my thick skull  
what goals gcc 4.1 has on powerpc-apple-darwin8.4.0?


(And I still can't seem to use the Apple tools to build 64-bit  
shared libraries that work; but that isn't a problem for this  
list ...)


Brad

Re: Results for 4.1.0 20060117 (prerelease) testsuite on powerpc-apple-darwin8.4.0 (-m64 results)

[Shantonu Sen]

I'm not recommending anything, I'm trying to help you verify whether  
GCC's testsuite is failing because of testsuite bugs, gcc bugs, tools  
bugs, or OS bugs. This should help you focus on the legitimate  
problems with gcc.


In this case, the thousands of failures were an interaction between  
how the testsuite runs the linker with -L paths relative to the  
bootstrapped compiler in the local build directory, and wouldn't be  
seen, typically, if you ran the testsuite against an installed compiler.


As a GCC developer and/or bleeding edge user, it's fairly common to  
require a newer toolchain to support new features in gcc than is  
being officially shipped by Apple. Running the testsuite successfully  
counts as a "feature" in this case. In those cases, you can either  
use binaries posted by members of Apple's compiler team, or build  
odcctools from source. I don't see this as significantly different.


If your concern is that you don't trust the modifications that have  
been made, you can view them and apply only the fixes you want:  
<http://cvs.opendarwin.org/cgi-bin/cvsweb.cgi/projects/odcctools/src/>


Shantonu

On Jan 25, 2006, at 2:12 PM, Bradley Lucier wrote:



On Jan 23, 2006, at 8:07 PM, Shantonu Sen wrote:

I've posted a new version of odcctools (based on Apple's cctools  
and ld64 source) which should fix a few thousand of the failures.  
Instructions are at:


<http://www.opendarwin.org/projects/odcctools/usingodcctools.html>

This is based on cctools-590.18 and ld64-26.0.81, which should be  
substantially similar to what you have, and since you can use -- 
prefix, you don't need to overwrite the Apple-provided tools.


Can you report how this changes things?


The results are much better, thanks:

http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg01316.html

So what are you recommending people do?  Use the OpenDarwin version  
of cctools instead of relying on Apple's official version?


Brad

x86 Darwin an libgcc-math

[Shantonu Sen]

With trunk and those set of patches, x86 Darwin bootstraps and builds  
libgcc-math. However, there are some issues actually using it:


alias:/tmp ssen$ cat test.c
#include 
#include 

int main(int argc, char *argv[]) {
  double a = 1.5900;
  printf("%f\n", sin(a));
  return 0;
}
alias:/tmp ssen$ /opt/gcc/bin/gcc -o test test.c -msselibm
/usr/bin/ld: Undefined symbols:
___libm_sse2_sin
collect2: ld returned 1 exit status
alias:/tmp ssen$

The problem appears to be that Darwin's specs override  
LINK_COMMAND_SPEC and don't include %(link_gcc_math). Something like  
this may be needed:

Index: config/darwin.h
===
--- config/darwin.h (revision 110474)
+++ config/darwin.h (working copy)
@@ -202,17 +202,17 @@
#define LINK_COMMAND_SPEC "\
%{!fdump=*:%{!fsyntax-only:%{!precomp:%{!c:%{!M:%{!MM:%{!E:%{!S:\
 %{!Zdynamiclib:%(linker)}%{Zdynamiclib:/usr/bin/libtool} \
 %l %X %{d} %{s} %{t} %{Z} \
 %{!Zdynamiclib:%{A} %{e*} %{m} %{N} %{n} %{r} %{u*} %{x} %{z}} \
 %{@:-o %f%u.out}%{!@:%{o*}%{!o:-o a.out}} \
 %{!Zdynamiclib:%{!A:%{!nostdlib:%{!nostartfiles:%S \
 %{L*} %(link_libgcc) %o %{fprofile-arcs|fprofile-generate| 
coverage:-lgcov} \

-%{!nostdlib:%{!nodefaultlibs:%(link_ssp) %G %L}} \
+%{!nostdlib:%{!nodefaultlibs:%(link_gcc_math) %(link_ssp) %G %L}} \
 %{!A:%{!nostdlib:%{!nostartfiles:%E}}} %{T*} %{F*} "

/* Please keep the random linker options in alphabetical order (modulo
'Z' and 'no' prefixes).  Options that can only go to one of libtool
or ld must be listed twice, under both !Zdynamiclib and
Zdynamiclib, with one of the cases reporting an error.  */
/* Note that options taking arguments may appear multiple times on a
command line with different arguments each time, so put a * after


However, once you make that change:
alias:/tmp ssen$ /opt/gccmath-bootstrap/bin/gcc -o test test.c -msselibm
symbol ___isinf used from dynamic library /usr/lib/libSystem.dylib 
(xmm_misc.o) not from earlier dynamic library /opt/gccmath-bootstrap/ 
lib/libgcc-math.0.dylib(libsse2_la-s_isinf.o)
symbol ___isinff used from dynamic library /usr/lib/libSystem.dylib 
(xmm_misc.o) not from earlier dynamic library /opt/gccmath-bootstrap/ 
lib/libgcc-math.0.dylib(libsse2_la-s_isinff.o)
/usr/bin/ld: warning suggest use of -bind_at_load, as lazy binding  
may result in errors or different symbols being used

alias:/tmp ssen$

Is it intentional that these functions have global visibility and  
interfere with functions declared and implemented by the system  
libraries? If not, can they be compilied with hidden visibility?


Shantonu

Re: x86 Darwin an libgcc-math

[Shantonu Sen]

Awesome.

With trunk, your 3 previous patches, my config/darwin.h patch for the  
link line, and your further patch for visibility:


[EMAIL PROTECTED] /opt/gccmath/bin/gcc -o test test.c -msselibm
[EMAIL PROTECTED] otool -Lv test
test:
/opt/gccmath/lib/libgcc-math.0.dylib (compatibility version  
1.0.0, current version 1.0.0)

time stamp 1138831883 Wed Feb  1 14:11:23 2006
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,  
current version 88.1.5)

time stamp 1137810491 Fri Jan 20 18:28:11 2006
[EMAIL PROTECTED] ./test
0.999816

Also, using nm I see that only the intentional support API is global.

[EMAIL PROTECTED] nm -g -f /opt/gccmath/lib/libgcc-math.0.dylib | grep -v  
" U "

33a0 T ___libm_sse2_acos
3080 T ___libm_sse2_acosf
4460 T ___libm_sse2_asin
5580 T ___libm_sse2_asinf
000139a0 T ___libm_sse2_atan
5a40 T ___libm_sse2_atan2
a6c0 T ___libm_sse2_atan2f
00017660 T ___libm_sse2_cos
00015f80 T ___libm_sse2_cosf
add0 T ___libm_sse2_exp
b250 T ___libm_sse2_expf
ce90 T ___libm_sse2_log10
cfc0 T ___libm_sse2_log10f
e4b0 T ___libm_sse2_powf
00018a30 T ___libm_sse2_sin
0001acb0 T ___libm_sse2_sinf
0001adf0 T ___libm_sse2_tan
00021270 T ___libm_sse2_tanf
[EMAIL PROTECTED]

Thank you very much! Bootstrapped on i386-apple-darwin8.4.1

Shantonu

On Feb 1, 2006, at 1:10 PM, Richard Guenther wrote:



Can you try the attached patch (it's not perfect as it misses to  
export some
of the symbols due to the simple #define hack not working for them)  
and

see if in principle it would solve the issue on Darwin?

Thanks,
Richard.

Inconsistency in runtime target tool search

[Shantonu Sen]

When I build a cross compiler, say from x86_64-unknown-linux-gnu to  
i386-apple-darwin8.4.1, and have a directory in my PATH with "i386- 
apple-darwin8.4.1-as" and "i386-apple-darwin8.4.1-ld", it appears  
that the target-prefixed "ld" is found by collect2, but not the  
target-prefixed "as" by the driver.



[EMAIL PROTECTED]:/tmp$ type i386-apple-darwin8.4.1-as
i386-apple-darwin8.4.1-as is /opt/odcctools/bin/i386-apple- 
darwin8.4.1-as

[EMAIL PROTECTED]:/tmp$ type i386-apple-darwin8.4.1-ld
i386-apple-darwin8.4.1-ld is /opt/odcctools/bin/i386-apple- 
darwin8.4.1-ld

[EMAIL PROTECTED]:/tmp$

[EMAIL PROTECTED]:/tmp$ i386-apple-darwin8.4.1-gcc -v -c test.c
Using built-in specs.
Target: i386-apple-darwin8.4.1
Configured with: ../gcc/configure --prefix=/opt/gcc-darwin -- 
target=i386-apple-darwin8.4.1 --with-sysroot=/MacOSX10.4u.sdk -- 
disable-libgomp --disable-libssp --disable-libgcc-math

Thread model: posix
gcc version 4.2.0 20060202 (experimental)
...
 as -arch i386 -force_cpusubtype_ALL -o test.o /tmp/ccqadIjw.s
Assembler messages:
Fatal error: invalid listing option `r'
[EMAIL PROTECTED]:/tmp$


My expectation here was that since this is a cross-compiler built  
with --target=i386-apple-darwin8.4.1, the driver would look for the  
assembler as "i386-apple-darwin8.4.1-as" if it wasn't found in any of  
the normal tool directories in $prefix/libexec/gcc or $prefix/ 
$target, etc. This does not seem to be the case, and a Linux ELF  
assembler doesn't do me a lot of good. Note that I did not use --with- 
ld/--with-as explicitly during configuration, so I expect directories  
and paths to be searched at runtime.


However, what I find confusing is that collect2 implements the  
algorithm as I expected it to:



[EMAIL PROTECTED]:/tmp$ i386-apple-darwin8.4.1-gcc -S test.c
[EMAIL PROTECTED]:/tmp$ i386-apple-darwin8.4.1-as -arch i386 - 
force_cpusubtype_ALL -o test.o test.s

[EMAIL PROTECTED]:/tmp$ i386-apple-darwin8.4.1-gcc -o test test.o -Wl,-v
collect2 version 4.2.0 20060202 (experimental) (i686 Darwin)
/opt/odcctools/bin/i386-apple-darwin8.4.1-ld -dynamic -arch i386 - 
weak_reference_mismatches non-weak -o test -lcrt1.o -L/opt/gcc- 
darwin/lib/gcc/i386-apple-darwin8.4.1/4.2.0 -L/opt/gcc-darwin/lib/ 
gcc/i386-apple-darwin8.4.1/4.2.0/../../../../i386-apple-darwin8.4.1/ 
lib -L/MacOSX10.4u.sdk/usr/lib test.o -v -lgcc -lSystem

Apple Computer, Inc. version odcctools-590.18od10
[EMAIL PROTECTED]:/tmp$


This seems to be because collect2.c has:
#ifdef CROSS_COMPILE
  /* If we look for a program in the compiler directories, we just use
 the short name, since these directories are already system- 
specific.

 But it we look for a program in the system directories, we need to
 qualify the program name with the target machine.  */

  const char *const full_ld_suffix =
concat(target_machine, "-", ld_suffix, NULL);


Now, my question is, why does collect2 implement its target tool  
search by prefixing the target name, but the driver itself doesn't  
when invoking the assembler? Should I file a bug to align all the  
code that searches for target tools?


As an aside, the cross compiler successfully builds and links target  
libraries because it uses:

[EMAIL PROTECTED]:~/gcc-build$ cat gcc/as
#!/bin/sh
exec /opt/odcctools/bin/i386-apple-darwin8.4.1-as "$@"
[EMAIL PROTECTED]:~/gcc-build$ cat gcc/collect-ld
#!/bin/sh
exec /opt/odcctools/bin/i386-apple-darwin8.4.1-ld "$@"
[EMAIL PROTECTED]:~/gcc-build$


I guess I'm asking for the driver to have parity with gcc's build  
system, which prepends the target name for these tools


Shantonu

Re: Results for 4.2.0 20060320 (experimental) testsuite on powerpc-apple-darwin8.5.0 (-m64 results)

[Shantonu Sen]

On Mar 21, 2006, at 12:34 PM, Bradley Lucier wrote:

I'm curious about whether any of the changes recently proposed to  
clean up the x86-darwin port can be applied to the 64-bit PowerPC  
darwin compiler;


Like what? I haven't really seen many cleanups that were x86/darwin- 
specific


I'm getting the feeling that gcc on ppc64 darwin may become  
something of an orphan.


Note sure what you mean here, but these ppc64 results are no worse  
than the ppc(32) results for Darwin. Did you look at the failures?


For example, here's your results:
=== g++ Summary ===

# of expected passes10807
# of unexpected failures1287
# of expected failures  67
# of unresolved testcases   14
# of unsupported tests  126

=== libstdc++ Summary ===

# of expected passes355
# of unexpected failures1576
# of expected failures  7
# of unsupported tests  323

And here's my results, on 10.4.3 with CVS odcctools (which has  
cctools-590.36/ld64-26.0.81)

=== g++ Summary ===

# of expected passes9814
# of unexpected failures1406
# of expected failures  65
# of unresolved testcases   77
# of unsupported tests  124

=== libstdc++ Summary ===

# of expected passes354
# of unexpected failures1589
# of expected failures  7
# of unsupported tests  323


This should inspire you with confidence that ppc32-darwin is as bad,  
if not worse, than ppc64-darwin. Many of the c++ failures are of the  
form:

/opt/odcctools/bin/ld: Undefined symbols:
__Unwind_GetIPInfo
collect2: ld returned 1 exit status

A fix for this was posted by Eric C. (), but never committed. Someone will  
have to decide Real Soon Now what the expected binary compatibility  
of GCC trunk vs. Mac OS X's libgcc should/will be. Andrew has filed  
this as 


What is the prior art for other OS vendors that ship a shared libgcc?

Shantonu

Re: [patch] fix c++ on darwin

[Shantonu Sen]

Yes, I set that. That's the goal, using new features available in Mac  
OS X 10.4 and creating binaries that are compatible with a stock 10.4  
system.


Shantonu

On Apr 14, 2006, at 10:13 AM, Eric Christopher wrote:



On Apr 14, 2006, at 8:29 AM, Shantonu Sen wrote:


(Moving to gcc@)

Eric, when will this be resolved? It's been over a month, and test  
suite results still are horrible


I had MACOSX_DEPLOYMENT_TARGET set in my environment, when I removed  
that everything worked just fine for me... I can test again if  
you're still seeing it. (You'd be the second report)


-eric

Re: detecting non-PIC in shared lib on Darwin?

[Shantonu Sen]

Andrew is referring to the following:
[EMAIL PROTECTED] cat foo.c
extern int a;
int foo(void) { return a; }
[EMAIL PROTECTED] cat bar.c
int a = 1;
[EMAIL PROTECTED] cc -mdynamic-no-pic -c foo.c -arch ppc
[EMAIL PROTECTED] cc -mdynamic-no-pic -c bar.c -arch ppc
[EMAIL PROTECTED] cc -dynamiclib -o libfoo.dylib foo.o bar.o -arch ppc
ld: foo.o has local relocation entries in non-writable section  
(__TEXT,__text)

/usr/bin/libtool: internal link edit command failed
[EMAIL PROTECTED]

Instead of going through stubs in the data segment, -mdynamic-no-pic  
puts relocations directly in the text segment on the assumption that  
the final linked image will be an executable at a fixed address and  
the relocations will be resolved to absolute addresses. If you do the  
same experiment with -arch ppc64, you will not get a static linker  
error, but instead the program will crash at runtime. Some may  
consider that a bug that should be reported to Apple.


I don't believe there's a general way of detecting non-dylib-safe  
object files, except trying to link it into a dylib and see if it  
fails (for ppc32)


Shantonu

On Apr 26, 2006, at 6:45 PM, Jack Howarth wrote:


Andrew,
What on earth would make you think that the linker on Darwin would
reject non-PIC code in linking a shared library. The linker on Linux
doesn't do any such thing (hence the discussion on the Debian mailing
list of adopting this as check on their builds).

http://lists.debian.org/debian-gcc/2003/10/msg00115.html

 Jack

Re: 4.2 hasn't bootstrapped on powerpc-apple-darwin G5 machine for a very long time

[Shantonu Sen]

Because it's hardcoded in the original darwin.h to something else, and  
the right one does not get detected during configuration.


Why must you use libtool from the same source as ld? Because libtool  
has binary detection logic, and an old version can reject object files  
with new load commands or new architectures, like ppc64 on a 10.3  
system.


Shantonu

On May 9, 2006, at 12:37 PM, Bradley Lucier wrote:



On May 3, 2006, at 7:50 PM, David Fang wrote:


FWIW, the 20060415 mainline (4.2) snapshot bootstrapped for me, using
odcctools-20060413 (odcctools-590.36od13).  This machine is a dual G5
(ppc970) using OS X 10.3.9, and Apple's gcc-3.3 (build 1640).

However, before building, I patched the following 2 files:
In gcc/config/darwin.h:
at: #define LINK_COMMAND_SPEC :
replace:/usr/bin/libtool
with:   /path/to/odcctools/bin/libtool


Thanks.  Is there any reason to hardwire which version of libtool to  
use?


Brad

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?

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


With MACOSX_DEPLOYMENT_TARGET=10.4 set:



The thousands of failures are because of ,  
which is diligently being pursued by [EMAIL PROTECTED]  
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: libgfortran build broken on Darwin ppc

[Shantonu Sen]

That's not correct. The linker support only exists in ld64 for Xcode  
2.4. It fails like this for ld(32). 32-bit Darwin targets shouldn't be  
using this assembly feature...


Shantonu

On Sep 9, 2006, at 12:16 PM, Eric Christopher wrote:



Using the cctools from Xcode 2.4, the failure changes and moves to  
the linkage

of libgfortran itself...
ld: .libs/maxloc0_4_r16.o unknown flags (type) of section 2  
(__TEXT,__literal16) in load command 0
ld: .libs/maxloc0_8_r16.o unknown flags (type) of section 2  
(__TEXT,__literal16) in load command 0
ld: .libs/maxloc1_4_r16.o unknown flags (type) of section 2  
(__TEXT,__literal16) in load command 0
ld: .libs/maxloc1_8_r16.o unknown flags (type) of section 2  
(__TEXT,__literal16) in load command 0
ld: .libs/maxval_r16.o unknown flags (type) of section 2  
(__TEXT,__literal16) in load command 0
ld: .libs/minloc0_4_r16.o unknown flags (type) of section 2  
(__TEXT,__literal16) in load command 0
ld: .libs/minloc0_8_r16.o unknown flags (type) of section 2  
(__TEXT,__literal16) in load command 0
ld: .libs/minloc1_4_r16.o unknown flags (type) of section 2  
(__TEXT,__literal16) in load command 0
ld: .libs/minloc1_8_r16.o unknown flags (type) of section 2  
(__TEXT,__literal16) in load command 0
ld: .libs/minval_r16.o unknown flags (type) of section 2  
(__TEXT,__literal16) in load command 0
ld: .libs/write.o unknown flags (type) of section 4  
(__TEXT,__literal16) in load command 0

/usr/bin/libtool: internal link edit command failed
So if there is a usable cctools, it doesn't exist outside of Apple.  
I wonder if
the literal16 patch was meant for Darwin intel only as I understand  
they don't

use stabs, etc at the moment.


No, it was meant for everything, it might only work with the cctools  
that was handed out at WWDC though. I've been looking around and  
can't find them though. I'll keep you updated.


-eric