Duplicate Thread Code Symbols in Xcode iPhone Demo builds

View: New views
2 Messages — Rating Filter:   Alert me  

Duplicate Thread Code Symbols in Xcode iPhone Demo builds

by pkouame :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Some parts of this message have been removed. Learn more about Nabble's security policy.
Hi -

First the good news: Finally got Snow+SDK3.1.2 to build demos on device with SDL1.3-5157. All looks great!

It was all working well on sim per my previous post, but I ran into problems on device builds with EXC_BAD_ACCESS in uikitopenglview:InitFrame.
There is a previous thread suggesting optimization flags were the culprit. I did not find that to be the case, I tested them all and the poster was
building for SDK2.X.
Drove me crazy following red herrings with compiler options and flags. I finally noticed that -all_load was not specified in the demo template. Once activated
the linker immediately caught a duplicate symbol in the threading code. Low and behold both the generic and pthread code files are being built,hence
duplicate symbols galore.

First, I strongly suggest folks switch the -all_load Linker flag on in Xcode for static libs you are trying to debug. And make sure debug
symbols info is on for all symbols and types (-gfull) Otherwise the linker is on half a brain and gcc gets confused, making things hard to trace.

Second, for some reason building the demos against SDK3.0 work fine (device and sim) without tweaks. I have yet to absorb that one.

Third, question, shouldn't the generic and pthread code be merged with conditionals? I disabled the generic thread code group in the IDE to eliminate
the redundant symbols, but that is obviously not the solution. Xcode leaves a lot to be desired in the way of smart(er) build controls (or at least it's overly
complex and I'm not the Xcode wizard I want to be). One can manipulate what a target is composed of, but in this case I see no other way but a code patch. Or
is this a config issue I am missing all together? What do you think?

I realize this is a work in progress - hopes this helps...

Keep up the good work, Patrice Kouame

_______________________________________________
SDL mailing list
SDL@...
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Re: Duplicate Thread Code Symbols in Xcode iPhone Demo builds

by Sam Lantinga-4 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Thanks for the info!

The generic code shouldn't have been in there, I removed it from the project.

I also applied Roger's fix from bug 847, this appears to work just fine.

See ya!

On Fri, Oct 30, 2009 at 2:18 AM, pkouame <patrice.kouame@...> wrote:

> Hi -
>
> First the good news: Finally got Snow+SDK3.1.2 to build demos on device with
> SDL1.3-5157. All looks great!
>
> It was all working well on sim per my previous post, but I ran into problems
> on device builds with EXC_BAD_ACCESS in uikitopenglview:InitFrame.
> There is a previous thread suggesting optimization flags were the culprit. I
> did not find that to be the case, I tested them all and the poster was
> building for SDK2.X.
> Drove me crazy following red herrings with compiler options and flags. I
> finally noticed that -all_load was not specified in the demo template. Once
> activated
> the linker immediately caught a duplicate symbol in the threading code. Low
> and behold both the generic and pthread code files are being built,hence
> duplicate symbols galore.
>
> First, I strongly suggest folks switch the -all_load Linker flag on in Xcode
> for static libs you are trying to debug. And make sure debug
> symbols info is on for all symbols and types (-gfull) Otherwise the linker
> is on half a brain and gcc gets confused, making things hard to trace.
>
> Second, for some reason building the demos against SDK3.0 work fine (device
> and sim) without tweaks. I have yet to absorb that one.
>
> Third, question, shouldn't the generic and pthread code be merged with
> conditionals? I disabled the generic thread code group in the IDE to
> eliminate
> the redundant symbols, but that is obviously not the solution. Xcode leaves
> a lot to be desired in the way of smart(er) build controls (or at least it's
> overly
> complex and I'm not the Xcode wizard I want to be). One can manipulate what
> a target is composed of, but in this case I see no other way but a code
> patch. Or
> is this a config issue I am missing all together? What do you think?
>
> I realize this is a work in progress - hopes this helps...
>
> Keep up the good work, Patrice Kouame
> _______________________________________________
> SDL mailing list
> SDL@...
> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>
>



--
        -Sam Lantinga, Founder and President, Galaxy Gameworks LLC
_______________________________________________
SDL mailing list
SDL@...
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org