I would like to rename symbols inside object files (.o) with something that would be the Mac equivalent of binutils' objcopy --redefine-syms tool.
I found no arm-apple-darwin10-objcopy. I tried the MacPorts' arm-elf-binutils port and also tried to play a bit with otool and segedit without much success.
Any ideas please?
Sounds like a job for Agner Fog's objconv.
From the announcement:
I have now finished making full support for Mach-O files in the object file converter mentioned in my previous posts. You may use it as a replacement for the missing objcopy utility.
Objconv can be used for the following purposes:
Convert object files and library/archive files between Mach-O, ELF, COFF and OMF formats for all x86 and x86-64 platforms.
Change symbol names in object files, make symbols weak, add alias names to symbols.
Build, modify and convert static library files (*.a, *.lib) across platforms (Mac, Linux, BSD, Windows)
Dump object files and executable files
Disassemble object files and executable files. Very good disassembler.
objconv manual
objconv.zip - source
I know I'm resurrecting this post from the dead, but...
I have a sudden need to do this as well, and discovering that objcopy doesn't work on OSX was a bit of a shock. But I think it's possible to use ld to achieve the same effect:
ld -r input.o -o output.o -alias oldsymbol newsymbol -unexported_symbol oldsymbol
This really just creates an alias for the symbol under a new name and hides the old one.
I haven't had a chance to do much testing yet, but looking at the output file with nm shows it seems to be doing the right thing.
objconv does not currently work for ARM, so this option is not available for iPhone. It should be no problem to use objconv from elf to mach-o for mac osx x86/x64 though. Let me know if you found a solution for ARM
Related
I am trying to link libssl.a and libcrypto.a static libraries in XCode command line project [under Link Binary With Libraries]. I have included Openssl header files in search path.
Compilation succeeds but execution fails with dyld: Library not loaded: /usr/local/ssl/lib/libcrypto.1.0.0.dylib.
Why does it look for dylib when I am linking it statically? How can this be fixed?
Any help would be appreciable.
Why does it look for dylib when I am linking it statically? How can this be fixed?
Apple's linker uses the dylib or share object if its available, regardless of of your linker flags like -rpath and -Bstatic. They even do it on iOS, where dylib's are not allowed!
Its kind of a well known problem once you know about it :) See, for example, Installing Crypto++ 5.6.2 on Mac OS X. Crypto++ has the same problems with Apple's tools.
The fix is to stop using -L and -l options, and to link the object file or archive directly. An archive is just a collection of object files, so you can use them interchangeably.
To specify the object files or archives for the linker, see Linking to an object file. Under Xcode, you add the fully specified archive name (like /usr/local/openssl-ios/lib/libcrypto.a) to Other Linker Flags (the OTHER_LDFLAGS Xcode option).
When adding the full archive to OTHER_LDFLAGS, I believe you just add it verbatim without any switches, like -l or -L. You may need -Wl (-Wl,/usr/local/openssl-ios/lib/libcrypto.a), but you don't use -l (-l/usr/local/openssl-ios/lib/libcrypto.a).
You use -Wl when the option is passed through the compiler driver to the linker. If the linker is invoked directly, then you don't need -Wl and should not use it.
A second option is to set GCC_LINK_WITH_DYNAMIC_LIBRARIES to YES. Apple does not appear to document it in Xcode Build Setting Reference, but its clearly under my copy of Xcode. See How to link a static library for iOS on Stack Overflow.
I seem to recall having problems with this in the past. Its one of those things that should work in theory, but does not work in practice.
A third option is to remove the dylib or shared object from all paths used under Xcode so Xcode does not accidentally find it when using -lcrypto.
A fourth option is use allow dynamic linking, but execute the program with DYLD_LIBRARY_PATH. Its OS X's equivalent to LD_LIBRARY_PATH, and ensures your copy of OpenSSL is loaded (like 1.0.2), and not the system's version of OpenSSL (0.9.8).
But I don't like this option because it requires users of your software to do something.
Another possibility due to the message dyld: Library not loaded: /usr/local/ssl/lib/libcrypto.1.0.0.dylib is to code sign your copy of the library. Its a little odd its found but not loaded, so I'm going to toss this out there in case its OS X's Code Signing or Gatekeeper Service...
To code sign your copy of the library under the MAC Developer program, just:
codesign -fs "Johnny Developer" /usr/local/ssl/lib/libcrypto.so
I wanted to study ELF relocation mechanism, so I assembled an x86 assembly program using NASM to produce an ELF file, but under Win32. Then I used mingw32's gdb to debug it. It loaded nicely and I could view the program using "list" command. However, I couldn't run it. I got the following messages:
Starting program: c:\Projects\NasmProjects\Test01\Hello.o
Error creating process c:\Projects\NasmProjects\Test01\Hello.o
Is there a way around this?
Is there a way around this?
No.
First, you have assembled a relocatable object file (of type ET_REL). There is no OS that will "run" such files -- OSes that do support executing ELF files, require a fully linked executable (of type ET_EXEC or ET_DYN).
Second, even if you manage to link an ET_EXEC, you still need your OS to know how to load and start executing such a file. Linux and Solaris kernels do know this, AIX and Windows kernels do not.
I have a lib (*.a) file, created with armcc in the elf format. There is no possibility to recompile it with llvm or gcc. (It's assembler written for armcc).
Linking it with the gnu ld works fine on Linux, but I have problems doing it on Mac, with llvm.
Because of the different internal format for obj files, it will say "Ignoring file ... which is not the architecture being linked"
Is there a workaround for this? A way to convert elf to Mach-O format? To tell llvm about elf?
There is such a tool for x86/86-64, written by Agner Fog, but I am looking for an ARM tool.
There is an objcopy from binutils, which should convert binary from one format to another. I think, you should have binutils compiled with both Linux and iOS BFDs. Unfortunately, binutils's support of Mach-O was incomplete (there are some negative reports about ARM+objcopy+Mach-O).
See also:
An objcopy equivalent for Mac / iPhone?
http://sourceware.org/bugzilla/show_bug.cgi?id=10222
Other way of converting is to do a reassembly (disassemble each .o file from .a archive and reassemble it with Mach-O-compatible assembler).
I downloaded and installed (I think) gtk on the Mac OSX (Lion). Compilation of test program went fine after getting all the -I's correct. Now the link is failing. A grep for the missing entrypoints
_gtk_init
_gtk_window_new
... 11 more
found them in
/Users/ccpalmer/gtk/inst/lib/libgtk-quartz-2.0.0.dylib
/Users/ccpalmer/gtk/inst/lib/libgtk-quartz-2.0.dylib
Being less familiar with OSX's underlying Unix, I'm not sure how to get thru the link step. I must admit, I've never encountered a "dylib" before.
Are there any OSX dev smarties out there who might shed some light on my mystery?
Charles
As moshbear commented above, dylib files are how shared libraries are packaged on Mac OS X. To use such a shared library, you need to pass two switches to your compiler, -L and -l. The first adds the directory containing your dylib to the linker's library search path, and the second specifies the library to link against. Something like this, for a fictional libfoo.dylib that lives in /usr/mylibs:
clang code.c -L/usr/mylibs -lfoo
In theory, it's very easy to build a Win32 app with a resource file using cmake. In an add_executable command, a resource file can be listed as easily as a C or C++ source file. There is a known bug, however, when building using MinGW tools.
I found a workaround, which is to include the following in CMakeFiles.txt...
if(MINGW)
set(CMAKE_RC_COMPILER_INIT windres)
ENABLE_LANGUAGE(RC)
SET(CMAKE_RC_COMPILE_OBJECT
"<CMAKE_RC_COMPILER> <FLAGS> <DEFINES> -o <OBJECT> <SOURCE>")
endif(MINGW)
Unfortunately, this doesn't seem to work. What seems to happen is that windres generates a <whatever>.rc.res file which ld doesn't understand.
In my searches, I've developed a strong suspicion that Win32 support is seen as a very low priority, especially outside of Visual Studio. This is understandable, as Win32 obviously isn't as important as it once was. And of course Visual Studio Express Editions are easily available for free.
Even so, it would be convenient for me if I could use MinGW GCC for a few old Win32 apps I still use. If nothing else, I can get GCOV test coverage stats.
Obviously if all else fails, I could always handle resource files using a custom build command. One issue is that I'm not familiar with either windres or ld, or how MinGW is meant to handle Win32 resource files. Another is that I don't really want to reinvent the wheel if someone already has a superior wheel they'd like to share with me.
So that's basically it - how can I support building Win32 apps with resource files using cmake, and using MinGW (but not breaking support for Visual Studio)?
I think, your problem is here:
<CMAKE_RC_COMPILER> <FLAGS> <DEFINES> -o <OBJECT> <SOURCE>
Maybe you should write something like this:
<CMAKE_RC_COMPILER> <SOURCE> <OBJECT>
Or more formal:
<CMAKE_RC_COMPILER> -i <SOURCE> -o <OBJECT>
The other possible problem could be with - which extension does cmake substitutes? As windress will guess the needed output file format from that.
References are here:
www.mingw.org/wiki/MS_resource_compiler
"res" files are unappropriate for ld, as you already know, and the windres example
sourceware.org/binutils/docs/binutils/windres.html
windres man
EDIT by question author...
The fixed cmake code snippet is as follows...
if(MINGW)
set(CMAKE_RC_COMPILER_INIT windres)
ENABLE_LANGUAGE(RC)
SET(CMAKE_RC_COMPILE_OBJECT
"<CMAKE_RC_COMPILER> <FLAGS> -O coff <DEFINES> -i <SOURCE> -o <OBJECT>")
endif(MINGW)
It should probably be setting a flags variable rather than inserting the -O option in the command template, but this works.