I include the amalgamation sqlite code in my iPhone project, and remove the reference to the iPhone sqlite framework.
My main target compile fine.
I have a second target for unit testing with the google framework. When compile I get:
error: syntax error before '#' token
I don't understand why. I have set both projects to sdk 2.
UPDATE: I include the link to the sqlite code & google. I must add that the target compile just fine for months before I added the sqlite code. I don't post sample code because I get 1263 errors - so I get error in all files -, but this is a sample traceback:
#class NSString, Protocol; <== ERROR HERE
Traceback:
cd /Users/trtrrtrtr/mamcx/projects/JhonSell/iPhone
setenv PATH "/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin:/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin"
/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/gcc-4.0 -x c-header -arch i386 -fmessage-length=0 -pipe -std=c99 -Wno-trigraphs -fpascal-strings -fasm-blocks -O0 -Wreturn-type -Wunused-variable -D__IPHONE_OS_VERSION_MIN_REQUIRED=20000 -isysroot /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator2.2.1.sdk -fvisibility=hidden -mmacosx-version-min=10.5 -gdwarf-2 -iquote /Users/trtrrtrtr/mamcx/projects/JhonSell/iPhone/build/JhonSell.build/Debug-iphonesimulator/Testing.build/Testing-generated-files.hmap -I/Users/trtrrtrtr/mamcx/projects/JhonSell/iPhone/build/JhonSell.build/Debug-iphonesimulator/Testing.build/Testing-own-target-headers.hmap -I/Users/trtrrtrtr/mamcx/projects/JhonSell/iPhone/build/JhonSell.build/Debug-iphonesimulator/Testing.build/Testing-all-target-headers.hmap -iquote /Users/trtrrtrtr/mamcx/projects/JhonSell/iPhone/build/JhonSell.build/Debug-iphonesimulator/Testing.build/Testing-project-headers.hmap -F/Users/trtrrtrtr/mamcx/projects/JhonSell/iPhone/build/Debug-iphonesimulator -F/Volumes/CrashReporter-1.0-rc2/CrashReporter-iPhone -F/Users/trtrrtrtr/mamcx/projects/JhonSell/iPhone -I/Users/trtrrtrtr/mamcx/projects/JhonSell/iPhone/build/Debug-iphonesimulator/include -I/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator2.2.1.sdk/usr/include/libxml2 "-I/Developer/RemObjects Software/Source" -I/Users/trtrrtrtr/mamcx/projects/JhonSell/iPhone/build/JhonSell.build/Debug-iphonesimulator/Testing.build/DerivedSources/i386 -I/Users/trtrrtrtr/mamcx/projects/JhonSell/iPhone/build/JhonSell.build/Debug-iphonesimulator/Testing.build/DerivedSources -c /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator2.2.1.sdk/System/Library/Frameworks/UIKit.framework/Headers/UIKit.h -o /var/folders/EA/EAmC8fuyElexZfnpnjdyr++++TI/-Caches-/com.apple.Xcode.501/SharedPrecompiledHeaders/UIKit-dqqtnrciylhdtjbmyglpcezxchmz/UIKit.h.gch
In file included from /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator2.2.1.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:12,
from /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator2.2.1.sdk/System/Library/Frameworks/UIKit.framework/Headers/UIAccelerometer.h:8,
from /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator2.2.1.sdk/System/Library/Frameworks/UIKit.framework/Headers/UIKit.h:9:
/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator2.2.1.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSObjCRuntime.h:120:
error: syntax error before '#' token
I finally figure out the problem.
I copy this from the iPhone target to the Testing target:
GCC_DYNAMIC_NO_PIC = NO
GCC_OPTIMIZATION_LEVEL = 0
GCC_PRECOMPILE_PREFIX_HEADER = YES
GCC_PREFIX_HEADER = JhonSell_Prefix.pch
GCC_PREPROCESSOR_DEFINITIONS = DEBUG
But why before I have not issues? I truly not understand.
With very little to go on, my guess would be including an Objective C header from a C/C++ implementation file, hence compiling the header in C/C++ instead of Objective C/Objective C++.
Looking at your updated information, you are actually compiling a header file, namely UIKit.h. The compiler has no idea what type of header file it is, so it defaults to C, which of course does not have #class and hence the syntax error.
So you will have to figure out why Xcode wants to compile UIKit.h in your second target.
Your gcc command line is compiling a .h file to a .gch file.
/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/gcc-4.0
# ...
-x c-header -arch i386 -fmessage-length=0 -pipe -std=c99 -Wno-trigraphs # ...
# ...
# THE INPUT FILE:
/Developer/Platforms/iPhoneSimulator.platform/Developer/
SDKs/iPhoneSimulator2.2.1.sdk/System/Library/Framework/
UIKit.framework/Headers/UIKit.h
# THE OUTPUT FILE:
-o /var/folders/EA/EAmC8fuyElexZfnpnjdyr++++TI/
-Caches-/com.apple.Xcode.501/
SharedPrecompiledHeaders/UIKit-dqqtnrciylhdtjbmyglpcezxchmz/UIKit.h.gch
I.e. UIKit.h into UIKit.h.gch: translating a header file into a "precompiled" header that can be included faster because it is in a tokenized form.
Looks like the compiler doesn't know it's supposed to be precompiling a header; it is configured incorrectly somehow, and is just treating that as code to be actually compiled, and choking because the code is Objective C.
Related
I am trying to compile for a gd32v chip using gcc(the riscv version on the arch community repo).
Compiling seems to work fine, however when trying to link the objects into an elf file, I get the error:
Linking ELF target: main.elf
riscv64-linux-gnu-g++ #_linker_flags -o main.elf ../../bmptk-RISC-V/targets/risc_v/gd32v/gd32vf103xb_boot.o hwlib.o main.o ../../bmptk-RISC-V/targets/risc_v/GD32VF103_standard_peripheral/Source/gd32vf103_rcu.o ../../bmptk-RISC-V/targets/risc_v/GD32VF103_standard_peripheral/Source/gd32vf103_gpio.o ../../bmptk-RISC-V/targets/risc_v/GD32VF103_standard_peripheral/system_gd32vf103.o bmptk_heap_none.o bmptk_fixed_size_stack.o -Os -Tmain.ld
/usr/lib/gcc/riscv64-linux-gnu/10.2.0/../../../../riscv64-linux-gnu/bin/ld: /usr/lib/gcc/riscv64-linux-gnu/10.2.0/../../../../riscv64-linux-gnu/lib/libstdc++.so: error adding symbols: file in wrong format
collect2: error: ld returned 1 exit status
make: *** [../../bmptk-RISC-V/Makefile.inc:1498: main.elf] Error 1
In this make rule, I am using a file '_linker_flags' for my linker flags, to keep the terminal clean during compilation. The contents of this file are as follows:
-march=rv32imac -mabi=ilp32 -Os -fdata-sections -ffunction-sections -I../../bmptk-RISC-V/targets/risc_v/ -I../../bmptk-RISC-V/targets/risc_v/GD32VF103_standard_peripheral -I../../bmptk-RISC-V/targets/risc_v/GD32VF103_standard_peripheral/Include -I../../bmptk-RISC-V/targets/risc_v/RISCV/drivers -I../../bmptk-RISC-V/targets/risc_v -I/usr/include -I/usr/include -I../../hwlib-RISC-V/library -I../../Catch2/single_include -I../../Catch2/single_include/catch2 -I../../boost_1_69_0 -I../../bmptk-RISC-V -I../../bmptk-RISC-V/targets -I../../bmptk-RISC-V/targets/risc_v -I../../bmptk-RISC-V/targets/risc_v/RISCV -I../../bmptk-RISC-V/targets/risc_v/RISCV/drivers -DHWCPP_FAKE_OSTREAM -DBMPTK_TARGET=gd32vf103v -DBMPTK_TARGET_gd32vf103v -DHWLIB_TARGET_gd32vf103v -DHWCPP_TARGET_gd32vf103v -DGF_TARGET_gd32vf103v -DBMPTK_CHIP=gd32vf103v -DBMPTK_CHIP_gd32vf103v -DBMPTK_XTAL= -DBMPTK_BAUDRATE=38400 -DHWLIB_BAUDRATE=38400 -DGODAFOSS_BAUDRATE=38400 -DGF_BAUDRATE=38400 -DBMPTK_VERSION=V04_00_work_in_progress_2020_05_23 -DBMPTK_EMBEDDED -lgcc -Wl,-Map,main.map -Wl,--gc-sections -Wl,-fatal-warnings
I'm not familiar with this error, does anyone know what I would have to look into to fix this?
EDIT:
I asked a teacher at school and they told me that the problem most likely arised from using a mismatching linker and compiler, or that some object files weren't cleaned when calling make. I made sure all objects were deleted before compiling and made sure the compiler and linker were the same.
They should be the same. I am running riscv64-linux-gnu-ld version 2.35 and riscv64-linux-gnu-g++ version 10.2.0. Both are from the arch community repository.
To see exactly the mapping/switches of the libraries supported by your compiler you can use : riscv64-linux-gnu-g++ -print-multi-lib. If you compiler was compiled with multilib enabled you can choose an rv32 libs without hard float otherwise it will not link also since you are compiler for rv32imac.
If your compiler was build without the multlib option you have two option:
Compile with -nostdlib and provide the needed file to the linker crt, libc libgcc ... or you can get a compiler which was build with multilib enabled.
I have a C++ project. I am testing a cross-compile with Autotools on OS X for iOS. I configure with:
$ echo $IOS_SYSROOT
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS8.2.sdk
$ CXXFLAGS="-DNDEBUG -g2 -O3 -arch arm64" ./configure --with-sysroot="$IOS_SYSROOT" --build=`config.guess` --host=aarch64-ios
When make'ing it results in (line breaks added for clarity):
libtool: compile: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
-DHAVE_CONFIG_H -I. ... -DNDEBUG -g2 -O3 -arch arm64 -MT adhoc.lo -MD -MP -MF .deps/adhoc.Tpo -c adhoc.cpp -o adhoc.o
In file included from adhoc.cpp:2:
In file included from /usr/include/c++/4.2.1/iosfwd:44:
In file included from /usr/include/c++/4.2.1/bits/c++config.h:41:
In file included from /usr/include/c++/4.2.1/bits/os_defines.h:61:
In file included from /usr/include/unistd.h:71:
In file included from /usr/include/_types.h:27:
In file included from /usr/include/sys/_types.h:32:
/usr/include/sys/cdefs.h:658:2: error: Unsupported architecture
#error Unsupported architecture
...
Notice the wrong header files are being used. The build system's headers are used rather than the iPhone headers. I'm fairly certain --with-sysroot is not being honored. Searching for the keywords seems to indicate its a widespread problem with Autoconf (based on all the bug reports trying to use the feature).
Manually adding CXXFLAGS="-sysroot=$IOS_SYSROOT -arch arm64 ... seems to fix the issue. This seems to be the same problem (or nearly the same problem) detailed at Bug 79885: --with-build-sysroot= does not get honored throughout the build.
There does not seem to be a AC_SYSROOT (or similar) to copy --with-sysroot into AM_CXXFLAGS. Searching the Autoconf site for the keywords is not returning useful hits: "--with-sysroot" site:https://www.gnu.org/software/autoconf/manual.
How are we supposed to handle Autoconf's --with-sysroot option? What is the practice packagers are supposed to follow?
Here are the Autoconf prject files: cryptopp-autotools. There are two files of interest, and they are configure.ac and Makefile.am. I'm not sure what applies to this problem at the moment.
Here's the message where Autoconf tells users to use it:
$ ./configure --help | grep sysroot
--with-sysroot[=DIR] Search for dependent libraries within DIR (or the
compiler's sysroot if not specified).
I'd prefer to supress the message if Autoconf cannot wire-in --with-sysroot properly. Otherwise, users are going to be filling bug reports against us.
Am trying to compile a large C++ project in a simulated 32bits environment (cel5.03-i386-2.3) on a 64bits machine. (The compiling worked well on 32bits machine before)
During this compiling some files fail as below. The weird thing is that the argument passed to g++ command is "--sysroot=" while in error message it becomes "-fsysroot=".
Why could this happen?
/usr/bin/g++ -MMD -MF /proj/src/.debug/lib/osiris/core/utils/WWNConverter.d -I/proj/src/lib/osiris -DDEBUG_LOG -DDEBUG -D_REENTRANT -DAPE_MODE -DSWAT_MODE -g -Werror -Wall -Wno-write-strings -fPIC -m32 --sysroot=/auto/andpkg/rep_cache//wr-x86/3.0FCS/sysroot -rdynamic -I/proj/src -I/proj/src/.debug/include/private -I/proj/src/.debug/include/public -I/proj/src/lib/framework -I/proj/src/lib/osiris -I/proj/src/lib/prt -I/proj/src/lib/callhome -I/proj/src/lib/snmp -I/proj/src/.debug/external/pcre/include -I/proj/src/external/sqlite/include -I/proj/src/external/openssl/openssl-fips-1.2.3/include -I/proj/src/support/storage-driver/include -I/proj/src/external/json/include -DTARGET_OBJECT=libosiris.so -I/proj/src/.debug/external/pcre/include -I/proj/src/.debug/external/libcurl/include -o /proj/src/.debug/lib/osiris/core/utils/WWNConverter.o -c /proj/src/lib/osiris/core/utils/WWNConverter.cc
make[1]: *** [/proj/src/.debug/lib/osiris/core/utils/WWNConverter.o] Error 1
cc1plus: error: unrecognized command line option "-fsysroot=/auto/andpkg/rep_cache//wr-x86/3.0FCS/sysroot"
The 32-bit compiler (GCC 3.4.6) is too old to support the --sysroot option, which was added to trunk with commit 102367, and did not make it into a release branch until GCC 4.1.0.
2005-07-25 Mark Mitchell <mark#codesourcery.com>
* gcc.c (option_map): Add --sysroot.
(process_command): Handle --sysroot.
(display_help): Document it.
* doc/cppopts.tex (-isysroot): Document.
* doc/invoke.texi (--sysroot): Document.
* doc/install.texi (--with-build-sysroot): Document.
* Makefile.in (inhibit_libc): New variable.
(INHIBIT_LIBC_CFLAGS): Likewise.
(LIBGCC2_CFLAGS): Include
$(INHIBIT_LIBC_CFLAGS).
(CRTSTUFF_CFLAGS): Include $(INHIBIT_LIBC_CFLAGS).
($(T)crtbegin.o): Do not use #inhibit_libc#.
($(T)crtend.o): Likewise.
($(T)crtbeginS.o): Do not use #inhibit_libc#.
($(T)crtendS.o): Likewise.
($(T)crtbeginT.o): Do not use #inhibit_libc#.
($(T)crtendT.o): Likewise.
(stmp-fixinc): Do not complain about missing headers if
inhibit_libc.
* configure.ac (inhibit_libc): Set it to true/false.
(--with-build-sysroot): New option. Use it to set
SYSTEM_HEADER_DIR.
* configure: Regenerated.
I'm trying to add a Swig interface on top of some already existing c++ code and I'm coming up with some errors with the -fPIC flag.
If I compile the already existing code without -fPIC and then create my Swig module using:
swig -python -c++ pyinterface.i
gcc -fPIC $(CFLAGS)-I $(PYTHON_INCLUDE_DIR) -c pyinterface_wrap.cxx
g++ -shared -o _pyinterface.so pyinterface_wrap.o -I $(PYTHON_INCLUDE_DIR) -L $(PYTHON_LIB_DIR) $(LPATH) $(LFLAGS) $(IPATH) $(LIBS)
Then I get a
warning: creating a DT_TEXTREL in object
However the module does seem to load and work in Python.
If I compile the already existing code with -fPIC and then do the same to create my module, when I try and import it into python:
import pyinterface
Then I get the error
ImportError: ./_pyinterface.so: undefined symbol: _Z7InitErfPA20_d
I can't tell why this would be. However, in the compliation of the base c++ files that I am trying to wrap, they do link to some standard libraries such as -llapack.
Could it be that I need to recompile these base libraries, like lapack, with -fPIC. That seems insane.
EDIT:
Actually sorry, I didn't realise, but with the -fPIC flag on I'm getting an error during compile:
g++: Internal error: Killed (program cc1plus)
Please submit a full bug report.
See http://bugs.gentoo.org/ for instructions.
I'll update this question if I figure out whats going on, but it seems like it might be unrelated to anything that the question actually raises.
I might be wrong regarding this reply.
Regarding the warning: creating a DT_TEXTREL in object
Even I was getting the same warning.
In my Makefile; I had done something like this
SRC= ../../some_folder/file.c 1.c 2.c
OBJS= $(SRC:.c=.o)
and while making the shared object, i was using this $(OBJS); whereas the "file.o" would be available at that location.
Make sure the object files that you are trying to access are available at that location.
My warning message vanished when i made the following changes
OBJS=file.o 1.o 2.o
I am attempting to compile a c++ class using gcc. Due to the nature of the build, I need to invoke gcc from a non-standard location and include non-system defined headers, only to add a set from a different location. However, when I do this, I run into an issue where I cannot find some base symbols (suprise suprise). So i am basically running this command to compile my code:
-->(PARENT_DIR)/usr/bin/gcc # invoke compiler
-B$(PARENT_DIR)/usr/lib64/gcc/suselinux-x8664
-B$(PARENT_DIR)/usr/lib64
#C/C++ flags
-fPIC -fvisibility=default -g -c -Wall -m64 -nostdinc
# source files
-I$(SRC_DIR_ONE)/
-I$(SRC_DIR_TWO)
-I../include
# 'Mock' include the system header files
-I$(PARENT_DIR)/usr/include/c++/$(GCC_VERSION)
-I$(PARENT_DIR)/usr/include/c++/$(GCC_VERSION)/backward
-I$(PARENT_DIR)/usr/include/c++/$(GCC_VERSION)/x86_64-suse-linux
-I$(PARENT_DIR)/usr/lib64/x86_64-suse-linux/$(GCC_VERSION)/include
-I$(PARENT_DIR)/usr/lib64/gcc/x86_64-suse-linux/$(GCC_VERSION)/include
-I$(PARENT_DIR)/usr/lib64/gcc/x86_64-suse-linux/$(GCC_VERSION)/include-fixed
-I$(PARENT_DIR)/usr/src/linux/include
-I$(PARENT_DIR)/usr/x86_64-suse-linux/include
-I$(PARENT_DIR)/usr/include/suselinux-x8664
-I$(PARENT_DIR)/usr/suselinux-x8664/include
-I$(PARENT_DIR)/usr/include
-I$(PARENT_DIR)/usr/include/linux
file.cpp
I am getting several errors which indicate that the base headers are not being included: such as:
$(PARENT_DIR)/usr/include/c++/$(GCC_VERSION)/cstddef ::prtdiff_t has not been declared
$(PARENT_DIR)/usr/include/c++/$(GCC_VERSION)/cstddef ::size_t has not bee declared.
Is there something that I am doing wrong when I include the header file directories? Or am I looking in the wrong place?
Perhaps the --sysroot arg would help, see gcc docs.