I'm a little stuck at the moment.
I have been working on a C++ project lately but i'm having trouble with exceptions.
The target is an STM32.
I set up 2 projects using STs Cube MX Code Generator.
The code executed is
try
{
throw 1;
}
catch(const int& ex)
{
configASSERT(0);
}
My used IDE (SW4STM32, eclipse based, g++) fails to catch the exception. I'm always running into the termination handler. The other IDE (atolic true studio, eclipse based, g++) catches the exception.
Therefore it's not a target problem but an IDE problem. I already did remove the fno-exceptions from the g++ compiler and the linker options. But still no luck.
Do you have any others ideas on where to look?
Thx :)
Edit:
SW4STM32 Compiler Flags (Console Output)
22:40:11 **** Incremental Build of configuration Debug for project Test_Exceptions_AC6 ****
make -j4 all
Building file: ../Core/Src/User/Test/Test.cpp
Invoking: MCU G++ Compiler
Test_Exceptions_AC6\Debug
arm-none-eabi-g++ -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 '-D__weak=__attribute__((weak))' '-D__packed=__attribute__((__packed__))' -DUSE_HAL_DRIVER -DSTM32F429xx -I"xxx/Test_Exceptions_AC6/Core/Inc" -I"xxx/Test_Exceptions_AC6/Core/Inc/User" -I"xxx/Test_Exceptions_AC6/Drivers/STM32F4xx_HAL_Driver/Inc" -I"xxx/Test_Exceptions_AC6/Drivers/STM32F4xx_HAL_Driver/Inc/Legacy" -I"xxx/Test_Exceptions_AC6/Middlewares/Third_Party/FreeRTOS/Source/portable/GCC/ARM_CM4F" -I"xxx/Test_Exceptions_AC6/Drivers/CMSIS/Device/ST/STM32F4xx/Include" -I"xxx/Test_Exceptions_AC6/Middlewares/Third_Party/FreeRTOS/Source/include" -I"xxx/Test_Exceptions_AC6/Middlewares/Third_Party/FreeRTOS/Source/CMSIS_RTOS" -I"xxx/Test_Exceptions_AC6/Drivers/CMSIS/Include" -Og -g3 -Wall -fmessage-length=0 -ffunction-sections -c -fno-rtti -MMD -MP -MF"Core/Src/User/Test/Test.d" -MT"Core/Src/User/Test/Test.o" -o "Core/Src/User/Test/Test.o" "../Core/Src/User/Test/Test.cpp"
../Core/Src/User/Test/Test.cpp: In function 'void Test_Func()':
../Core/Src/User/Test/Test.cpp:56:21: warning: unused variable 'n_elements' [-Wunused-variable]
volatile uint32_t n_elements = test_custom_list.size();
^~~~~~~~~~
Finished building: ../Core/Src/User/Test/Test.cpp
SW4STM32 Linker Output
Building target: Test_Exceptions_AC6.elf
Invoking: MCU G++ Linker
arm-none-eabi-g++ -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -specs=nosys.specs -specs=nano.specs -T"../STM32F429ZITx_FLASH.ld" -Wl,-Map=output.map -Wl,--gc-sections -fno-rtti -o "Test_Exceptions_AC6.elf" #"objects.list" -lm
Finished building target: Test_Exceptions_AC6.elf
make --no-print-directory post-build
Generating hex and Printing size information:
arm-none-eabi-objcopy -O ihex "Test_Exceptions_AC6.elf" "Test_Exceptions_AC6.hex"
arm-none-eabi-size "Test_Exceptions_AC6.elf"
text data bss dec hex filename
Attolic Output
22:46:09 **** Incremental Build of configuration Debug for project Exceptions_True_Studio ****
Info: Internal Builder is used for build
arm-atollic-eabi-g++ -c ..\Core\Src\User\Test\Test.cpp -mthumb -mcpu=cortex-m4 -mfloat-abi=hard -mfpu=fpv4-sp-d16 -std=c++14 -DSTM32F10X_MD -DSTM32F429xx -D__packed=__attribute__((__packed__)) -D__weak=__attribute__((weak)) -DUSE_STDPERIPH_DRIVER -I../Core/Inc/User -I../Core/Inc/ -I../Drivers/CMSIS/Include -I../Middlewares/Third_Party/FreeRTOS/Source/include -I../Drivers/CMSIS/Device/ST/STM32F4xx/Include -I../Middlewares/Third_Party/FreeRTOS/Source/portable/GCC/ARM_CM4F -I../Drivers/STM32F4xx_HAL_Driver/Inc/Legacy -I../Drivers/STM32F4xx_HAL_Driver/Inc -I../Middlewares/Third_Party/FreeRTOS/Source/CMSIS_RTOS -O0 -ffunction-sections -g -fstack-usage -Wall -Wextra -Wfatal-errors -Wmissing-include-dirs -Wswitch-default -Wswitch-enum -fno-threadsafe-statics -o Core\Src\User\Test\Test.o
..\Core\Src\User\Test\Test.cpp: In function 'void Test_Func()':
..\Core\Src\User\Test\Test.cpp:47:21: warning: unused variable 'n_elements' [-Wunused-variable]
volatile uint32_t n_elements = test_custom_list.size();
^~~~~~~~~~
arm-atollic-eabi-g++ -o Exceptions_True_Studio.elf Core\Src\User\Test\Test.o Core\Src\crc.o Core\Src\dma2d.o Core\Src\fmc.o Core\Src\freertos.o Core\Src\gpio.o Core\Src\i2c.o Core\Src\ltdc.o Core\Src\main.o Core\Src\spi.o Core\Src\stm32f4xx_hal_msp.o Core\Src\stm32f4xx_hal_timebase_TIM.o Core\Src\stm32f4xx_it.o Core\Src\system_stm32f4xx.o Core\Src\tim.o Core\Src\usart.o Core\Src\usb_otg.o Drivers\STM32F4xx_HAL_Driver\Src\stm32f4xx_hal.o Drivers\STM32F4xx_HAL_Driver\Src\stm32f4xx_hal_cortex.o Drivers\STM32F4xx_HAL_Driver\Src\stm32f4xx_hal_crc.o Drivers\STM32F4xx_HAL_Driver\Src\stm32f4xx_hal_dma.o Drivers\STM32F4xx_HAL_Driver\Src\stm32f4xx_hal_dma2d.o Drivers\STM32F4xx_HAL_Driver\Src\stm32f4xx_hal_dma_ex.o Drivers\STM32F4xx_HAL_Driver\Src\stm32f4xx_hal_dsi.o Drivers\STM32F4xx_HAL_Driver\Src\stm32f4xx_hal_flash.o Drivers\STM32F4xx_HAL_Driver\Src\stm32f4xx_hal_flash_ex.o Drivers\STM32F4xx_HAL_Driver\Src\stm32f4xx_hal_flash_ramfunc.o Drivers\STM32F4xx_HAL_Driver\Src\stm32f4xx_hal_gpio.o Drivers\STM32F4xx_HAL_Driver\Src\stm32f4xx_hal_hcd.o Drivers\STM32F4xx_HAL_Driver\Src\stm32f4xx_hal_i2c.o Drivers\STM32F4xx_HAL_Driver\Src\stm32f4xx_hal_i2c_ex.o Drivers\STM32F4xx_HAL_Driver\Src\stm32f4xx_hal_ltdc.o Drivers\STM32F4xx_HAL_Driver\Src\stm32f4xx_hal_ltdc_ex.o Drivers\STM32F4xx_HAL_Driver\Src\stm32f4xx_hal_pwr.o Drivers\STM32F4xx_HAL_Driver\Src\stm32f4xx_hal_pwr_ex.o Drivers\STM32F4xx_HAL_Driver\Src\stm32f4xx_hal_rcc.o Drivers\STM32F4xx_HAL_Driver\Src\stm32f4xx_hal_rcc_ex.o Drivers\STM32F4xx_HAL_Driver\Src\stm32f4xx_hal_sdram.o Drivers\STM32F4xx_HAL_Driver\Src\stm32f4xx_hal_spi.o Drivers\STM32F4xx_HAL_Driver\Src\stm32f4xx_hal_tim.o Drivers\STM32F4xx_HAL_Driver\Src\stm32f4xx_hal_tim_ex.o Drivers\STM32F4xx_HAL_Driver\Src\stm32f4xx_hal_uart.o Drivers\STM32F4xx_HAL_Driver\Src\stm32f4xx_ll_fmc.o Drivers\STM32F4xx_HAL_Driver\Src\stm32f4xx_ll_usb.o Middlewares\Third_Party\FreeRTOS\Source\CMSIS_RTOS\cmsis_os.o Middlewares\Third_Party\FreeRTOS\Source\croutine.o Middlewares\Third_Party\FreeRTOS\Source\event_groups.o Middlewares\Third_Party\FreeRTOS\Source\list.o Middlewares\Third_Party\FreeRTOS\Source\portable\GCC\ARM_CM4F\port.o Middlewares\Third_Party\FreeRTOS\Source\portable\MemMang\heap_4.o Middlewares\Third_Party\FreeRTOS\Source\queue.o Middlewares\Third_Party\FreeRTOS\Source\tasks.o Middlewares\Third_Party\FreeRTOS\Source\timers.o startup\startup_stm32f429xx.o -mthumb -mcpu=cortex-m4 -mfloat-abi=hard -mfpu=fpv4-sp-d16 -T../STM32F429ZI_FLASH.ld -specs=nosys.specs -static -Wl,-cref,-u,Reset_Handler, -Wl,-Map=Exceptions_True_Studio.map -Wl,--gc-sections -Wl,--defsym=malloc_getpagesize_P=0x1000 -Wl,--start-group -lc -lm -lstdc++ -lsupc++ -Wl,--end-group
C:\Program Files (x86)\Atollic\TrueSTUDIO for STM32 9.0.1\ide\jre\bin\java -jar C:\Program Files (x86)\Atollic\TrueSTUDIO for STM32 9.0.1\Tools\arm-atollic-reports.jar sizeinfo list Exceptions_True_Studio.elf
Generate build reports...
Print size information
text data bss dec hex filename
307304 1924 173124 482352 75c30 Exceptions_True_Studio.elf
Print size information done
Generate listing file
Output sent to: Exceptions_True_Studio.list
Generate listing file done
Generate build reports done
arm-atollic-eabi-objcopy.exe -O ihex Exceptions_True_Studio.elf Exceptions_True_Studio.hex
Info: Parallel threads used: 1
22:46:21 Build Finished (took 12s.140ms)
Now as you can see, there is no fnoexceptions active. Therefore I'd expect to receive exceptions. :(
SW4STM32 uses Eclipse Platform 4.6.3 Eclipse CDT 9.2.1
Attolic uses Eclipse Platform 4.6.1, Eclipse CDT 9.1.0
So the eclipse base versions are pretty similar.
Do you have any other ideas?
Related
I am building a C library from source and linking to my C++ application. The library's CMake output confirms Clang 14 and debug build:
CC=clang cmake ..
-- Build type: Debug
-- The C compiler identification is Clang 14.0.0
make shows no optimization:
-O0 -g3 -std=c99 -Wall -Wextra -Wwrite-strings -Wformat=2 -Wno-format-nonliteral -Wvla -Wlogical-op -Wshadow -Wformat-signedness -Wformat-overflow=2 -Wformat-truncation -Werror
sudo make install shows debug and the install path:
Install the project...
-- Install configuration: "Debug"
-- Installing: /usr/local/lib/the_library.a
I have checked the libraries were modified.
My application, my compiler flags showing debug/optimization:
-Wall -Wextra -pedantic -march=native -Werror=return-type -Wswitch-enum -Wconversion -Werror=attributes -Werror=unused-variable -Werror=unused-parameter -Werror=unused-result -Werror=address -Werror=unused-but-set-variable -Werror=unused-function -Werror=unused-but-set-parameter -Werror=uninitialized -Werror=sign-compare -Werror=float-conversion -Werror=unknown-warning-option -Werror=unused-private-field -Werror=return-stack-address -Wno-bitwise-instead-of-logical -Werror=reorder-ctor -Wshorten-64-to-32 -g -O0 -fPIE -fno-omit-frame-pointer -std=c++20
And my linker showing the correct library:
-ldl /usr/local/lib/the_library.a
I then start GDB:
gdb --args ./my_application
b SomeFile.h:200
Breakpoint 1 at 0x13d7c4: SomeFile.h:200. (3 locations)
Line 200 is a function call to the library but in my application. It hits the breakpoint:
layout src
s
but won't step in to the library
HOWEVER, if I set the breakpoint to the name of the library's function, it steps SUCCESSFULLY.
Is the problem this (3 locations) on the breakpoint? The library function is not inlined, nor is SomeFile.h:200.
I was building some Cython extensions, and have to link it against a static library (it has CUDA code in them, so have to be static):
running build_ext
building 'k3lib' extension
gcc -pthread -B /home/kelvin/anaconda3/envs/torch/compiler_compat -Wl,--sysroot=/ -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/home/kelvin/repos/tools/include -I/home/kelvin/anaconda3/envs/torch/include/python3.8 -c main.cpp -o build/temp.linux-x86_64-3.8/main.o -O3 -march=native
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++
g++ -pthread -shared -B /home/kelvin/anaconda3/envs/torch/compiler_compat -L/home/kelvin/anaconda3/envs/torch/lib -Wl,-rpath=/home/kelvin/anaconda3/envs/torch/lib -Wl,--no-as-needed -Wl,--sysroot=/ build/temp.linux-x86_64-3.8/main.o /home/kelvin/repos/tools/include/libk2.a -L/home/kelvin/repos/tools/include -lk2 -o build/lib.linux-x86_64-3.8/k3lib.cpython-38-x86_64-linux-gnu.so -static -Wl,-Bstatic -flinker-output=exec
However, Cython's g++ compile command includes the options -shared -fPIC by default. I tried a number of options at the end of the command via this setup file (the static library is at $(LOCAL_INCLUDE)/libk2.a):
includes = [os.getenv("LOCAL_INCLUDE")]
ext_modules = [
Extension("k3lib", sources=["main.pyx"],
libraries=["k2"], include_dirs=includes, library_dirs=includes, language="c++",
extra_compile_args=["-O3", "-march=native"], extra_objects=[f"{includes[0]}/libk2.a"],
extra_link_args=['-static', '-Wl,-Bstatic', '-flinker-output=exec'])
]
#extra_objects=[f"{includes[0]}/libk2.a"]
#extra_link_args=['-static']
setup(name="k3lib", ext_modules=cythonize(ext_modules, language_level="3"))
Still, g++ thinks that I want to build a shared library, and thus the error message. Is there a way to override the -shared option? I'm planning to go into Cython's files and edit them myself, but was wondering is there a simpler way?
Context: I was following this question on SO but can't replicate their success.
The image for my embedded (ARM Cortex-M) firmware is significantly bloated from what looks like symbol names, some of which are very long due to C++ templates instantiated with lambda closures. The code is compiled with ARM GCC 10.1 with:
-Os -ffunction-sections -fdata-sections -fno-exceptions -fno-rtti -g0
I have made sure that there are no stray occurences of __PRETTY_FUNCTION__ or similar scattered around.
The strings are found using the arm-none-eabi-strings program, which basically just looks for byte sequences looking like strings. It is run on the binary image, which does not contain debug symbols.
What could be causing strings of type names to be embedded in the image? The code does make use of virtual methods, so vtables are generated. However, I had assumed that -fno-rtti would prevent the generation of type info structures.
EDIT: The compilation process is handled by CMake, but these are the commands run by CMake (with absolute paths removed for readability):
# compile
arm-none-eabi-g++
-I<SDK-includes>
-mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mthumb -mabi=aapcs -mfloat-abi=hard
-Wall -Werror
-ffunction-sections -fdata-sections
-fno-rtti -fconcepts-diagnostics-depth=3 -fno-exceptions
-Os -DNDEBUG -g3 -ftemplate-backtrace-limit=0
-fcoroutines -fno-use-cxa-atexit -std=c++2a -o main.cpp.obj -c main.cpp
# link
arm-none-eabi-g++
-mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mthumb -mabi=aapcs -mfloat-abi=hard
-Werror
-ffunction-sections -fdata-sections
-fno-rtti -fconcepts-diagnostics-depth=3 -fno-exceptions
-Os -DNDEBUG -g3
--specs=nosys.specs -Tlinker-script.ld
-static -Wl,--gc-sections,--entry,Reset_Handler
-Wl,--start-group -lm -lc -lgcc -Wl,--end-group
main.cpp.obj -o main.elf
# extract binary
arm-none-eabi-objcopy
-O binary main.elf main.bin
I have tried with -g0 as-well, but after objcopy, the debug symbols are stripped anyway.
The compiler is GCC 10.1:
arm-none-eabi-g++ (GNU Arm Embedded Toolchain 10-2020-q2-preview) 10.1.1 20200529 (release)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
I'm building a library (libproj) using g++-9 and CMake (on Xenial, on Travis), so I can statically link it in a Rust crate. My build.rs sets up and runs CMake with the following config:
cmake proj-7.0.1
-DBUILD_SHARED_LIBS=ON
-DBUILD_TESTING=OFF
-DCMAKE_BUILD_TYPE=Release
-DCMAKE_CXX_FLAGS="-std=c++11 -fPIC"
-DCMAKE_INSTALL_PREFIX=[path snipped]/out
-DCMAKE_C_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64
-DCMAKE_C_COMPILER=/usr/bin/gcc-9
-DCMAKE_CXX_COMPILER=/usr/bin/g++-9
-DCMAKE_ASM_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64
-DCMAKE_ASM_COMPILER=/usr/bin/gcc-9
Which builds and installs libproj successfully.
I then tell cargo to statically link it:
cargo:root=[path snipped]/out
cargo:rustc-link-search=native=[path snipped]/out/lib
cargo:rustc-link-lib=static=proj
However, the link step fails, saying I can't use relocation in a shared object:
note: /usr/bin/ld: [path snipped]/out/lib/libproj.a(4D_api.cpp.o): relocation
R_X86_64_32 against `.rodata.str1.8' can not be used when making a
shared object; recompile with -fPIC`
[path snipped]/out/lib/libproj.a(4D_api.cpp.o): error adding symbols: Bad value
collect2: error: ld returned 1 exit status
What am I doing wrong here? I've also tried to build libproj as a static lib by setting BUILD_SHARED_LIBS to OFF as per the install instructions, but that hasn't had any effect.
UPDATE:
I've managed to enable PIC for g++ (by default it's only enabled for gcc)
running: "cmake" "-Wdev" "--debug-output" "[snipped]/proj-7.0.1" "-DCMAKE_CXX_FLAGS=-std=c++11" "-DCMAKE_CXX_FLAGS=-fPIC" "-DBUILD_SHARED_LIBS=OFF" "-DCMAKE_INSTALL_PREFIX=[snipped]/out" "-DCMAKE_C_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_C_COMPILER=/usr/bin/gcc-9" "-DCMAKE_CXX_COMPILER=/usr/bin/g++-9" "-DCMAKE_ASM_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_ASM_COMPILER=/usr/bin/gcc-9" "-DCMAKE_BUILD_TYPE=Debug" "-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON"
Resulting in the following g++-9 invocation, which includes -fPIC:
/usr/bin/g++-9 -DCURL_ENABLED -DMUTEX_pthread -DPROJ_LIB=\"/[snip]/proj\" -DTIFF_ENABLED -I/[snip]/src -I/[snip]/include -I/[snip]/src -I/usr/include/x86_64-linux-gnu -fPIC -g -fvisibility=hidden -Wall -Wextra -Wswitch -Wshadow -Wunused-parameter -Wmissing-declarations -Wformat -Wformat-security -std=c++11 -o CMakeFiles/proj.dir/aasincos.cpp.o -c /[snip]/proj/proj-7.0.1/src/aasincos.cpp
However, I know get a completely different error (thousands of lines), that looks like my static library hasn't been correctly linked to the c++11 stdlib:
Error:
undefined reference to std::allocator<char>::allocator()
UPDATE 2:
I've managed to remove the -nodefaultlibs flag from ld. The latest g++ invocation:
/usr/bin/g++-9 -I/[snipped]/src -I/[snipped]/include -I/[snipped]/src -isystem /[snipped]/include -isystem /[snipped]/googletest -fPIC -g -fvisibility=hidden -Wall -Wextra -Wswitch -Wshadow -Wunused-parameter -Wmissing-declarations -Wformat -Wformat-security -pthread -std=c++11 -o CMakeFiles/proj_context_test.dir/proj_context_test.cpp.o -c /[snipped]/proj_context_test.cpp
And I've managed to add lstdc++ to the linker invocation:
"cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/[snip]/lib" "/home/travis/build/georust/proj-sys/target/debug/deps/proj_sys-95cbd73f2c3f0bde.20tasg77xuhsj5z6.rcgu.o" "/home/travis/build/georust/proj-sys/target/debug/deps/proj_sys-95cbd73f2c3f0bde.57y4784ihm3qw715.rcgu.o" "-o" "/[snip]/deps/proj_sys-95cbd73f2c3f0bde" "/home/travis/build/georust/proj-sys/target/debug/deps/proj_sys-95cbd73f2c3f0bde.3kiafs23968zh4mj.rcgu.o" "-Wl,--gc-sections" "-pie" "-Wl,-zrelro" "-Wl,-znow" "-L" "/home/travis/build/georust/proj-sys/target/debug/deps" "-L" "/home/travis/build/georust/proj-sys/target/debug/build/proj-sys-aff2ac9d43b77886/out/lib" "-L" "/home/travis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-lsqlite3" "-lcurl" "-ltiff" "-lstdc++" "-Wl,-Bstatic" "-Wl,--whole-archive" "-lproj" "-Wl,--no-whole-archive" [trimmed rlib details] "-Wl,--end-group" "/home/travis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-2541f1e09df1c67d.rlib" "-Wl,-Bdynamic" "-ldl" "-lrt" "-lpthread" "-lgcc_s" "-lc" "-lm" "-lrt" "-lpthread" "-lutil" "-lutil"
But the undefined reference error remains.
As I can see from your example, you have quotation marks around CMAKE_CXX_FLAGS and do not have ones around CMAKE_C_FLAGS. It looks odd.
I have built libgproj myself with cmake + your flags and with make VERBOSE=1.
I can see, that C-files compiled without fPIC, m64 and fdata-sections. I suppose, that the cause is in the quotation marks around CMAKE_C_FLAGS. I saw your log in Travis, and there is configuration for cmake from cargo:
"cmake" "/home/travis/build/georust/proj-sys/PROJSRC/proj/proj-7.0.1" "-DBUILD_SHARED_LIBS=ON" "-DBUILD_TESTING=OFF" "-DCMAKE_BUILD_TYPE=Release" "-DCMAKE_CXX_FLAGS=-std=c++11 -fPIC" "-DCMAKE_INSTALL_PREFIX=/home/travis/build/georust/proj-sys/target/debug/build/proj-sys-03a5fe6428bb060a/out" "-DCMAKE_C_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_C_COMPILER=/usr/bin/gcc-9" "-DCMAKE_CXX_COMPILER=/usr/bin/g++-9" "-DCMAKE_ASM_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_ASM_COMPILER=/usr/bin/gcc-9"
Note, that -DCMAKE_C_FLAGS and CMAKE_CXX_FLAGS escaped with their values, and not values by itself. I suppose, that these options become in the shell:
cmake -DCMAKE_C_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64 -DCVMAKE_CXX_FLAGS=-std=c++11 -fPIC
I have tried this command, without quotation marks and cmake just ignored unknown options. So it will not fail.
I suggest you to add cmake option -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON to cmake configuration or VERBOSE=1 to the make options, if you can, and then you can see real compile options passed to gcc in Travis.
You will see somethig like this:
[ 19%] Building C object src/CMakeFiles/proj.dir/wkt1_generated_parser.c.o
cd [some path]/PROJ/cmake_build/src && /usr/bin/cc -DCURL_ENABLED -DMUTEX_pthread
-DPROJ_LIB=\"/usr/local/share/proj\" -DTIFF_ENABLED -I[some path]PROJ/src -I[some
path]/PROJ/include -I[some path]/PROJ/cmake_build/src -O3 -DNDEBUG -
fvisibility=hidden -Wall -Wextra -Wswitch -Wshadow -Wunused-parameter -Wmissing-
declarations -Wformat -Wformat-security -Wmissing-prototypes -std=c99 -o
CMakeFiles/proj.dir/wkt1_generated_parser.c.o -c [some
path]/PROJ/src/wkt1_generated_parser.c
Conclusion:
You can try adding verbosity to see real compile options.
You can try to escape options properly, if it's necessary after first step.
Also I want to note, that SHARED_BUILD_LIBS=ON in my test forbids building static lib, which you want to link. When I set shared libs building setting option to OFF, static lib was built.
I’m running Netbeans 7.4 on Mavericks. In order to be able to use gdb, compilation with the -ggdb flag seems to be necessary. However, even though I specify it through the Project’s Properties/Additional Options wizard, Netbeans also emits -g during compilation. Unfortunately, it turns out that this behavior has an adverse effect when the debugging session commences. Is there any way to force Netbeans not to also emit -g?
Output during compilation:
g++ -m64 -ggdb -c -g -Werror -std=c++11 -MMD -MP -MF "build/Debug/macport_GNU-MacOSX/main.o.d" -o build/Debug/macport_GNU-MacOSX/main.o main.cpp
mkdir -p dist/Debug/macport_GNU-MacOSX
g++ -m64 -ggdb -o dist/Debug/macport_GNU-MacOSX/executable build/Debug/macport_GNU-MacOSX/main.o
Alexander.Simon#oracle.com responded here [1] to set "Development Mode" to "No Flags", then specify -ggdb in the "Additional Options".
1 - https://netbeans.org/projects/cnd/lists/users/archive/2014-02/message/12