On Mac OS X using Objective-C 2, plugin bundles can be compiled with one of three garbage collection settings:
Not Supported
Supported (-fobjc-gc)
Required (-fobjc-gc-only)
How can one programmatically query a compiled plugin bundle to determine which of these three settings was used?
It's part of the __OBJC segment but I don't know of any API that exposes it.
Garbage collected:
cristi:tmp diciu$ otool -v -o ./a.out
./a.out:
Contents of (__DATA,__objc_classrefs) section
00000001000010b0 0x0
Contents of (__DATA,__objc_imageinfo) section
version 0
flags 0x6 OBJC_IMAGE_SUPPORTS_GC
Non garbage collected:
cristi:tmp diciu$ otool -v -o ./a.out
./a.out:
Contents of (__DATA,__objc_classrefs) section
00000001000010b0 0x0
Contents of (__DATA,__objc_imageinfo) section
version 0
flags 0x0
The runtime does this using private functions: see gc_enforcer and it's use of * _objcInfoRequiresGC*
Following the answer from diciu, you can use the Mach-O API. You have to parse the segments contained in the binary file and search for the __OBJC one; the segment_command structure allows an access to the segment's flags.
You can also take a look at the ClassDump project. It has a pretty complete Mach-O parser.
It's probably easiest to just try and load the bundle using NSBundle's -loadAndReturnError: method. If the bundle won't load due to the fact that its GC settings are different to those in your app, you'll get an NSExecutableRuntimeMismatchError.
Related
I am trying to build the AWS C++ SDK on Solaris, but I cannot do so successfully.
I found this open issue on the AWS C++ SDK page that says it is possible, but there is no guide on it and I am hoping somebody here can help.
Here is the command I use to build it:
$ cmake ../aws-sdk-cpp/ -DCMAKE_BUILD_TYPE=Debug -DBUILD_ONLY="s3"
Here is the output:
-- TARGET_ARCH not specified; inferring host OS to be platform compilation target
-- Building AWS libraries as shared objects
-- Generating linux build config
-- Building project version: 1.7.134
-- Configuring done
-- Generating done
-- Build files have been written to: /workspace/dmoini/sdk_build/.deps
gmake: Warning: File 'Makefile' has modification time 267 s in the future
gmake[1]: Warning: File 'CMakeFiles/Makefile2' has modification time 267 s in the future
gmake[2]: Warning: File 'CMakeFiles/AwsCCommon.dir/progress.make' has modification time 267 s in the future
gmake[2]: warning: Clock skew detected. Your build may be incomplete.
gmake[2]: Warning: File 'CMakeFiles/AwsCCommon.dir/progress.make' has modification time 267 s in the future
[ 4%] Performing build step for 'AwsCCommon'
[ 1%] Building C object CMakeFiles/aws-c-common.dir/source/array_list.c.o
In file included from /usr/include/stdio.h:37:0,
from /workspace/dmoini/sdk_build/.deps/build/src/AwsCCommon/include/aws/common/common.h:22,
from /workspace/dmoini/sdk_build/.deps/build/src/AwsCCommon/include/aws/common/array_list.h:18,
from /workspace/dmoini/sdk_build/.deps/build/src/AwsCCommon/source/array_list.c:16:
/opt/gcc-5.1.0/lib/gcc/i386-pc-solaris2.11/5.1.0/include-fixed/sys/feature_tests.h:405:2: error: #error "Compiler or options invalid for pre-UNIX 03 X/Open applications and pre-2001 POSIX applications"
#error "Compiler or options invalid for pre-UNIX 03 X/Open applications \
^
gmake[5]: *** [CMakeFiles/aws-c-common.dir/build.make:63: CMakeFiles/aws-c-common.dir/source/array_list.c.o] Error 1
gmake[4]: *** [CMakeFiles/Makefile2:484: CMakeFiles/aws-c-common.dir/all] Error 2
gmake[3]: *** [Makefile:139: all] Error 2
gmake[2]: *** [CMakeFiles/AwsCCommon.dir/build.make:112: build/src/AwsCCommon-stamp/AwsCCommon-build] Error 2
gmake[1]: *** [CMakeFiles/Makefile2:68: CMakeFiles/AwsCCommon.dir/all] Error 2
gmake: *** [Makefile:84: all] Error 2
CMake Error at CMakeLists.txt:193 (message):
Failed to build third-party libraries.
Additionally, here is my system information:
$ uname -a
SunOS bld-dmoini-01-sv4b 5.11 omnios-r151020-4151d05 i86pc i386 i86pc
Any and all help/guidance is greatly appreciated.
I've successfully completed compiling the AWS C++ SDK on a stock install of Solaris 11.4, and found several issues that could cause the problems noted.
Start with a clean source tree.
Remove -Werror
The first thing do to is remove the -Werror compiler options. The version of OpenSSL installed by default on Solaris 11.4 has quite a few deprecated functions, and the -Werror option causes the build to fail when it runs into those deprecations. I used this find command run from the topmost directory of the AWS SDK source tree to remove all the -Werror options:
vi `find . | xargs grep -l Werror`
You'll get about three or four files, only two of which are actually setting the -Werror as a compiler option. Just remove the "-Werror" strings from those files.
Fix the POSIX defines
Then run cmake . in the topmost directory. It will fail because the cmake files that it downloads will have improper POSIX command-line options - -D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=500. That 500 is wrong. _POSIX_C_SOURCE=200809L corresponds to _XOPEN_SOURCE=700. _XOPEN_SOURCE=500 is SUSv2, circa 1997. It's not proper to compile a SUSv2 application with C99.
Per 2.2.1 Strictly Conforming POSIX Application, paragraph 8:
For the C programming language, shall define _POSIX_C_SOURCE to be 200809L before any header is included
and 2.2.4 Strictly Conforming XSI Application, paragraph 8:
For the C programming language, shall define _XOPEN_SOURCE to be 700 before any header is included
Per the Illumos sys/feature_tests.h file (based on OpenSolaris, which was also the basis for Solaris 11):
* Feature Test Macro Specification
* ------------------------------------------------ -------------
* _XOPEN_SOURCE XPG3
* _XOPEN_SOURCE && _XOPEN_VERSION = 4 XPG4
* _XOPEN_SOURCE && _XOPEN_SOURCE_EXTENDED = 1 XPG4v2
* _XOPEN_SOURCE = 500 XPG5
* _XOPEN_SOURCE = 600 (or POSIX_C_SOURCE=200112L) XPG6
* _XOPEN_SOURCE = 700 (or POSIX_C_SOURCE=200809L) XPG7
The files cmake downloads via git need to be edited:
vi `find .deps | xargs grep -l XOPEN_SOURCE`
Change any -D_XOPEN_SOURCE=500 to -D_XOPEN_SOURCE=700 and rerun cmake .. It should complete successfully this time.
Then run gmake. (I find gmake works much better on Solaris for just about all open source projects, as many open source projects use GNU-specific make extensions.)
Now you get to fix any broken source code you run into.
Fix broken source code
1
The file aws-sdk-cpp/aws-cpp-sdk-core/source/platform/linux-shared/OSVersionInfo.cpp has the following wrong code:
Aws::String ComputeOSVersionString()
{
utsname name;
int32_t success = uname(&name);
Per POSIX, the correct type is struct utsname, not just utsname:
int uname(struct utsname *name);
The AWS code needs to be:
Aws::String ComputeOSVersionString()
{
struct utsname name;
int success = uname(&name);
And no, I'm most certainly not impressed with the quality of the AWS code, given this, umm, laugher:
while (!feof(outputStream))
Yes, an actual while (!feof()) loop...
2
The file aws-sdk-cpp/aws-cpp-sdk-mediaconvert/include/aws/mediaconvert/model/M2tsSegmentationMarkers.h uses an enumeration with the value EBP, which conflicts with the EBP register #define in /usr/include/sys/regset.h.
I just changed it to EBP_HASH as that seems to match the code somewhat:
vi `find . | xargs grep -l EBP`
3
The file aws-sdk-cpp/aws-cpp-sdk-route53domains/include/aws/route53domains/model/CountryCode.h creates an enumeration value ES that conflicts with the ES register #define in /usr/include/sys/regset.h. I just added
#ifdef ES
#undef ES
#endif
and the compile continued. I don't know if that #undef could have broken anything.
4
The file aws-sdk-cpp/aws-cpp-sdk-waf/include/aws/waf/model/GeoMatchConstraintValue.h has ES, GS, and SS enumeration value that conflict with the ES, GS, and SS register #define's in /usr/include/sys/regset.h.
Again, I just added a few more #undef's:
#ifdef ES
#undef ES
#endif
#ifdef GS
#undef GS
#endif
#ifdef SS
#undef SS
#endif
I'm really wondering why sys/regset.h is being #include'd in just about everything in the AWS SDK.
5
Same problem in aws-sdk-cpp/aws-cpp-sdk-waf-regional/include/aws/waf-regional/model/GeoMatchConstraintValue.h. Same fix, add:
#ifdef ES
#undef ES
#endif
#ifdef GS
#undef GS
#endif
#ifdef SS
#undef SS
#endif
Note that compiling on SPARC hardware means the #define value from sys/regset.h will be completely different, and any errors will be completely different.
6
The file aws-sdk-cpp/aws-cpp-sdk-core-tests/utils/FileSystemUtilsTest.cpp incorrectly assumes the POSIX NAME_MAX value is defined. Per the POSIX Pathname Variable Values standard (bolding mine):
Pathname Variable Values
The values in the following list may be constants within an
implementation or may vary from one pathname to another. For example,
file systems or directories may have different characteristics.
A definition of one of the symbolic constants in the following list
shall be omitted from the <limits.h> header on specific
implementations where the corresponding value is equal to or greater
than the stated minimum, but where the value can vary depending on the
file to which it is applied. The actual value supported for a specific
pathname shall be provided by the pathconf() function.
Again: the "definition ... shall be omitted ... where the value can vary".
The AWS code wrongly assumes NAME_MAX must be #define'd.
I just hardcoded a value of 255 to get past this point, although using something like _POSIX_NAME_MAX or _XOPEN_NAME_MAX is probably better.
7
File aws-sdk-cpp/ws-cpp-sdk-core-tests/http/HttpClientTest.cpp seems to be incorrectly assuming a std::shared_ptr will be 8 bytes. This question and answer provides a good example of how that's wrong.
I just ignored this error as it's just a test and continued with gmake -i, which completed successfully outside of this one error.
I'm new to the Nim programming language, and coming from a Lua background, it excited me to find out that there is a module for adding Lua bindings to Nim.
I installed Nimble (Nim's package manager) for Windows and executed "nimble install lua" to download and install the correct module. Upon trying to import it and compile the source, this happened:
C:\Users\Ashley\Desktop\Stuff\Coding\Nim\Projects\LuaTest>nim c -r "C:\Users\Ashley\Desktop\Stuff\Coding\Nim\Projects\LuaTest\main.nim"
Hint: system [Processing]
Hint: main [Processing]
Hint: lua [Processing]
CC: main
CC: lua_lua
Hint: [Link]
Hint: operation successful (10698 lines compiled; 1.262 sec total; 16.163MB; Debug Build) [SuccessX]
could not load: lua(|5.1|5.0).dll
Error: execution of an external program failed: 'c:\users\ashley\desktop\stuff\coding\nim\projects\luatest\main.exe '
I have Lua 5.1 already installed with the proper entries in PATH. It's located in Program Files (x86). The directory contains a dll called lua5.1.dll. I tried looking up the error on Google, but there were no results that helped. What could be the problem?
On Windows you can put the library at the same place as the generated binary. In this case the file should be called lua.dll, lua5.1.dll or lua5.0.dll. Also make sure that the library and binary are both for the same system architecture, either x86 (32bit) or x86-64 (64bit).
The vibration ane by Adobe works well in a Flex mobile app both on iOS and Android, but when I try to launch an AIR simulator from Flash Builder 4.7 on Windows 7 I get the error:
Here a copy of the error message from the latter screenshot:
Process terminated without establishing connection to debugger.
The content cannot be loaded because there was a problem loading an extension: Error: Requested extension com.adobe.Vibration is not supported for Windows-x86.
Launch command details: "C:\Program Files\Adobe\Adobe Flash Builder 4.7 (64 Bit)\sdks\4.6.0 (AIR 3.5)\bin\adl.exe" -runtime "C:\Program Files\Adobe\Adobe Flash Builder 4.7 (64 Bit)\sdks\4.6.0 (AIR 3.5)\runtimes\air\win" -profile extendedMobileDevice -screensize 640x920:640x960 -XscreenDPI 326 -XversionPlatform IOS -extdir "C:\Users\xxx\Adobe Flash Builder 4.7\.metadata\.plugins\com.adobe.flexbuilder.project.ui\ANEFiles\MyApp-Mobile\win32\" C:\Users\xxx\Documents\MyApp\mobile\bin-debug\MyApp-app.xml C:\Users\xxx\Documents\MyApp\mobile\bin-debug
At the same time:
Another ANE by Adobe - the GameCenter.ane included with Adobe Gaming SDK works flawlessly with the AIR Simulator
The com.adobe.extensions.Vibration.ane mentioned above doesn't fail when I select the BlackBerry AIR simulator (but the iOS and Android AIR Simulators do not work).
Is there a way to make this work more comfortable?
I'd like to use the com.adobe.extensions.Vibration.ane in my Flex mobile app, but I also want to use the AIR simulator - without commenting the source code and removing that ANE from project properties.
UPDATE 2016:
Adobe has updated their Vibration native extension (ANE) sample with 64-bit support.
The problem with the ANE is that it's not a complete implementation. Most importantly the ANE doesn't implement a default fallback implementation which is what the device would fallback to if there wasn't a particular implementation for the current platform.
This makes the ANE very hard to use in cross-platform development as it will fail in some cases. Any platform that isn't specifically included will fail with the message you received.
Basically without changing the ANE yourself you won't be able to use it as you are expecting. Your only way is to do some conditional style compilation and not call the ANE in the simulator.
If you do wish to change the ANE then the best option is to implement the default library. This is quite simple, but you will need: XCode, eclipse with Android dev tools, and adt from the AIR SDK.
Firstly you'll need to compile the existing projects, the Android lib, the iOS lib and the existing actionscript library, to generate VibrationAndroidLibrary.jar, libVibrationiOSLibrary.a and VibrationActionScriptLibrary.swc respectively.
You'll then need to make another actionscript library, and duplicate the com.adobe.nativeExtensions.Vibration class as below:
public class Vibration
{
public function Vibration()
{
}
public static function get isSupported():Boolean
{
return false;
}
public function vibrate(duration:Number):void
{
}
}
This class will replace the other class in cases where the extension isn't implemented instead of you getting the above message.
Then we'll need to add the default definition to the extension.xml file:
<extension xmlns="http://ns.adobe.com/air/extension/2.5">
<id>com.adobe.Vibration</id>
<versionNumber>1</versionNumber>
<platforms>
<platform name="Android-ARM">
<applicationDeployment>
<nativeLibrary>VibrationAndroidLibrary.jar</nativeLibrary>
<initializer>air.extensions.VibrationExtension</initializer>
<finalizer>air.extensions.VibrationExtension</finalizer>
</applicationDeployment>
</platform>
<platform name="iPhone-ARM">
<applicationDeployment>
<nativeLibrary>libVibrationiOSLibrary.a</nativeLibrary>
<initializer>ExtInitializer</initializer>
<finalizer>ExtFinalizer</finalizer>
</applicationDeployment>
</platform>
<platform name="default">
<applicationDeployment />
</platform>
</platforms>
</extension>
Then we'll need to recompile the ANE using the new default actionscript SWC. Lets say you're in the VibrationNEDeliverables directory from the mentioned ANE, you can enter this into a bash file and run it or put it all on one line from the command line). The first couple of lines just extract the library.swf file and move it to the locations needed by the package command. Be careful with the paths etc here, I've assumed you've put the default lib in VibrationActionScriptDefaultLibrary but you'll need to change this appropriately.
unzip -o -d VibrationActionScriptLibrary/bin VibrationActionScriptLibrary/bin/VibrationActionScriptLibrary.swc
unzip -o -d VibrationActionScriptDefaultLibrary/bin VibrationActionScriptDefaultLibrary/bin/VibrationActionScriptDefaultLibrary.swc
cp VibrationActionScriptLibrary/bin/library.swf VibrationiOSLibrary/build/Release-iphoneos/.
cp VibrationActionScriptLibrary/bin/library.swf VibrationAndroidLibrary/bin/.
adt -package \
-storetype pkcs12 -keystore YOUR_SIGNING_KEY.p12 -storepass KEY_PASSWORD \
-target ane com.adobe.extensions.Vibration.ane VibrationActionScriptLibrary/src/extension.xml \
-swc VibrationActionScriptLibrary/bin/VibrationActionScriptLibrary.swc \
-platform iPhone-ARM -C VibrationiOSLibrary/build/Release-iphoneos . \
-platform Android-ARM -C VibrationAndroidLibrary/bin . \
-platform default -C VibrationActionScriptDefaultLibrary/bin .
Once that's complete you should now have a new version of the ANE with a default lib which will make it much more useable! Personally I don't think an ANE should be released without it.
If you need a fully functional ANE, you can check out ours: http://distriqt.com/native-extensions
A solution that I've used in the past was something like this:
Create a utility class that returns whether you're running on a device that supports the ANE. In my case, the class contained a static method that checked the value of Capabilities.os. See the list of values it can return here.
Put the code that calls the ANE method(s) into their own function, and call this function if the ANE is supported. If I recall correctly, it was necessary to put the code that used the ANE in a separate function, not just inside an if block, otherwise the same error would occur in the simulator:
Do this:
public function doSomethingThatWillUseANE():void
{
if (DeviceCapabilities.supportsANE) // static utility class
{
methodThatUsesANE();
}
}
private function methodThatUsesANE()
{
// execute actual ANE method here
}
Instead of doing it all in one function like this:
public function doSomethingThatWillUseANE():void
{
if (DeviceCapabilities.supportsANE) // static utility class
{
// execute actual ANE method here
}
}
same problem exists with the newest vibration ane built for ios 64bit compatibility. My workaround was to place the ane import statement inside the function that actually called the vibrate method, and uncheck the include box for the ane in the project build path settings for android and ios.
I have a flag variable (set by a separate function) in my application that flags whether the app is being run within the ide. The view that uses vibration will only call the above vibration function if the flag is set to non-IDE mode. I still get an initial warning when I run the ide simulator, but not the critical error. When I do a release build, FlashBuilder forces me to checkmark the include box for the ane in the applicable project build path settings (I have to uncheck it again next time I want to run the simulator).
It's clunky, but it makes working with the ane liveable. Peeves me to no end that adobe hasn't addressed this.
I have two Free Pascal units that I would like to use from a C program on linux.
Here is what I do:
$ fpc -fPIC base64.pas queueutils.pas
Warning: Only one source file supported
Free Pascal Compiler version 2.2.2 [2008/11/05] for x86_64
Copyright (c) 1993-2008 by Florian Klaempfl
Target OS: Linux for x86-64
Compiling queueutils.pas
queueutils.pas(2088,11) Warning: Symbol "Socket" is deprecated
queueutils.pas(2097,10) Warning: Symbol "Connect" is deprecated
queueutils.pas(2104,3) Warning: Symbol "Sock2Text" is deprecated
2432 lines compiled, 0.5 sec
4 warning(s) issued
$ ppumove -o queueutils -e ppl *.ppu
PPU-Mover Version 2.1.1
Copyright (c) 1998-2007 by the Free Pascal Development Team
Processing base64.ppu... Done.
Processing queueutils.ppu... Done.
Linking queueutils.o base64.o
Done.
Seems fine so far, libqueueutils.so is created:
$ file libqueueutils.so
libqueueutils.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped
$ ldd libqueueutils.so
ldd: warning: you do not have execution permission for `./libqueueutils.so'
statically linked
However when the C program tries to use the library this way:
libqueue = dlopen("./libqueueutils.so", RTLD_LAZY);
if (!libqueue) {
fprintf (stderr, "%s\n", dlerror());
}
it yields an error message:
$ ./tmbrkr
./libqueueutils.so: undefined symbol: VMT_PROCESS_TPROCESS
This VMT_PROCESS_TPROCESS-related error is resolved if I add process.o and process.ppu to the linking process done by ppumove. However after doing so another unit is missing and after that another... You get it.
Is there a way to somehow link all the necessary units together in one .so file so that the C program can dlopen() the library properly?
Just like a normal binary (exe) is from a "program" source file , a .so/dll is created from a ''library'' sourcefile.
For the rest is the model is the same. You simply build the library mainprogram, and the compiler collects all units necessary and stuffs them in the .so.
With the exports keyword you can define what symbols to export.
library testdll;
uses x,y,z;
// define exportable symbols here
// some examples of symbol exports
exports
P1 index 1, // dll based on index
P2 name 'Proc2', // normal export with alternate external symbol
P3, // just straight export.
P4 resident // for some MCU use
;
begin
// startup code
end.
Also look up $soname $libsuffix and $libprefix in the manual.
Though I would recommend just using most recent 2.6.0, not some 5 year old 2.2.2
It might require recompiling FPC first with PIC though.
I have software that first loads a .dylib lets call libFirst.dylib using the following command:
void* handle = dlopen(path.c_str(), RTLD_LAZY | RTLD_GLOBAL);
Later on inside a function from the loaded libFirst.dylib I attempt to load another .dylib using the same command but for libSecond.dylib, the loading of this shared library gives me the following warnings in my Xcode console:
error warning: Ignored unknown object module at 0x129310 with type 0x8a8399
dlerror: dlopen(/path/libSecond.dylib, 9): Library not loaded: libFirst.dylib
Referenced from: /path/libSecond.dylib
Reason: image not found
What I don't get is that its says libFirst.dylib is not loaded but I am currently inside a function from libFirst.dylib, so how can this be?
All my paths in DYLD_LIBRARY_PATH appear correct too.
Thanks in advance, I have been stuck on this for days.
I ended up using -install_name to change the install name of all my libraries to #rpath/dylibName.dylib and then in Xcode I set the Runpath Search paths using #loader_path to find all my .dylibs that I was using.
use:
install_name_tool -id #executable_path/../Frameworks/mylib.dylib mylib.dylib
then check it with:
otool -D mylib.dylib
I think an easier way to get around this error would be to revert to an earlier version where you were not getting this error. Right click on the project folder and navigate to local history to revert to an earlier version. I verified this to be working on the android studio installed on Mac OS Big sur.