Reliable Deployment of Delphi-Generated Dylib on OSX - macos

I would like to deploy a .dylib on OSX, which has been created with Delphi. This .dylib should be loadable by third-party applications.
This is going to seem like a duplicate question, but after plenty of searching, I can't find an answer for it. It's the same issue as this: https://forums.embarcadero.com/thread.jspa?messageID=592417
The problem is that the .dylib requires libcgunwind.1.0.dylib, but that it cannot find it when being run from a third-party application. As a test, I tried copying libcgunwind.1.0.dylib into usr/lib, and that worked. When OSX cannot locate the .dylib, it will always search in usr/lib. Unfortunately, I do not want to do this as a final solution, because it would require elevated permissions, and seems like a heavy handed way of dealing with a simple problem.
Inspecting a bit closer, I used otool to inspect my .dylib, and it gave me the following path: #rpath/libcgunwind.1.0.dylib.
The trouble is, there's no accounting for what paths will be listed in #rpath, when your .dylib is being run by a third-party application. For this to work, the application would always have to provide an absolute path to libcgunwind.1.0.dylib.
The obvious solution is to use install_name_tool to replace #rpath with #loader_path. If my logic is correct, this should cause my .dylib to always find libcgunwind.1.0.dylib, as long as they are in the same folder. This makes sense, as the .dylib ought to be in charge of finding its own dependencies.
So, I tried the following command line:
install_name_tool -change #rpath/libcgunwind.1.0.dylib #loader_path/libcgunwind.1.0.dylib libTest.dylib
and received this message:
install_name_tool: file not in an order that can be processed (local relocation entries out of place): libTest.dylib
I did some searching around for this error message, and I haven't been able to find any information on it. I have to assume that install_name_tool is expecting some specific conventions found in a gcc or llvm built .dylib, and that Delphi's compiler is not providing those conventions.
I did some digging around in Delphi's compiler dccosx, and checked the command-line arguments Delphi is sending to it, but I can't find any useful options. This way of using libcgunwind.1.0.dylib, seems to be implicit to the compiler, and not something I can adjust.
I'm not suggesting that this is the right way to tackle the issue, these are just the latest things that I've tried. If you can come up with a different way of working around the problem, please share your ideas!

The install_name_tool seems to require that certain parts of the dylib are in a certain order like "local relocation entries" then "symbol table", "local symbols", ... The error message means that this order is not as expected.
My suggestion is that you try to patch the dylib file. I do that all the time with OSX executables because I need to tell them which dylib versions they are compatible with. This fixes a couple of bugs in a Delphi OSX application. A dylib has a very similar structure as the executable. My experience is that patching these files is not as complicated as it sounds.
You can find the description of the file structure here:
https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/MachORuntime/Reference/reference.html
The LC_LOAD_DYLIB section is what you'll need to look at. You should be able to replace the dylib names with something longer as this section usually has some extra padding.

Related

How do I inform lldb debugger where the source code is?

