Open GoogleCodeExporter opened 8 years ago
I get exactly the same issue. I tried several things but I couldn't find a
working fix yet. It is not related to the
method in Proj4 but to any method defined there.
It seems to be an issue with static linking over 2 levels or so.
Original comment by fbutt...@googlemail.com
on 12 Apr 2010 at 6:13
I fixed it. The problem was, that I used the linker flag "-all_load" because I
am also using three20. After
removing that flag, my application works fine again. I guess the bug can be set
to INVALID.
Original comment by fbutt...@googlemail.com
on 14 Apr 2010 at 1:04
Is there anyway to make this work with -all_load? I need it for a closed source
framework I'm using.
Original comment by rat...@gmail.com
on 17 Apr 2010 at 12:35
I also cannot work without the -all_load flag. I use libraries that depend on
it.
Original comment by kuzm...@gmail.com
on 18 Apr 2010 at 2:55
It appears that the compiler has issues will all c functions. This would
suggest a bug with the compiler. The
workaround is to make all of the functions inline. This worked fine for
aasincos. The rest of the files need to be
updated. A job that I am not looking forward to.
Original comment by kuzm...@gmail.com
on 18 Apr 2010 at 4:16
Was there ever a better work around for this found?
Original comment by rat...@gmail.com
on 26 May 2010 at 11:11
This also happens with 3.2, not just 4.0
Original comment by BitcaB...@gmail.com
on 11 Jun 2010 at 1:54
[deleted comment]
I also need it working with the -all_load flag for several frameworks. Does
anyone have any ideas on how to get this fixed.
Original comment by shaun.me...@gmail.com
on 22 Jun 2010 at 1:28
I would very much like it if this issue would be resolved, of if somebody would
publish a work around for this.
Is the suggestion made by kuzmycz a possibility?
What if this 'making the function inline' could be done for just aasin and
aacos ... would that be enough?
Original comment by wou...@human-software.nl
on 22 Jun 2010 at 1:40
If this is a bug in the compiler ... did anybody file a bug report @ apple?
Original comment by wou...@human-software.nl
on 22 Jun 2010 at 1:41
Can we bump this to a higher priority?
It seems to me that 'unable to build with the current SDK version' deserves a
higher priority than 'Medium'.
Original comment by wou...@human-software.nl
on 22 Jun 2010 at 2:17
Same problem here, would love to see a solution for this...
Original comment by herman.m...@gmail.com
on 22 Jun 2010 at 2:27
I had the same problem using route-me with CorePlot.
As a workaround for using -all_load you can use -force_load
{path_to_external_lib}
Sample: "-force_load
/Users/myname/Projects/ThirdParty/core-plot/framework/build/Release-iphoneos/lib
CorePlot-CocoaTouch.a"
Original comment by vladimir...@gmail.com
on 22 Jun 2010 at 7:57
Well the force_load was not an option for me but I have found the issue. It is
a bug in the libtool which is described here:
http://blog.binaryfinery.com/?p=225#more-225 . I'm working on a workaround...
Original comment by herman.m...@gmail.com
on 23 Jun 2010 at 10:04
This is also a serious problem for me. I have tried a number of things to fix
it, but with no success. The -force_load suggestion seems to work for me when
debugging on the device, but when it comes time to build, I get new errors
related to the three20 framework I'm using.
I need the -all_load flag because of this three20 library, and I imagine others
need it for a similar reason. Although I'm trying to find a way to get the
three20 library to run without this flag, it would be great if there were any
further suggestions on how to fix this problem so that it will work with
-all_load if necessary.
Original comment by emailfor...@yahoo.com.au
on 24 Jun 2010 at 11:49
Confirm this issue as well. Also cannot remove -all_load due to using three20
in the same project
Original comment by Clarke...@gmail.com
on 27 Jun 2010 at 1:44
have worked around the problem by setting my project and all libraries used to
compile in armv6 only.
Original comment by Clarke...@gmail.com
on 27 Jun 2010 at 10:31
If somebody can create a detailed and to-the-point description of the problem
... and if it is a bug in Xcode, can he/she create a bug report @
bugreporter.apple.com ?
Original comment by wou...@human-software.nl
on 28 Jun 2010 at 7:20
Well I must have solved this problem at some point when getting things working
on 4.0. One of the things I did was link proj4 directly into our main project,
instead of via route-me. Static lib including a static lib problem iirc. One of
the changes 4.0 introduced was switching what architectures built by default,
so you'll need to go through all your projects and make sure you're building
armv6 & armv7 as needed. We link in half a dozen static libs or so, and are
definitely using -all_load still.
Original comment by erik.scr...@gmail.com
on 22 Jul 2010 at 10:40
Expanding on my previous comment:
I believe the problem was proj4 switched from armv6 to armv6&armv7. Both armv6
& armv7 versions on libMapView.a were including armv6&armv7 version of
libproj4.a. When linking in all symbols (-all_load), you get dupes. This looks
like a limitation of including a .a inside a .a, and is generally not a good
idea. So there ought to be two potential fixes:
1) switch proj4 to be armv6 only. This is how it was before switching to sdk4.
Not optimized, but avoids dupe symbols.
2) link to libProj4.a directly in your main project, and remove it from
MapView. This lets you use armv6&armv7 for proj4.
Original comment by erik.scr...@gmail.com
on 22 Jul 2010 at 10:53
use just armv6 and delete key -all_load im resolved this
problem
Original comment by sngg...@gmail.com
on 18 Aug 2010 at 12:34
Add the following script to the map view library build. It removes the
duplicate symbols.
--
#!/bin/bash
# (c) 2010 James Briant, binaryfinery.com
# Edited by Pierre de La Morinerie
if [[ $TARGET_BUILD_DIR == *iphoneos* ]] && [[ $ARCHS == *\ * ]]
then
echo "Rebuilding library as proper multiarch file"
LIB_ARM6=$TEMP_FILES_DIR/Objects-$BUILD_VARIANTS/armv6/$EXECUTABLE_NAME
LIB_ARM7=$TEMP_FILES_DIR/Objects-$BUILD_VARIANTS/armv7/$EXECUTABLE_NAME
# Libtool skrewed up, and built fat binaries in place of the arch-specific ones
: strip them.
lipo $LIB_ARM6 -remove armv7 -o $LIB_ARM6
lipo $LIB_ARM7 -remove armv6 -o $LIB_ARM7
# Now recombine the stripped lib to the final product
libtool -static $LIB_ARM6 $LIB_ARM7 -o $BUILT_PRODUCTS_DIR/$EXECUTABLE_NAME
else
echo "Skipping arm multi-architecture rebuild"
fi
Original comment by kuzm...@gmail.com
on 19 Aug 2010 at 1:41
Could you specify exactly where this script file has to be inserted? thx
Original comment by fmau...@gmail.com
on 13 Sep 2010 at 10:14
Original issue reported on code.google.com by
kuzm...@gmail.com
on 10 Apr 2010 at 8:24