I'm working on a snow leopard machine (10.6.5) and I'm hunting a bug in our C++ application. However, I can't build our app with g++ -O0 -g, because the linker crashes:
g++-4.0 -arch i386 -arch x86_64 ... -dynamic -bundle -o SOMELIB.dylib <SOME OBJECTS>...
collect2: ld terminated with signal 11 [Segmentation fault]
collect2: ld terminated with signal 11 [Segmentation fault]
I guess the two crashes are because there are two "-arch" flags.
I managed to get a core file, which said the crash occurs in
(gdb) bt
#0 0x000000010001a2eb in Linker::synthesizeDebugNotes ()
#1 0x0000000100024cc5 in Linker::collectDebugInfo ()
#2 0x0000000100028198 in Linker::link ()
#3 0x000000010002a9eb in main ()
With this hint, I removed '-g' from the compiler flags, and everything builds fine. Moreover, most of our stuff builds fine with '-g', but just two of the big modules (.dylibs) don't, so I'm left with no debuginfo for those. And, ironically, the bug lurks just there, in one of these dylibs.
The bug is most likely due to an uninitialized memory use, as it manifests rarely, and running the app under valgrind reveals that there are a few uninitialized memory refences, but because of the missing debuginfo, it just says it happens inside module XXX (the dylib I can't compile with "-g")
So, I tried to download the ld utility from Apple's open source website, but I found (just like that guy) that it won't build because of a missing dependency to a Mac-specific version of libunwind, which Apple won't give away. Thus I can't recompile the linker.
So the next question is - what should I do now? I really wanted to avoid contacting Mac support...
ld version is "ld64 97.17", XCode is 3.2.5, gcc is 4.0.1.
I really need some directions...
Related
Right now I am dipping my toes in x86 asm, and am trying to build a simple program using the 32-bit IA-32. I understand macOS 10.15 Catalina dumped support for running 32-bit programs, but does this mean there is no way I can build them? What if I need to cross-compile for another system?
Here is what I am trying to do. Say I have
test.c:
int main() {
return 0;
}
I compile with clang test.c -m32, and get the following warning:
ld: warning: The i386 architecture is deprecated for macOS (remove from the Xcode build setting: ARCHS)
ld: warning: ignoring file /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib/libSystem.tbd, missing required architecture i386 in file /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib/libSystem.tbd
ld: dynamic main executables must link with libSystem.dylib for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)
When I try with gcc-10 test.c -m32 (installed through brew), I get
/var/folders/pg/m7w7y_w94s32b23psmxmy7bh0000gn/T//ccwFWObO.s:5:2: error: instruction requires: Not 64-bit mode
pushl %ebp
^
/var/folders/pg/m7w7y_w94s32b23psmxmy7bh0000gn/T//ccwFWObO.s:12:2: error: instruction requires: Not 64-bit mode
popl %ebp
^
Am I completely stuck here? What would you recommend to get around this? Do I need to use another operating system (e.g., past version of macOS, ubuntu, FreeBSD, etc.) in order to build 32-bit executable? For what it's worth, I can produce an asm source file, calling either gcc-10 -S test.c -m32 or the same with clang. I just can't build (and likely run) the executable. All suggestions appreciated.
I want to compile the following project that's hosted on GitHub. I'm on MacOs High Sierra 10.13.5.
When I run make on the solver directory, it gives the following error after running gcc with the -static option:
g++ -o dapcstp src/bbnode.o src/bbtree.o src/bounds.o src/cputime.o
src/heur.o src/inst.o src/main.o src/options.o src/prep.o
src/procstatus.o src/sol.o src/stats.o src/timer.o src/util.o -static -
lboost_timer -lboost_system -lboost_chrono -lboost_program_options -
lboost_filesystem
ld: library not found for -lcrt0.o
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
make: *** [dapcstp] Error 1
In the answer to ld: library not found for -lcrt0.o on OSX 10.6 with gcc/clang -static flag it says the following:
This option will not work on Mac OS X unless all libraries (including libgcc.a) have also been compiled with -static. Since neither a static version of libSystem.dylib nor crt0.o are provided, this option is not useful to most people.
Is there a way I could circumvent this limitation and compile the project correctly on Mac ?
Looking at the project, the -static option is superfluous and counterproductive (even on system where static linking is supported). You can just remove it.
There is another question with similar naming but it was never resolved.
I installed arm-none-eabi gcc and binutils from the GNU Arm Embedded PPA on Ubuntu. This toolchain normally works fine.
Today however, in my Makefile, I link with -march=armv7-m -mcpu=cortex-m3 as some of the options. This immediately causes ld to fail like this:
$ arm-none-eabi-ld -mcpu=cortex-m3 -march=armv7-m -Tcm3.ld # and some more options
arm-none-eabi-ld: unrecognised emulation mode: arch=armv7-m
Supported emulations: armelf
What have I done wrong? I can't seem to find any information about this!
I've also tested this with my other toolchain (CodeSourcery, March 2011). That toolchain normally works, but fails now too.
Should I be linking with gcc not ld?
It appears that linking with gcc rather than ld solves the problem. I can even pass in the linker script without having to use -Wl,-T.
I'm still open as to why ld didn't work in the first place.
I mostly work on linux and have no problems but want to occasionally use a Mac for work. Somehow gfortran does not work there, though. I installed it as instructed but when I try to compile something, this happens:
gfortran -o m_g_matrix2.x m_g_matrix.f90
ld: entry point (start) undefined. Usually in crt1.o for architecture x86_64
collect2: error: ld returned 1 exit status
I have no idea what this means and google search did not help. Did someone manage to get gfortran to work on Mac?
Thanks for the help!
I installed gcc binaries for yosemite from http://hpc.sourceforge.net
and also installed Xcode command-line tools as directed there.
gcc contains the gfortran compiler.
Seems to work well on macbook air with Yosemite.
JTN
I want to set up a project to take my .hs code, and my main .c program, and result in a statically linked executable through the use of LLVM compiler. I can get things working via ghc command line options to build a .hs, produce the stubs, and compile and link a driver application using ghc entirely. However, I get various issues within Xcode.
My first issue was that I of course need to use 32 bit compiling environment in Xcode. That solved, I had to fiddle with paths to explicitly include the HsFFI.h. That solved, I get a linker error:
Ld "build/Debug/FFI Test.app/Contents/MacOS/FFI Test" normal i386
cd "/Users/rcl/TestXCodeProjects/FFI Test"
setenv MACOSX_DEPLOYMENT_TARGET 10.6
/Developer/usr/bin/clang -arch i386
-isysroot /Developer/SDKs/MacOSX10.6.sdk
"-L/Users/rcl/TestXCodeProjects/FFI Test/build/Debug"
"-L/Users/rcl/TestXCodeProjects/FFI Test/FFI Test"
"-F/Users/rcl/TestXCodeProjects/FFI Test/build/Debug"
-filelist "/Users/rcl/TestXCodeProjects/FFI Test/build/FFI Test.build/
Debug/FFI Test.build/Objects-normal/i386/FFI Test.LinkFileList"
-mmacosx-version-min=10.6 -framework Cocoa
"/Users/rcl/TestXCodeProjects/FFI Test/FFI Test/ForeignExportCost.a"
-o "/Users/rcl/TestXCodeProjects/FFI Test/build/Debug/FFI Test.app/
Contents/MacOS/FFI Test"
Undefined symbols for architecture i386:
"_hs_init", referenced from:
-[FFI_TestAppDelegate applicationDidFinishLaunching:] in FFI_TestAppDelegate.o
"_simpleFunction", referenced from:
-[FFI_TestAppDelegate applicationDidFinishLaunching:] in FFI_TestAppDelegate.o
"_hs_exit", referenced from:
-[FFI_TestAppDelegate applicationDidFinishLaunching:] in FFI_TestAppDelegate.o
ld: symbol(s) not found for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)
The "simpleFunction" is in "ForeignExportCost.a" library which I compile using ghc like this:
ghc -no-hs-main -fPIC -c ForeignExportCost.hs
ghc -no-hs-main -shared ForeignExportCost.o -o ForeignExportCost.a
What am I missing or doing wrong?
Ugh - it looks like the answer to my question is detailed here, telling me how to painfully add a ton of .a's to my project. And this blog post gave some helpful tips to getting on the way.
Although if someone tells me "hey wait, there's an easier way than iteratively figuring out failed deps" that would be awesome. Because I want to reuse this framework several times and this is a real pain of a way to get things up and going!