devernay / xcodelegacy

Legacy components for XCode 4-12 (deprecated compilers and Mac OS X SDKs)
https://github.com/devernay/xcodelegacy
470 stars 63 forks source link

Link Time Optimization in XCode 8 creates problems #30

Closed gghose closed 7 years ago

gghose commented 7 years ago

Similar to the deduplicate there seems to be flags introduced by default that the ppc linker doesn't understand.

Running ld for ppc ...ld: unknown option: -object_path_lto collect2: ld returned 1 exit status

If you manually edit the link command and eliminate this option and the lto one that follows it, it does successfully link.

devernay commented 7 years ago

hope we find a solution similar to https://github.com/devernay/xcodelegacy/issues/27

can you try to add a User-Defined build setting LD_LTO_OBJECT_FILE in your Xcode project with an empty value?

I found this option by looking at /Applications/Xcode.app/Contents/PlugIns/Xcode3Core.ideplugin/Contents/SharedSupport/Developer/Library/Xcode/Plug-ins/CoreBuildTasks.xcplugin/Contents/Resources/Ld.xcspec

gghose commented 7 years ago

Fantastic! It worked!

Unfortunately, I'm still stuck with a project that now won't build under either Xcode 6.4 or Xcode 8.1 (remind me why I upgraded to Sierra?)

Looks like something to do with changes in the dynamic linker.

ld: malformed mach-o, symbol table not in __LINKEDIT file '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks//Accelerate.framework/Accelerate'

collect2: ld returned 1 exit status

On Sat, Jan 14, 2017 at 1:07 AM, Frédéric Devernay <notifications@github.com

wrote:

hope we find a solution similar to #27 https://github.com/devernay/xcodelegacy/issues/27

can you try to add a User-Defined build setting LD_LTO_OBJECT_FILE in your Xcode project with an empty value?

I found this option but looking at /Applications/Xcode.app/ Contents/PlugIns/Xcode3Core.ideplugin/Contents/SharedSupport/Developer/ Library/Xcode/Plug-ins/CoreBuildTasks.xcplugin/ Contents/Resources/Ld.xcspec

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/devernay/xcodelegacy/issues/30#issuecomment-272607218, or mute the thread https://github.com/notifications/unsubscribe-auth/ABUSvdg1nTfYvgUgchmsiPYAMXYalNVUks5rSHRDgaJpZM4LjhWy .

devernay commented 7 years ago

I get this too, but only when linking for i386, not for ppc, with the Accelerate framework targetting 10.5 (10.6 is ok it seems). I guess we will have to get an older ld for i386 too, as we're doing for ppc, see the contents of /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld

devernay commented 7 years ago

I commited a fix that works for me.

if yes, I'll make a 2.0 release

gghose commented 7 years ago

Well it's going to be a while before I can check unfortunately. I was getting so frustrated with Sierra compared to previous versions with regard to development that I decided to wipe and downgrade to El Capitan. And then I found out that the SMART status of my disk was failing so the installer wouldn't proceed. And of course this is on a MacBook Air, making SSD replacement not trivial.

Bottom line, it will be a few days for I can check on things. May I ask, are you running on Sierra?

On Sun, Jan 15, 2017 at 12:02 PM, Frédéric Devernay < notifications@github.com> wrote:

I commited a fix that works for me.

sudo ./XcodeLegacy.sh -compilers uninstall sudo ./XcodeLegacy.sh -compilers install

  • tell me if it works for you now

if yes, I'll make a 2.0 release

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/devernay/xcodelegacy/issues/30#issuecomment-272711996, or mute the thread https://github.com/notifications/unsubscribe-auth/ABUSvZ0Ssiw20B_bY1WfiswmyjPMfpF9ks5rSl8ggaJpZM4LjhWy .

devernay commented 7 years ago

I'm running on Sierra, and I have the intuition that the problem may have been there since el capitan.

Frédéric Devernay, Research Scientist, INRIA frederic.devernay@inria.fr

Le 15 janv. 2017 à 21:06, gghose notifications@github.com a écrit :

Well it's going to be a while before I can check unfortunately. I was getting so frustrated with Sierra compared to previous versions with regard to development that I decided to wipe and downgrade to El Capitan. And then I found out that the SMART status of my disk was failing so the installer wouldn't proceed. And of course this is on a MacBook Air, making SSD replacement not trivial.

Bottom line, it will be a few days for I can check on things. May I ask, are you running on Sierra?

On Sun, Jan 15, 2017 at 12:02 PM, Frédéric Devernay < notifications@github.com> wrote:

I commited a fix that works for me.

