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
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
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
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:
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.
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
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
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
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
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
:
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
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
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?
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
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
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,
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
%
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
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,
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
20 matches
Mail list logo
