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.
Related
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 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?
Ubuntu 17.10
GCC Version: 5.4
Bazel Version: 0.9.0
TensorFlow: r1.5
CUDA 8.0 / cuDNN 6 / GTX 1080 Ti
How do I make Bazel use gcc for building TensorFlow from source?
While building, its running into compiler errors like:
error: 'errno' was not declared in this scope
while (nanosleep(&ts, &ts) != 0 && errno == EINTR) {}
Setting --verbose_failures flag, it shows that its not using /usr/bin/gcc-5 or /usr/bin/gcc for compiling
external/local_config_cuda/crosstool/clang/bin/crosstool_wrapper_driver_is_not_gcc -U_FORTIFY_SOURCE '-D_FORTIFY_SOURCE=1' -fstack-protector -fPIE -Wall -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer -g0 -O2 -DNDEBUG -ffunction-sections -fdata-sections -g0 -DGEMMLOWP_ALLOW_SLOW_SCALAR_FALLBACK '-march=native' '-std=c++11' -g0 -MD -MF
Searching online, I found that the path to gcc and CC, CXX variables must be set in tools/cpp/CROSSTOOL. But where exactly is tools/cpp/CROSSTOOL?? How do I force bazel to use gcc-5?
I know next to nothing about cuda and tensorflow, but tensorflow doesn't use the same C++ toolchain that bazel autoconfigures when compiling with cuda, so the CC env variable trick won't work. The file crosstool_wrapper_driver_is_not_gcc is just a shell wrapper that could in theory still call your gcc (or it will be cuda). I'd run bazel with --subcommands to see the complete invocation of the failing action, then reproduce without bazel, and then go from there.
I am on a complex project built in python2.7 that uses the PyDSTool package for analysis of dynamical system. PyDSTool provides two C-based integrators - Radau and Dopri - which I want to use to integrate my system of equations whose source is coded in a bunch of C/C++ files.
I have little control on the package, and when I instantiate the integrator, I can only add headers *.H files, source files (*.C, *.CPP) and pass the directories to include in the search path of the compiler as well as libraries to link to.
Since a consistent part of the code is based on C++11 I am passing to the compiler also the argument -std=C++11.
Eventually, /PyDSTool/Generators/mixins.py launch a setup command (line 185) which in turn runs the command build_ext from distutils to which all the above flags are appended.
For the sake of clarity: the flags that I am appending are:
compile options: '-I/usr/lib64/python2.7/site-packages/numpy/core/include -I/home/maurizio/Dropbox/StabilityAnalysis_tmp -I/usr/local/pydstool/PyDSTool/integrator -I/usr/include/python2_7 -I/usr/include/numpy -I/home/maurizio/Dropbox/Ongoing_Projects/pycustommodules -I/home/maurizio/Dropbox/Ongoing_Projects/c_libraries -I/home/maurizio/Dropbox/Ongoing_Projects/c_libraries/models -I/home/maurizio/Dropbox/Ongoing_Projects/DePitta_PNAS/Software/Stability_Analysis/ -I/usr/lib64/python2.7/site-packages/numpy/core/include -I/usr/include/python2.7 -c'
extra options: '-std=c++11 -w -Wno-return-type -Wall -lpython2.7 -lm -lgsl -lgslcblas -D__DOPRI__'
The resulting compilation command as issued by PyDSTool reads:
error: Command "gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC -I/usr/lib64/python2.7/site-packages/numpy/core/include -I/home/maurizio/Dropbox/StabilityAnalysis_tmp -I/usr/local/pydstool/PyDSTool/integrator -I/usr/include/python2_7 -I/usr/include/numpy -I/home/maurizio/Dropbox/Ongoing_Projects/pycustommodules -I/home/maurizio/Dropbox/Ongoing_Projects/c_libraries -I/home/maurizio/Dropbox/Ongoing_Projects/c_libraries/models -I/home/maurizio/Dropbox/Ongoing_Projects/DePitta_PNAS/Software/Stability_Analysis/ -I/usr/lib64/python2.7/site-packages/numpy/core/include -I/usr/include/python2.7 -c /home/maurizio/Dropbox/StabilityAnalysis_tmp/dop853_temp/ei_network_vf.c -o /home/maurizio/Dropbox/StabilityAnalysis_tmp/dop853_temp/home/maurizio/Dropbox/StabilityAnalysis_tmp/dop853_temp/ei_network_vf.o -std=c++11 -w -Wno-return-type -Wall -lpython2.7 -lm -lgsl -lgslcblas -D__DOPRI__" failed with exit status 1
Once looking into the build.log file automatically generated by PyDSTool, it turns out that the exit status is due to the fact that the compiler does not see the C++ libraries that are in several routines/libs used by my code, e.g.
/usr/include/blitz/blitz.h:45:18: fatal error: string: No such file or directory
#include <string>
^
Compilation Terminated
Now, it is not a problem of my code, because if I compile my code as a standalone in python or through scipy.weave with the same compile and extra options pasted above, it works. It is a problem of making PyDSTool build the code within the integrator. As I am NOT practical with distutils and all gcc options I hope there is some expert here that could provide me with some insight. I suspect in fact that I am missing some options or whatever to pass to the compiler.
Just for the sake of completeness. The issue I pointed out above does not have an easy workaround. PyDSTool C-based integrators (i.e. Radau and Dopri) cannot be compiled with source code for the equations in C++ but only in C. So either you recast your code in plain C or try to edit PyDSTool integrators and recast them in C++. The first option is likely the only one currently possible (at least to some non-experts as who is writing).
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