sudo ./XcodeLegacy.sh -compilers uninstall sudo ./XcodeLegacy.sh -compilers install

  • tell me if it works for you now

if yes, I'll make a 2.0 release

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/devernay/xcodelegacy/issues/30#issuecomment-272711996, or mute the thread https://github.com/notifications/unsubscribe-auth/ABUSvZ0Ssiw20B_bY1WfiswmyjPMfpF9ks5rSl8ggaJpZM4LjhWy .

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/devernay/xcodelegacy/issues/30#issuecomment-272719855, or mute the thread https://github.com/notifications/unsubscribe-auth/ADmmF05plBII06eGSqrtuI0r2fb8gmxBks5rSnxHgaJpZM4LjhWy.

rsfinn commented 7 years ago

The 2.0rc1 fix prevents the option flags from being used (apparently because the if [ $# != 1 ] check got moved above the place where the option flag is processed).

devernay commented 7 years ago

oops, will fix

gghose commented 7 years ago

I now have a fresh Xcode 8.2.1 install to play with on El Capitan. Is there a new rc I should try out?

On Tue, Jan 17, 2017 at 2:27 AM, Frédéric Devernay <notifications@github.com

wrote:

oops, will fix

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/devernay/xcodelegacy/issues/30#issuecomment-273050904, or mute the thread https://github.com/notifications/unsubscribe-auth/ABUSvUWWeCqYUjU_XWaGvlF6K9th9n92ks5rTHtcgaJpZM4LjhWy .

devernay commented 7 years ago

Thanks @rsfinn there you go https://github.com/devernay/xcodelegacy/releases/tag/v2.0rc2

gghose commented 7 years ago

Yuck. Problem right off the bat (with Xcode not with you!).

I'm getting this message: The run destination My Mac is not valid for Running the scheme 'Lablib'.

And all of the suggestions from a Google search talk about changing the build architectures. But the whole point is for me to be able build for multiple architectures! Moreover even when I go with an $(ARCHS_STANDARD) I still get the message. Xcode can really drive me crazy sometimes!

On Thu, Jan 19, 2017 at 4:17 PM, Frédéric Devernay <notifications@github.com

wrote:

Thanks @rsfinn https://github.com/rsfinn there you go https://github.com/devernay/xcodelegacy/releases/tag/v2.0rc2

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/devernay/xcodelegacy/issues/30#issuecomment-273916316, or mute the thread https://github.com/notifications/unsubscribe-auth/ABUSvQE-4lLVjFBP_yi5E3xT44dlHga3ks5rT-DegaJpZM4LjhWy .

gghose commented 7 years ago

OK. Fixed that one by literally editing a field and then restoring it.

But I'm still encountering the LINKEDIT issue:

export MACOSX_DEPLOYMENT_TARGET=10.5

/Applications/Xcode.app/Contents/Developer/usr/bin/llvm-gcc-4.2 -arch

x86_64 -dynamiclib -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.5.sdk -L/Users/geoff/Desktop/Lablib/LocalFrameworks/build/Development -L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.5.sdk/usr/local/lib -L/usr/local/Cellar/ffmpeg/3.2.2/lib -F/Users/geoff/Desktop/Lablib/LocalFrameworks/build/Development -filelist /Users/geoff/Desktop/Lablib/LocalFrameworks/build/Lablib.build/Development/Lablib.build/Objects-normal/x86_64/Lablib.LinkFileList -install_name @executable_path/../Frameworks/Lablib.framework/Versions/A/Lablib -mmacosx-version-min=10.5 -fobjc-link-runtime -weak-lavutil -weak-lavformat -weak-lswscale -weak-lavcodec -framework Accelerate -framework Security -framework CoreAudio -framework AppKit -framework IOKit -framework OpenGL -framework AudioUnit -framework Carbon -weak-lvpx_interapp -framework CoreVideo -framework Cocoa -framework AddressBook -framework AudioToolbox -framework QTKit -framework Foundation -weak_framework ITC -framework GLUT -framework SystemConfiguration -weak_framework PVCAM -framework CoreServices -weak_framework QuickTime -framework QuartzCore -weak_framework bTop -weak_framework eyelink_core -weak_framework SDL -weak_framework SDL_gfx -single_module -compatibility_version 1 -current_version 1 -Xlinker -dependency_info -Xlinker /Users/geoff/Desktop/Lablib/LocalFrameworks/build/Lablib.build/Development/Lablib.build/Objects-normal/x86_64/Lablib_dependency_info.dat -o /Users/geoff/Desktop/Lablib/LocalFrameworks/build/Lablib.build/Development/Lablib.build/Objects-normal/x86_64/Lablib

.......

ld: malformed mach-o, symbol table not in __LINKEDIT file '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks//Accelerate.framework/Accelerate

On Thu, Jan 19, 2017 at 5:10 PM, Geoff Ghose gmghose@gmail.com wrote:

Yuck. Problem right off the bat (with Xcode not with you!).

I'm getting this message: The run destination My Mac is not valid for Running the scheme 'Lablib'.

And all of the suggestions from a Google search talk about changing the build architectures. But the whole point is for me to be able build for multiple architectures! Moreover even when I go with an $(ARCHS_STANDARD) I still get the message. Xcode can really drive me crazy sometimes!

On Thu, Jan 19, 2017 at 4:17 PM, Frédéric Devernay < notifications@github.com> wrote:

Thanks @rsfinn https://github.com/rsfinn there you go https://github.com/devernay/xcodelegacy/releases/tag/v2.0rc2

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/devernay/xcodelegacy/issues/30#issuecomment-273916316, or mute the thread https://github.com/notifications/unsubscribe-auth/ABUSvQE-4lLVjFBP_yi5E3xT44dlHga3ks5rT-DegaJpZM4LjhWy .

devernay commented 7 years ago

did you uninstall and reinstall the compilers? check that these exist:

$ ls -la /Applications/Xcode.app/Contents/Developer/usr/libexec/gcc/darwin/i386/ld 
-rwxr-xr-x  3 root  wheel  4973120 15 jan 17:02 /Applications/Xcode.app/Contents/Developer/usr/libexec/gcc/darwin/i386/ld
$ ls -la /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld
-rwxr-xr-x  1 root  wheel  2123 15 jan 17:02 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld
devernay commented 7 years ago

(with the same size of course - 5th column in the results)

gghose commented 7 years ago

I'm on XCode 8.2.1, so that might explain the difference in the default toolchain ld. Also note that this happens for the x86_64 arch, but NOT for i386 and ppc which link fine.

woozle:~ geoff$ ls -la
/Applications/Xcode.app/Contents/Developer/usr/libexec/gcc/darwin/i386/ld

-rwxr-xr-x  3 root  wheel  4973120 Jan 19 16:22
/Applications/Xcode.app/Contents/Developer/usr/libexec/gcc/darwin/i386/ld

woozle:~ geoff$ ls -la
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld

-rwxr-xr-x  1 root  wheel  2139 Jan 19 16:22
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld
devernay commented 7 years ago

Are you trying to link x86_64 for 10.5? What's the point exactly, since I think it won't ever run in x86_64 on 10.5 (no kernel support for this arch afaik)? You should use:

If you really want to compile x86_64 for 10.5, you can modify the script following what I did for i386, but then the x86_64 linker will always use the snow leopard ld, and linking for more recent macOS may not work anymore. I would strongly discourage this, and will definitely not set it as a default behavior in the script.

An alternate solution would be to parse -mmacos-version-min=10.[456] in the arguments or the MACOSX_DEPLOYMENT_TARGET env var and use the snow leopard ld only in these cases for i386 and x86_64 archs. I may implement this.

devernay commented 7 years ago

ok, I implemented a solution that does everything, no need to set custom Xcode settings, except perhaps "Implicitly Link Objective-C Runtime Support" if you get an error (see readme)

can you try it and give feedback, please?

gghose commented 7 years ago

Success!

I reinstalled the compilers using the script and got rid of the LD user defines and it links just fine. Many, many thanks!

On Sat, Jan 21, 2017 at 3:57 AM, Frédéric Devernay <notifications@github.com

wrote:

ok, I implemented a solution that does everything, no need to set custom Xcode settings, except perhaps "Implicitly Link Objective-C Runtime Support" if you get an error (see readme)

can you try it and give feedback, please?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/devernay/xcodelegacy/issues/30#issuecomment-274251806, or mute the thread https://github.com/notifications/unsubscribe-auth/ABUSvb6753krr0A-cEPa7TGxl0ASU8Dkks5rUdaUgaJpZM4LjhWy .

devernay commented 7 years ago

@rsfinn can you check that it works fine for you too before I do the 2.0 release?

@siriuscn @ddobrev @mrpippy @misfitius @zhoub @sstillwell @dfroger @ling32945 @DominusExult @EricFromCanada @nbeadman @Gnimuc @DrLou @olance @inspector-g @raxoft @nickwww @mattygroves @raxoft you are welcome to test too

rsfinn commented 7 years ago

Yes, just double-checked and the single-OS options (e.g. -osx1011) appear to be working fine. Thanks.