I have an executable that makes use of /usr/lib/libcrypto.0.9.8.dylib. I've (more or less) figured out some breakpoints within that library that I'd like to understand better.
However, I do not remember if this is the stock openssl on the system, or if I later installed it (don't think so, pretty sure that homebrew would have put it elsewhere).
This is for macOS Mojave (10.14). If the debug symbols have been stripped in libcrypto, I'm not sure I even know how to check that (nm?). I have, however, downloaded and extracted the source (matching the version).
Is there any way to configure lldb such that it can show me the source code instead of assembly language? If the debugging symbols have been stripped (without even checking, I'd assume so) can you even do this?
I'm trying to do my own research for this, but I'm not even sure I know what keywords to search with yet.
The tools on Darwin don't store debug information in the binaries, but rather in a separate standalone bundle (a dSYM). So if you don't have a dSYM for your libcrypto then you don't have debug information for it, and there's no way to reconstruct the code->source map.
Some distributions have debug packages as well as release ones that include the dSYM's. lldb matches dSYM to binary using a common UUID computed by the linker. You can print the UUID with the command dwarfdump --uuid <PATH TO BINARY> and then see if wherever you got the library from kept that dSYM.
But if you can't find the dSYM, you aren't going to be able to do any source level debugging.

GCC: How to find out why a library is included in the executable

This is the problem:
(On Linux Slackware64) I compiled Inkscape (0.92.3) and found that exporting to PNG doesn't work. An indication on the terminal tells me:
libpng warning: Application built with libpng-1.6.16 but running with 1.5.13
First reaction was to list the linked libraries using ldd. Indeed, both libpng-1.6.16 and libpng-1.5.13 are listed as necessary.
So, I suspected that some of the other libraries was requiring libpng-1.5.13. I made a small Python program which takes all the libraries (except the libpngs) and applies ldd to each of them. None of them listed libpng15. What now? I suspect that if any of the secondary libraries needed libpng15, it would be listed here, but, just in case I made the search recursive. No luck.
So it was, apparently, inkscape itself requesting the old version. A simple search in all files in the search tree only showed the string 'png15' in the viewer and actual inkscape executable.
There are probably older programs of mine still linked with png15, so I probably want to keep that version around.
Most, if not all references on the net mentioning this error (or similar) refer to programs with very old pnglibs (1.2.4x) trying to use a newer version, but here it's the other way around.
libpng-config --version reports 1.6.16
Any suggestion how to identify the source of this problem? Particularly why inkscape included the old libpng?

Runpath Search Paths can't find library even with #rpath/library.dylib

I've been banging my head against the wall on this for hours. I've been playing around with CMUSphinx's pocketsphinx library, running on OSX 10.10/XCode 7.2,and want to get my .app bundle to work on computers besides my own. Most importantly, there are three dynamic libraries that have to be embedded in the .app bundle(libpocketsphinx.3.dylib, libsphinxad.3.dylib, and libsphinxbase.3.dylib), and then loaded using Runpath Search Paths settings in XCode.
I've read just about everything I can find on how to get this to work. I should note that the .app bundle compiles/runs as intended on my own machine. I've made sure that the libraries are copied into the .app bundle's /Contents/Frameworks folder. The libraries are not using references, but are copied into my source folder (as per a forum post on this exact issue on CMUSphinx's page). I've tried just about every combination of using install_name_tool for #rpath/libraryname.dylib, as well as #loader_path and #executable_path in both the executable (so changing it in XCode to #whatever_path/../Frameworks), as well as the three library files. I also have tried #loader_path/Frameworks per another post here, but no luck.
Whats weird is the error I'm getting seems like it is loading libsphinxad.3.dylib, as both libsphinxad.3.dylib and libsphinxad.3.dylib rely on libsphinxbase.3.dylib, but I get this error in the crash report:
Dyld Error Message:
Library not loaded: /usr/local/lib/libsphinxbase.3.dylib
Referenced from: /Volumes/SunGate/VoiceCommander.app/Contents/Frameworks/libsphinxad.3.dylib
Reason: image not found
Note, the /Volumes/SunGate/ is just a drive on another machine I'm testing this on.
I would really appreciate help with this! I will do my best to provide any other information that might help solve this!
I found this lib by using the "find" command on my system. Not surprisingly it was here
sphinxbase/src/libsphinxbase/.libs/libsphinxbase.3.dylib
I linked it to /usr/local/lib/
ln -s sphinxbase/src/libsphinxbase/.libs/libsphinxbase.3.dylib /usr/local/lib/libsphinxbase.3.dylib
And all set to go!

Signing Firemonkey-generated dylib on Mac OS X

When I try to run codesign on a dylib created by Embarcadero's Firemonkey I get an error message:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate:
file not in an order that can be processed (local relocation entries
out of place): /Users/jwwalker/Documents/libV35SS.dylib
It might be related to this question: Reliable Deployment of Delphi-Generated Dylib on OSX
However, I tried reordering the load commands to make LC_ID_DYLIB come first, as was apparently the solution for that question, and it didn't help. Is there some other way to do binary editing on the file to fix it? Any clues as to the "right" location of the local relocation entries?
Using information from the Mach-o File Format Reference, I put together a tool that (at least in the case of my fairly small and simple dylib) rearranges data in the dylib to make it palatable to codesign. I released my code as open source.
The solution for the other question was patching the paths of the used dylibs directly in the dylib. That was basically doing manually what install_name_tool was supposed to do. But that won't help you for codesigning. That would basically mean you'd have to write your own code signing tool, but then it is still not certain that OSX will accept the signature of a "broken dylib".
You could take a closer look at the following source file. This is the best I've found so far about the correct order and the structure of the dylib.
http://www.opensource.apple.com/source/cctools/cctools-855/libstuff/checkout.c
Fixing this issue manually will probably be a big challenge. I guess you'd have to take the dylib apart and rewrite it:
https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/MachORuntime/Reference/reference.html
You might want to vote for this QC and tell Embarcadero that they must fix this if they want to support deployment to OSX 10.9.5 or Yosemite:
Report No: 125607 Status: Open
[MacOS] can not codesign libmidas.dylib for Apple Mac Store
http://qc.embarcadero.com/wc/qcmain.aspx?d=125607
QCWIN:Defect_No=125607

How to build apple's opensource libc?

I'm trying to build apple's opensource libc (from http://www.opensource.apple.com/source/Libc/Libc-763.11/) on my OS X 10.6.8 laptop. This is in an attempt to essentially get a locally generated replica of /usr/lib/libSystem.B.dylib, which I intend to experiment on further.
I see a couple basic roadblocks though (unless, obviously, I'm missing something basic):
No instructions on how to do the build. There are a couple of Makefiles in the URL I reference above, but they fail to build when I try to do straightforward makes:
$make -f Makefile
Makefile:14: *** missing separator. Stop.
I suspect the source available for download is incomplete. Not incomplete in the sense that Apple isn't revealing all of the changes, but incomplete in the sense that there are source files that were (presumably) not modified by Apple, so isn't included in the collection. For example, I don't see the implementation of the "open" call (which, in the gnu libc hierarchy, is available at io/open.c)
The closest reference I could find after some googling was this: http://www.projectosx.com/forum/index.php?showtopic=1922&st=0&p=12457&#entry12457 but it still isn't close enough for my taste!
Any pointers?
Thanks!
Only some general pointers (although some links are discussing older OSX versions):
http://darwinbuild.macosforge.org/trac/ticket/6
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-projects/darwin/overlay/sys-libs/libc-darwin/libc-darwin-391.ebuild?view=markup&sortby=log
http://althenia.net/wiki/darwin#standard_library_libc
http://dev.gentoo.org/~vapier/CROSS-COMPILE-GUTS
http://www.raccoonfink.com/fink/darwin-cross/

Resources