Sounds like a good idea, but so far I haven't been able to make this work.
Normally our operators are provided in a dylib. I can suppress the symbol export at this level but this is going to cause the application proper to link against the OS operators when inlining fails.
To work around this I tried adding out-of-line versions of the operators to the application project (duplicating those in the dylib) however I'm not able to do this with the precompiled header used in my application project. Xcode doesn't appear to allow disabling precompiled headers on a specific file (anyone know a trick for this?) and I can't disable them on the entire project for other reasons.
I also tried creating a small static library which contained the out-of-line operators, and linking that into the application. Unfortunately this doesn't appear to be working either - the linker complains that the symbols in the application's unexported_symbols_list are not present (even though 'nm' shows them as being exported from the static library.)
Any further thoughts on this issue?
thx,
chris
(For reference, both PPC and x86 are using apple gcc 4.0.1.)
On Thursday, May 04, 2006, at 00:59AM, Epard, Marc <email@hidden> wrote:
>
><<Original Attached>>
Title: Re: problem with operator new
on 5/3/06 3:29 AM, Chris Bergmann wrote:
> I¹m having a problem with an overridden global-scope operator new on
> the intel macs. It appears that a different link order is used on the
> intel macs (both natively and in rosetta) than what is used on the
> powerpc. The result of this is that the OS libraries are sometimes
> using our overridden operator new, causing a crash when the version
> of Œnew¹ and Œdelete¹ used don¹t match.
We encountered the same problem and a colleague worked around it with the
UNEXPORTED_SYMBOLS_FILE build setting. We specify a file we call
Unexported.txt which contains the list of entry points below. We set
UNEXPORTED_SYMBOLS_FILE on each target that produces an executable and links
to our static library that contains operator new and delete.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/xcode-users/email@hidden
This email sent to email@hidden
