I am porting some code from AIX to Linux I am getting compilations errors for undefined symbols TRUE and FALSE. They are not defined in the source code and I dont have access to AIX system. Are these symbols defined in headers of xlc compiler ?
Yes, TRUE and FALSE are defined in some headers on AIX (unrelated to xlc though). Examples: cur01.h, curses.h, im.h, ntbl.h, piostruct.h, IN/standard.h, rpc/types.h, sys/audio.h
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 have a library that interfaces against ImageMagick 6. During compilation I get the below compilation warnings (promoted to errors by me).
I am aware that explicitly defining these values during compilation using -DMAGICKCORE_QUANTUM_DEPTH=16 -DMAGICKCORE_HDRI_ENABLE=0 will solve the issue (on my specific installation), however, as I am writing my CMake configuration files to be as portable as I can make them, this feels way to brittle and I really hope there is a better way.
Which brings me back to my question: Is there a way to determine MAGICKCORE_HDRI_ENABLE and MAGICKCORE_QUANTUM_DEPTH using cmake, bash or similar for the specific version of the library I am linking against?
/usr/include/ImageMagick-6/magick/magick-config.h:29:3: error: #warning "you should set MAGICKCORE_QUANTUM_DEPTH to sensible default set it to configure time default" [-Werror=cpp]
# warning "you should set MAGICKCORE_QUANTUM_DEPTH to sensible default set it to configure time default"
^
/usr/include/ImageMagick-6/magick/magick-config.h:30:3: error: #warning "this is an obsolete behavior please fix your makefile" [-Werror=cpp]
# warning "this is an obsolete behavior please fix your makefile"
^
/usr/include/ImageMagick-6/magick/magick-config.h:52:3: error: #warning "you should set MAGICKCORE_HDRI_ENABLE to sensible default set it to configure time default" [-Werror=cpp]
# warning "you should set MAGICKCORE_HDRI_ENABLE to sensible default set it to configure time default"
^
/usr/include/ImageMagick-6/magick/magick-config.h:53:3: error: #warning "this is an obsolete behavior please fix yours makefile" [-Werror=cpp]
# warning "this is an obsolete behavior please fix yours makefile"
^
cc1plus: all warnings being treated as errors
While writing the question I came across an answer to this. I'll summarize it here as the other questions regarding this angle it slightly differently.
Imagemagick ships with an utility called Magick++-config on my installation (Ubuntu 16.04) I found this utility under /usr/lib/x86_64-linux-gnu/ImageMagick-6.8.9/bin-Q16/Magick++-config. Below is the cmake code snipped I ended up using to extract the relevant build options.
find_package(ImageMagick 6.7 COMPONENTS Magick++ MagickCore)
if(ImageMagick_FOUND)
# Find Imagemagick Library directory
get_filename_component(MAGICK_LIB_DIR ${ImageMagick_MagickCore_LIBRARY} DIRECTORY)
# Find where Magick++-config lives
file(GLOB_RECURSE MAGICK_CONFIG FOLLOW_SYMLINKS ${MAGICK_LIB_DIR}/Magick++-config)
# Ask about CXX and lib flags/locations
set(MAGICK_CONFIG ${MAGICK_CONFIG} CACHE string "Path to Magick++-config utility")
execute_process(COMMAND "${MAGICK_CONFIG}" "--cxxflags" OUTPUT_VARIABLE MAGICK_CXX_FLAGS)
execute_process(COMMAND "${MAGICK_CONFIG}" "--libs" OUTPUT_VARIABLE MAGICK_LD_FLAGS)
# Add these to cache
set(MAGICK_CXX_FLAGS "${MAGICK_CXX_FLAGS}" CACHE string "ImageMagick configuration specific compilation flags." )
set(MAGICK_LD_FLAGS "${MAGICK_LD_FLAGS}" CACHE string "ImageMagick configuration specific linking flags.")
# Split into list:
string(REGEX MATCHALL "([^\ ]+)" MAGICK_CXX_FLAGS "${MAGICK_CXX_FLAGS}")
string(REGEX MATCHALL "([^\ ]+)" MAGICK_LD_FLAGS "${MAGICK_LD_FLAGS}")
# Remove trailing whitespace (CMAKE warns about this)
string(STRIP "${MAGICK_CXX_FLAGS}" MAGICK_CXX_FLAGS)
string(STRIP "${MAGICK_LD_FLAGS}" MAGICK_LD_FLAGS)
target_compile_options(<project> ${MAGICK_CXX_FLAGS})
target_link_libraries(<project> ${MAGICK_LD_FLAGS})
endif(ImageMagick_FOUND)
Source
I have added libpng to my application. If I build for simulator, everything is OK. When I build application for device, I got linker error:
Undefined symbols for architecture armv7: "_png_init_filter_functions_neon", referenced from: _png_read_filter_row in libpng-arm7-release.a(pngrutil.o)
I have build libpng manually from source, same way for simulator and device (only with changed target of compilation). I have tried to find this problem, but noone seems to post anything about this problem.
I "solved" this by replacing lines 117-121 in libpng's pngpriv.h:
# ifdef __ARM_NEON__
# define PNG_ARM_NEON_OPT 2
# else
# define PNG_ARM_NEON_OPT 0
# endif
by
#define PNG_ARM_NEON_OPT 0
This disables ARM's NEON optimizations, which seems to be the cause of the problem.
This is merely a workaround though, I didn't have time to investigate the real cause of the problem further.
Adding to PSyton's comment, here is how we solved it.
Compile the arm/*.c files. This however does only work for Android. For iOS, we additionally had to create a new pnglibconf.h with the entries:
#undef PNG_ARM_NEON_API_SUPPORTED
#undef PNG_ARM_NEON_CHECK_SUPPORTED
#define PNG_ARM_NEON_OPT 0
Looking at the ARM defines in libpng, it seems like they are a bit buggy currently, as PNG_ARM_NEON_API_SUPPORTED should be sufficient to turn NEON compilation off.
I experienced a similar error on macOS.
After getting libpng from the source
https://sourceforge.net/projects/libpng/files/
and compiling with the PNG_ARM_NEON option off, the error disappeared.
I'm trying to debug an objective C program. It used to run, and I'm not sure what changes could have broken it, but it no longer runs at all. In the debugger, I now get:
.
.
.
unable to read unknown load command 0x80000022
unable to read unknown load command 0x80000022
unable to read unknown load command 0x80000022
Program loaded.
sharedlibrary apply-load-rules all
run
Error calling thread_get_state for GP registers for thread 0x16131lx506^error,msg="error on line 207 of \"/SourceCache/gdb/gdb-908/src/gdb/macosx/i386-macosx-nat-exec.c\" in function \"fetch_inferior_registers\": (os/kern) invalid argument (0x4)\n"
I've seen several places that claim te explain the 1st warning, but none of them seem appropriate. Nothing online claims to explain the error.
Any clues as to what these errors mean in conjunction?
ETA: I just upgraded to 10.6, so it may have started then, although I'm compiling to target 10.4...
Is this relevant? From the Xcode release notes:
Note: GCC 4.2 cannot be used with the
Mac OS X 10.4u SDK. If you want to
build targets using the 10.4u SDK on
Xcode 3.2, you must set the Compiler
Version to GCC 4.0
I am trying to comple mod_auth_kerb for apache on mac os x 10.5.7. I get no compilation errors, but when apache tries to load it:
org.apache.httpd[95092]: httpd: Syntax error on line 160 of /private/etc/apache2/httpd.conf: Cannot load /usr/libexec/apache2/mod_auth_kerb.so into server: dlopen(/usr/libexec/apache2/mod_auth_kerb.so, 10): no suitable image found. Did find:\n\t/usr/libexec/apache2/mod_auth_kerb.so: mach-o, but wrong architecture
I have tried the following in the make file:
ARCHFLAGS='-arch ppc64'
CPPFLAGS = -I. -Ispnegokrb5 $(KRB5_CPPFLAGS) $(KRB4_CPPFLAGS) $(DEFS) -mpowerpc64 -mcpu=G5 -mtune=G5 -arch ppc64
LDFLAGS = $(KRB5_LDFLAGS) $(KRB4_LDFLAGS) $(LIB_resolv) -mpowerpc64 -mcpu=G5 -mtune=G5 -arch ppc64
CFLAGS = -mpowerpc64 -mcpu=G5 -mtune=G5 -arch ppc64
I have looked in these threads:
http://lists.apple.com/archives/unix-porting/2008/Mar/msg00061.html
http://objectmix.com/apache/690208-re-mod_auth_kerb-mac-os-x-10-5-client.html
I also changed this in the source:
from
krb5_rc_resolve_full
to
__KerberosInternal_krb5_rc_resolve_full
I cannot get apache to load it and it claims it is the wrong architecture. I think apache is 64 bit from the ground up in this version of mac server so that is probably the problem. I just don't know how to get through it.
Line 160 is a red herring in the httpd.conf file (it has ##).
I don't know how to compile it correctly and was hoping for help.
I have a G5 PPC 64.
Thank you.
EDIT:
What is odd is this:
otool -hv mod_auth_kerb.so mod_auth_kerb.so: Mach header
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
MH_MAGIC_64 PPC64 ALL 0x00 BUNDLE 10 1328 NOUNDEFS DYLDLINK TWOLEVEL
So I don't know what's wrong.
I am on the PPC64 and that's what it looks like I have compiled.
If i'm following the question correctly, I think you will need to build/install a cross compiling toolchain to build it from PPC to x86_64 or another non-PPC architecture, or even in some cases, PPC to PPC64 and vice-versa.
I would not advise this if you are unfamiliar with GCC, the Unix toolchain and the Darwin foundation stuff in general.
You might be able to find Darwin toolchain setups on the web. Some links in the right direction:
http://lists.apple.com/archives/darwin-development/2002/Dec/msg00062.html
http://ranger.befunk.com/fink/darwin-cross/
http://myownlittleworld.com/miscellaneous/computers/darwin-cross-distcc.html
http://www.google.com/search?q=Darwin+cross+compilation