Dave Vasilevsky <[EMAIL PROTECTED]> wrote:
> Ok guys, I've talked with msachs some and apparently this actually
> works for him:
>
> (Panther) make clean; make CC_LIB=g++ libbreak.dylib(Tiger) make
> CC=g++-3.3
>
> Previously drm said this didn't work, so I'd like some more testing.
> H
On Apr 19, 2005, at 1:12 AM, Matthew Sachs wrote:
In further testing, however, it seems that it also works with g++-3.3
on Tiger and no -fabi-version on Panther without the SDK. I've asked
my coworkers for clarification on why we should be using the SDK in
this situation.
Ok guys, I've talked w
On Apr 18, 2005, at 20:41, Matthew Sachs wrote:
Panther:
g++ -c lib.cpp -fabi-version=1 -o lib.o
g++ -dynamiclib -fabi-version=1 -o libbreak.dylib lib.o
Tiger:
g++-3.3 -isystem /Developer/SDKs/MacOSX10.3.9.sdk/usr/include/
gcc/darwin/3.3 -isystem /Developer/SDKs/MacOSX10.3.9.sdk/usr/
On Apr 18, 2005, at 6:21 PM, TheSin wrote:
if upgrading from 10.3 -> 10.4 will will need to set abi-version to 0
I'm not sure but I think this will work.
I strongly suspect this will not work. -fabi-version=0 is equivalent to
-fabi-version=. So on
g++-3.3 it's like 1, and on gcc 4 it's like 2.
On Apr 19, 2005, at 12:09 AM, Peter O'Gorman wrote:
Ah, how silly of me, of course I need to specify g++-3.3 on tiger.
That or pass -fabi-version=1. Sorry for the confusion! My intro to this
kinda sucked before, so according to what we know now, these are some
examples of what should work and wha
Matthew Sachs wrote:
Okay, the following works:
Panther:
g++ -c lib.cpp -fabi-version=1 -o lib.o
g++ -dynamiclib -fabi-version=1 -o libbreak.dylib lib.o
Tiger:
g++-3.3 -isystem /Developer/SDKs/MacOSX10.3.9.sdk/usr/include/
gcc/darwin/3.3 -isystem /Developer/SDKs/MacOSX10.3.9.sdk/usr/i
On Apr 18, 2005, at 21:03, Benjamin Reed wrote:
Matthew Sachs wrote:
Okay, the following works:
Panther:
g++ -c lib.cpp -fabi-version=1 -o lib.o
g++ -dynamiclib -fabi-version=1 -o libbreak.dylib lib.o
I'm confused... What good is this? Thousands upon thousands of
fink users already have
Ouch.I'm afraid this is mostly over my head, but if there's specific feedback (other than documenting -fabi-version) that comes up when this is all sorted out, please let me know.Yours,- Ernie P.On Apr 18, 2005, at 3:21 PM, TheSin wrote:it would seem that we will need a two way update to me. Kinda
Matthew Sachs wrote:
Okay, the following works:
Panther:
g++ -c lib.cpp -fabi-version=1 -o lib.o
g++ -dynamiclib -fabi-version=1 -o libbreak.dylib lib.o
I'm confused... What good is this? Thousands upon thousands of fink
users already have pre-existing binaries that were built without
-
Okay, the following works:
Panther:
g++ -c lib.cpp -fabi-version=1 -o lib.o
g++ -dynamiclib -fabi-version=1 -o libbreak.dylib lib.o
Tiger:
g++-3.3 -isystem /Developer/SDKs/MacOSX10.3.9.sdk/usr/include/
gcc/darwin/3.3 -isystem /Developer/SDKs/MacOSX10.3.9.sdk/usr/include -
c -o break.
Please explain!
Your 3.3-built object files weren't build with ABI version 1. The
following works:
Panther:
breakgcc$ g++ -c lib.cpp -fabi-version=1 -o lib.o
breakgcc$ g++ -dynamiclib -fabi-version=1 -o libbreak.dylib lib.o
Tiger:
breakgcc$ g++ -fabi-version=1 -o break break.o libbr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dave Vasilevsky wrote:
| I suspect that the non-Apple-guaranteed probability of them working
| together all the time very closely approaches 1. I wrote a very small
| test case for the RTTI issue, it's at
| http://vasi.webhop.org/files/misc/breakgcc.tgz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Matthew Sachs wrote:
| On Apr 18, 2005, at 10:36, Jean-François Mertens wrote:
|
|> Are we sure that mixing things compiled with 'g++-3.3' on panther and
|> on tiger has no problems ?
|
|
| I got an answer on this; you'll need to use the 10.3.9 SDK for
it would seem that we will need a two way update to me. Kinda like what we had. But the second stage WILL need a clean install.if upgrading from 10.3 -> 10.4 will will need to set abi-version to 0 I'm not sure but I think this will work.10.4-transitional treeFor new installs lets use the 10.4 tr
On Apr 18, 2005, at 5:47 PM, David R. Morrison wrote:
On Apr 18, 2005, at 4:52 PM, David R. Morrison wrote:
On Apr 18, 2005, at 2:53 PM, Matthew Sachs wrote:
I got word that the default for -fabi-version in 3.3 is -1, for
compatibility with 3.1. So that explains why you can't link
-fabi-version=
On Apr 18, 2005, at 4:52 PM, David R. Morrison wrote:
On Apr 18, 2005, at 2:53 PM, Matthew Sachs wrote:
I got word that the default for -fabi-version in 3.3 is -1, for
compatibility with 3.1. So that explains why you can't link
-fabi-version=1 packages with 3.3-built default ABI packages.
It's
On Apr 18, 2005, at 2:53 PM, Matthew Sachs wrote:
I got word that the default for -fabi-version in 3.3 is -1, for
compatibility with 3.1. So that explains why you can't link
-fabi-version=1 packages with 3.3-built default ABI packages.
It's really infuriating that this wasn't documented. The m
On Apr 18, 2005, at 2:53 PM, Matthew Sachs wrote:
I got word that the default for -fabi-version in 3.3 is -1, for
compatibility with 3.1. So that explains why you can't link
-fabi-version=1 packages with 3.3-built default ABI packages.
Code is here:
http://www.opensource.apple.com/darwinsour
On Apr 18, 2005, at 14:50, David R. Morrison wrote:
I don't think the SDK compatibility things are the way to go for
us. If
we do this, we'll be stuck with 10.3 compatibility mode forever,
right?
It just means that you can't link SDK-built C++ packages with non-SDK
C++ packages. However, th
I don't think the SDK compatibility things are the way to go for us. If
we do this, we'll be stuck with 10.3 compatibility mode forever, right?
We may just have to make a clean break; perhaps we can put something like
Conflicts: macos (<< 10.4)
into fink itself on 10.4? This would stop people
On Apr 18, 2005, at 14:39, TheSin wrote:
in front of -I/sw/include ?? Just want to make sure it'll be
higher in the search order then usr/include and stuff so we don't
get things all mixed up. Thanks to RangerRick's SDK virts we
should be able to enforce this.
Here's a full example, courtes
in front of -I/sw/include ?? Just want to make sure it'll be higher in the search order then usr/include and stuff so we don't get things all mixed up. Thanks to RangerRick's SDK virts we should be able to enforce this. ---TShttp://southofheaven.org/Chaos is the beginning and end, try dealing wit
On Apr 18, 2005, at 10:36, Jean-François Mertens wrote:
Are we sure that mixing things compiled with 'g++-3.3' on panther
and on tiger has no problems ?
I got an answer on this; you'll need to use the 10.3.9 SDK for this
to be guaranteed to work.
---
On Apr 18, 2005, at 12:56, Jean-François Mertens wrote:
Thanks !
But I think we are more concerned about the possbility
for users having switched to tiger to continue using some
of their old binaries build on panther (and even building
further on them) . To quote :
Running Panther-built packages o
On 18 Apr 2005, at 18:44, Matthew Sachs wrote:
We have an "SDK" feature that can be used to guarantee that
something built on a new OS can be deployed on an older OS. To
use this from the command line, add:
-isysroot /Developer/SDKs/MacOSX10.3.9.sdk
Sorry, make that:
-isysroot /Develop
On Apr 18, 2005, at 12:35, Matthew Sachs wrote:
We have an "SDK" feature that can be used to guarantee that
something built on a new OS can be deployed on an older OS. To use
this from the command line, add:
-isysroot /Developer/SDKs/MacOSX10.3.9.sdk
Sorry, make that:
-isysroot /Develo
On Apr 18, 2005, at 08:20, David R. Morrison wrote:
However, this discovery leaves us completely without a strategy for
the Tiger upgrade. The only one I can imagine at the moment is to
force users to run gcc_select=3.3 when running under the 10.4-
transitional tree, and later having them run
On Apr 18, 2005, at 10:36, Jean-François Mertens wrote:
Are we sure that mixing things compiled with 'g++-3.3' on panther
and on tiger has no problems ?
I've asked my coworkers for more information on this. However, if it
turns out there are compatibility issues, we have a way to fix them.
We
On 18 Apr 2005, at 15:52, David R. Morrison wrote:
We were trying to design a system in which users could continue to
use things they had already compiled under 10.3 and combine them
with new things.
On 18 Apr 2005, at 15:58, Peter O'Gorman wrote:
On 18 Apr 2005, at 15:04, Peter O'Gorman wrote:
Jean-François Mertens wrote:
On 18 Apr 2005, at 15:04, Peter O'Gorman wrote:
The only thing I can suggest is having a %p/lib/fink/override/
/bin/g++
and gcc and cc,c++ as symlinks to g++-3.3 and gcc-3.3 etc and fink
ensuring
that %p/lib/fink/override//bin/ comes first in $PATH when
building st
Let me explain the situation as I understand it.
First, we cannot mix g++ compiles between gcc-3.3 and gcc-4.0 because
of the ABI difference.
We thought (following the documentation) that setting -fabi-version=1
would solve this. In fact, it does solve it quite nicely: if you build
everything
On 18 Apr 2005, at 15:04, Peter O'Gorman wrote:
The only thing I can suggest is having a %p/lib/fink/override/
/bin/g++
and gcc and cc,c++ as symlinks to g++-3.3 and gcc-3.3 etc and fink
ensuring
that %p/lib/fink/override//bin/ comes first in $PATH when
building stuff.
not sure I understand we
On 2005-04-18, David R. Morrison wrote:
> Hi Martin.
>
> I had been very puzzled by those missing symbol problems, so I'm glad
> you figured it out. The timing is excellent, because we haven't pushed
> -fabi-version=1 into stable yet, or fully committed ourselves to the
> Tiger upgrade strateg
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David R. Morrison wrote:
| However, this discovery leaves us completely without a strategy for the
| Tiger upgrade. The only one I can imagine at the moment is to force
| users to run gcc_select=3.3 when running under the 10.4-transitional
| tree, and
this seems to be the same problem for xdrawchem in unstable that I can't figure out. ---TShttp://southofheaven.org/Chaos is the beginning and end, try dealing with the rest. On 18-Apr-05, at 6:20 AM, David R. Morrison wrote:Hi Martin.I had been very puzzled by those missing symbol problems, so I'm
Hi Martin.
I had been very puzzled by those missing symbol problems, so I'm glad
you figured it out. The timing is excellent, because we haven't pushed
-fabi-version=1 into stable yet, or fully committed ourselves to the
Tiger upgrade strategy which uses it.
However, this discovery leaves us c
36 matches
Mail list logo
