I'm working on porting a library onto AIX. It works on Solaris, Windows and Linux but AIX is giving me headaches. I'm at a point where it builds and runs but I have an issue with some of the libraries it's linking in. Ideally I want to be able to ship a library that just requires the c runtime to be available with no other dependencies. At the moment I'm having a problem with libpthread which I can see is a symlink to an AIX specific threading library.
My issue is this:
If I don't link pthread (I don't seem to need to on Solaris for the same code base) then I get undefined symbols. That's fine I am using pthreads. If I link it in then it works fine, except that any calling application also has to link to pthreads. I don't really understand is why does my calling app, which has no dependency on pthread, need to link against it just because it's calling a library which links to the shared object?
I'm on AIX 6.1 using gcc 4.2.4.
I'd be OK with shipping a library that requires pthreads to be present on the library path (ideally we'd get a static version) but I'm a bit unhappy about shipping a library that places linker rqeuirements on the client.
Any ideas on what I might be doing wrong?
I defeinitely seem to be going in circles. I removed the -shared flag on the linker to resolve an earlier problem and that, of course, makes the library static. So the behaviour is just normal behaviour in that if you depend on a dynamic library from a static one you have to link both into your app. So I've put the shared flag back and now half of my functions are no longer accessible. It does explain the problem I was seeing though.
Related
I've tried searching through existing answers, but didn't find anything that helps with this exact situation, so here goes ...
I'm working on a project with a deliverable .so file that contains a lot of proprietary IP, so we want to tightly control the export symbols that it exposes. Examining the .so with the nm and objdump tools actually shows no symbols exposed (which seems a bit odd, as a client app is able to link with it), but opening it with Ghidra shows absolutely everything imaginable in the 'Exports' tree.
The project is C/C++ code being built in Visual Studio 2019, using the Clang 5.0 toolset (release build for ARM64, android-27). Perhaps important to note that the library exposes a C API, so none of the functions/structs/enums intended to be exposed are namespaced. The -fvisibility=hidden switch is being set, which I understand should hide symbols by default, and __attribute__((visibility("default"))) is being specified only on the functions we want to expose. But it doesn't appear to be working as expected.
As a sanity-check experiment, I hacked the code to change the __attribute__((visibility("default"))) to __attribute__((visibility("hidden"))), just to see what effect that would have, and was pleasantly relieved to see that the relevant functions no longer appeared in the Ghidra view. This suggests that we could use that to hide things we don't want exposed, but:
It's just not really feasible to go through the entire codebase to retrofit that everywhere.
Surely that shouldn't be necessary because the -fvisibility=hidden switch should be doing that as the default for everything in the library.
For comparison, there is a Windows DLL build of the same project, which declares __declspec(dllexport) in the relevant places (usual approach of using a macro to handle the various different build scenarios), and when examining the DLL in Ghidra, only the relevant functions that we want exposed are visible as being exported.
I just want the .so build to do the same thing, but can't seem to make it happen.
As a last-ditch effort, I tried using the llvm-strip tool to try removing symbols from the .so file after building, but to no avail (probably because the other tools didn't actually list any symbols in the first place).
Any advice would be gratefully received!
I have a "fat" framework built for iOS, which is being used in a debugging tool built for macOS. Previously I was linking this framework statically, which worked, even though XCode complains about it being built for the simulator (since the architecture is the same). But now, newer versions of the library are dynamic, so that route doesn't work, as the tool is a command line application, which doesn't support embedding frameworks.
I could turn it into an application bundle, it seems, in order to solve that, but I'm not sure what this entails (creating a new project?). I can certainly figure it out but ..
In the meantime, I thought I'd load the library dynamically using dlopen() etc and retrieve the classes/methods I need (I already have some code for this which at least compiles). However, that call fails with the following message:
no suitable image found. Did find:
/<path to library file>: mach-o, but built for simulator (not macOS)
Since linking statically is only a warning and actually works, is there a way to make dlopen work as well?
Recompiling the framework itself is not an option for me in this situation.
Are you considering editing the binary of the dylib framework? If so in the Macho-O header you could try changing LC_VERSION_MIN_IPHONEOS to LC_VERSION_MIN_MACOSX.Probably it won't be enough,but it's a simple change for a quick test. Here's a screenshot comparison of those load commands in MachOView
Also covered the other way round here
I have just finished porting a decent amount of c-sources to the iOS platform and packaged them as a universal static framework. I, then, added the framework (not the project) to a sample iOS app in order to test linkage and proper function. That's when I ran into a humbling problem.
In my attempt to solve the problem described here, I also came across some symbols that are composed through the heavy use of macros (i HATE those). Some of those macros use function attributes that are really extensions of gcc rather than of standard C.
Of course I can always add -std=gnu89, but even then, I am not sure it will resolve the original problem of undefined symbols in the static library.
Not only that, I am now worried that my port to iOS of those sources may not be an accurate port and may result in the type of bugs/issues that maybe related to compiler's codeine and/or optimization policies.
If you can share some of your experience/advice in how best to go about that port, I would really appreciate it.
Thanks!
From manual testing with clang 8.0, it seems that both __attribute__((constructor)) and __attribute__((__constructor__)) work for your purpose.
I'm having this annoying problem.
I'm doing an ios app in objective-c++. I'm coding the backbone of the app in c++ and the UI in objective-c, because the app is most likely going to be ported to Android (maybe also wp) at a later point. The setup works just fine... That is, until I want to include some c/c++ libraries.
The app is going to do a lot of requests to web services and therefore I've decided to include the libcurl library.
I have downloaded the library, configured it and "made" it and it is installing just fine in /usr/local/lib and /usr/local/include. I have added the libcurl.a/libcurl.dylib to the project, but here comes the problem:
When I want to include it in the .h or .cpp (or .mm) file it says that the file is missing fx.
#include "curl/curl.hpp" // -or similar according to library, always returns "file not found"
The intellisense is also not suggesting the files/libraries when typing. I have also tried with the libcurlpp and Poco libraries which all installs just fine and are added to the project just fine (via Build phases -> Link Binaries with Libraries), but is not recognized in the code.
I have also build libcurl specific for ios via this link:
http://home.comcast.net/~seiryu/libcurl-ios.html
and again everything is working regarding building and installing the library, but again I can't include it in the code...
I really hope it's just because I'm retarded at this and that it is some sort of setting I have missed or don't know about. Searched all over the web now and tried different solutions, all with the same result. I must be including the libraries wrong in some way...?
P.S. I've also tried adding the OS provided libcurl.4.dylib, with same result. Can't include it in the code.
Has anyone used Bluetooth on Mac OS X with Lazarus or FreePascal? There is a bluetooth unit, but it currently only supports Linux.
Information about existing unit:
http://wiki.freepascal.org/Bluetooth
I plan to enhance this to support Mac OS, but it would be nice to know if anyone has written any code to use BlueTooth on Mac OS already to avoid duplicated work.
On the other hand, if you have used XCode to access Bluetooth, what libraries did you use? I am sure I can discover this with the XCode profiler by opening some Bluetooth applications.
Note: Mac OS X doesn't appear to use the BlueZ library that Linux has, so I don't think the solution is as easy as changing the library path. Instead, it has IOBluetooth "Framework", located at /System/Library/Frameworks/IOBluetooth.framework.
Having a look, it looks like:
kaikei.ocn.ntt.com:IOBluetooth.framework $ file *
CodeResources: XML document text
Headers: directory
IOBluetooth: Mach-O universal binary with 3 architectures
IOBluetooth (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64
IOBluetooth (for architecture i386): Mach-O dynamically linked shared library i386
IOBluetooth (for architecture ppc7400): Mach-O dynamically linked shared library ppc
Resources: directory
Versions: directory
On the other hand, I think if anyone had done this already, I would probably be able to find it on Google.... On the off chance I am wrong, please reply and let me know.
Clarification: I have created bindings for normal shared libraries before (f.e. sqlite3), but not for a "framework". If nobody has created bindings or otherwise used the MacOS Bluetooth framework from FreePascal, advice on how to use framework functions from FreePascal in general woule be appreciated. (And normally the functions I am porting are C based, not Obj-C, so I am not sure how to declare Obj-C methods in FPK, although I am sure I will be able to find some samples if I keep searching).
The main svn repository for translated Mac OS X framework C headers is http://svn.freepascal.org/svn/macosxintf/trunk
From time to time, FPC releases are synchronised with the latest versions hosted there. Note that the files in that repository (in the MPPInterfaces subdirectory) are in a generic format that can be automatically translated into either FPC, GPC or CodeWarrior Pascal versions.
To generate the FPC versions, use "make fpcpinterfaces", and find the results in the Build/FPCPinterfaces folder.
To translate new headers, execute something like this from inside a checked out copy of the macosxintf repository:
./Scripts/Convert.pl /System/Library/Frameworks/IOBluetooth.framework/Headers/IOBluetooth.h FORCE MPPInterfaces
Afterwards, you'll still have to edit the resulting file to add/remove units and clean up some other things not handled by the automatic translation process. Once finished, you may want to submit a bug report at bugs.freepascal.org with the finished units.
(note: because I'm unregistered, I can only add in one url per post, so the next url's are a bit mangled to get around that restriction)
You can also subscribe to the Mac Pascal list (lists.sonic.net/mailman/listinfo/mac-pascal) and ask there whether someone already translated those headers.
The Bluetooth framework indeed also contains some Objective-C headers. Objective-Pascal support is only available in the latest FPC svn versions, as described on the FPC wiki (google FPC_PasCocoa). You need this support in order to interface with Objective-C.
Translating Objective-C is probably easiest using the script elsewhere in FPC's svn (svn.freepascal.org/svn/fpc/trunk/packages/cocoaint/utils/)
You may want to ask for help on the above-mentioned Mac Pascal list, as all people maintaining the aforementioned translations and translation tools are subscribed there.