I have a R script that throws a segfault error. The R script uses a package "RSofia" that internally calls a C++ program using Rcpp package which I believe is causing the issue.
Please refer to the link for the question I posted on the same: RSofia Issue
I am trying to debug and identify what is causing the issue using valgrind as follows:
R -d "valgrind --leak-check=full --show-reachable=yes" -f svm.r
This throws the following output:
==11235== Memcheck, a memory error detector
==11235== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==11235== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==11235== Command: /usr/lib64/R/bin/exec/R -f svm.r
==11235==
vex: priv/main_main.c:319 (LibVEX_Translate): Assertion `are_valid_hwcaps(VexArchAMD64, vta->archinfo_host.hwcaps)' failed.
vex storage: T total 0 bytes allocated
vex storage: P total 0 bytes allocated
valgrind: the 'impossible' happened:
LibVEX called failure_exit().
==11235== at 0x38031DA7: report_and_quit (m_libcassert.c:235)
==11235== by 0x38031E0E: panic (m_libcassert.c:319)
==11235== by 0x38031E68: vgPlain_core_panic_at (m_libcassert.c:324)
==11235== by 0x38031E7A: vgPlain_core_panic (m_libcassert.c:329)
==11235== by 0x3804D162: failure_exit (m_translate.c:708)
==11235== by 0x380D4C38: vex_assert_fail (main_util.c:219)
==11235== by 0x380D3009: LibVEX_Translate (main_main.c:319)
==11235== by 0x3804AACE: vgPlain_translate (m_translate.c:1559)
==11235== by 0x38079D9F: vgPlain_scheduler (scheduler.c:991)
==11235== by 0x380A6409: run_a_thread_NORETURN (syswrap-linux.c:103)
sched status:
running_tid=1
Thread 1: status = VgTs_Runnable
==11235== at 0x4000B00: ??? (in /lib64/ld-2.12.so)
==11235== by 0x2: ???
==11235== by 0x7FF00036E: ???
==11235== by 0x7FF000386: ???
==11235== by 0x7FF000389: ???
Can someone help with how to locate the error from this message and what could be a possible fix to this?
Looks like it is using an assert() which, according to Writing R Extension one should not be using in the first place.
Now why the assert() evaluates the way it does and hence aborts is another matter. But for that one would need a minimally reproducible example, plus some spare time and patience.
Related
Here is the brief log:
# valgrind --error-limit=no --leak-check=full --tool=memcheck /mnt/aarch64/ld-linux-aarch64.so.1 ./program
==12104== Memcheck, a memory error detector
==12104== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==12104== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==12104== Command: /mnt/aarch64/ld-linux-aarch64.so.1 ./program
==12104==
vex: priv/host_arm64_defs.c:2796 (genSpill_ARM64): Assertion `offsetB < 4096' failed.
vex storage: T total 4207069920 bytes allocated
vex storage: P total 0 bytes allocated
valgrind: the 'impossible' happened:
LibVEX called failure_exit().
host stacktrace:
==12104== at 0x5803F488: show_sched_status_wrk (m_libcassert.c:406)
==12104== by 0x5803F5C7: report_and_quit (m_libcassert.c:477)
==12104== by 0x5803F7FB: panic (m_libcassert.c:553)
==12104== by 0x5803F7FB: vgPlain_core_panic_at (m_libcassert.c:558)
==12104== by 0x5803F81F: vgPlain_core_panic (m_libcassert.c:563)
==12104== by 0x5805481B: failure_exit (m_translate.c:761)
==12104== by 0x5811E043: vex_assert_fail (main_util.c:245)
==12104== by 0x5817A897: genSpill_ARM64 (host_arm64_defs.c:2796)
==12104== by 0x58172217: spill_vreg (host_generic_reg_alloc3.c:338)
==12104== by 0x5817324F: doRegisterAllocation_v3 (host_generic_reg_alloc3.c:1280)
==12104== by 0x5811CD97: libvex_BackEnd (main_main.c:1133)
==12104== by 0x5811CD97: LibVEX_Translate (main_main.c:1236)
==12104== by 0x58056FCB: vgPlain_translate (m_translate.c:1830)
==12104== by 0x58092A27: handle_chain_me (scheduler.c:1169)
==12104== by 0x580954A7: vgPlain_scheduler (scheduler.c:1514)
==12104== by 0x580D8E8F: thread_wrapper (syswrap-linux.c:101)
==12104== by 0x580D8E8F: run_a_thread_NORETURN (syswrap-linux.c:154)
==12104== by 0x580D916F: vgModuleLocal_start_thread_NORETURN (syswrap-linux.c:328)
==12104== by 0x580A68D3: ??? (in /mnt/aarch64/lib/valgrind/memcheck-arm64-linux)
sched status:
running_tid=3
I want to known whether the reset output of valgrind is still meaningful for pointing out the memory leak in the program when it reports the said error(i.e. the 'impossible' happened: LibVEX called failure_exit())
Updated:
The program does run, I can see many stack strace,e.g:
Thread 1: status = VgTs_WaitSys syscall 98 (lwpid 12168)
==12168== at 0x6E85274: syscall (in /lib/libc-2.31.so)
==12168== by 0x6B99FF3: std::__atomic_futex_unsigned_base
...
Thread 2:
...
In general, if Valgrind reports some errors and then encounters an internal error, those initial reports should be valid.
In the case of the message that you show, the first report is an internal error related to the virtualization of the ARM aarch64 CPU. That's only useful for Valgrind developers.
Try running Valgrind with -d -v. There will be a lot of output, but you should see
syswrap- run_a_thread_NORETURN(tid=1): pre-thread_wrapper that is the guest executable starting
a load of gdbsrv messages
a mix of REDIR and mallocrf/hashtbl messages as the guest startup code invokes ld.so to load shared libraries
I can't tell where you get the subsequent traces from - could be trace options, more likely from the assert.
I was toying around with Valgrind, when I noticed something weird:
my C++ program does nothing, yet there is 1 memory alloc and 1 free.
My simple program:
int main() {
return 0;
}
when compiled with g++ and checked with Valgrind
> g++ main.cpp
> valgrind --leak-check=full --track-origins=yes ./a.out
==40790== Memcheck, a memory error detector
==40790== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==40790== Using Valgrind-3.16.0.GIT and LibVEX; rerun with -h for copyright info
==40790== Command: ./a.out
==40790==
==40790==
==40790== HEAP SUMMARY:
==40790== in use at exit: 0 bytes in 0 blocks
==40790== total heap usage: 1 allocs, 1 frees, 72,704 bytes allocated
==40790==
==40790== All heap blocks were freed -- no leaks are possible
==40790==
==40790== For lists of detected and suppressed errors, rerun with: -s
==40790== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
My question: My program does nothing. Where does the alloc and free come from?
Interestingly enough, the same program compiled with gcc, shows zero allocs and frees:
> gcc main.c
> valgrind --leak-check=full --track-origins=yes ./a.out
==40740== Memcheck, a memory error detector
==40740== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==40740== Using Valgrind-3.16.0.GIT and LibVEX; rerun with -h for copyright info
==40740== Command: ./a.out
==40740==
==40740==
==40740== HEAP SUMMARY:
==40740== in use at exit: 0 bytes in 0 blocks
==40740== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==40740==
==40740== All heap blocks were freed -- no leaks are possible
==40740==
==40740== For lists of detected and suppressed errors, rerun with: -s
==40740== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Follow up question: Why do the two memory allocations differ, for the same piece of code?
compiler: gcc (GCC) 10.1.0
valgrind: valgrind-3.16.0.GIT
The main function is the entry point of your code. It doesn't have to be (and seldom is) the entry point to the process for the operating system that is loading your program.
There's usually plenty of code running first to set up things needed for the standard library (like setting up the standard I/O streams, and fetching the actual arguments from the operating system) before your main function is called.
And it's important to note that the main function is called like any other function. Once it returns it will return to the initialization code which will now clean up after itself (like freeing memory it might have allocated, and closing streams, etc.).
I'm learning C language from Learn C The Hard Way. I'm on exercise 6 and while I can make it work, valgrind repots a lot of errors.
Here's the stripped down minimal program from a file ex6.c:
#include <stdio.h>
int main(int argc, char *argv[])
{
char initial = 'A';
float power = 2.345f;
printf("Character is %c.\n", initial);
printf("You have %f levels of power.\n", power);
return 0;
}
Content of Makefile is just CFLAGS=-Wall -g.
I compile the program with $ make ex6 (there are no compiler warnings or errors). Executing with $ ./ex6 produces the expected output.
When I run the program with $ valgrind ./ex6 I get errors which I can't solve. Here's the full output:
==69691== Memcheck, a memory error detector
==69691== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==69691== Using Valgrind-3.11.0.SVN and LibVEX; rerun with -h for copyright info
==69691== Command: ./ex6
==69691==
--69691-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option
--69691-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 2 times)
--69691-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 4 times)
==69691== Conditional jump or move depends on uninitialised value(s)
==69691== at 0x1003FBC3F: _platform_memchr$VARIANT$Haswell (in /usr/lib/system/libsystem_platform.dylib)
==69691== by 0x1001EFBB6: __sfvwrite (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x1001FA005: __vfprintf (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x10021F9CE: __v2printf (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x10021FCA0: __xvprintf (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x1001F5B91: vfprintf_l (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x1001F39F7: printf (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x100000F1B: main (ex6.c:8)
==69691==
Character is A.
==69691== Invalid read of size 32
==69691== at 0x1003FBC1D: _platform_memchr$VARIANT$Haswell (in /usr/lib/system/libsystem_platform.dylib)
==69691== by 0x1001EFBB6: __sfvwrite (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x1001FA005: __vfprintf (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x10021F9CE: __v2printf (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x10021FCA0: __xvprintf (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x1001F5B91: vfprintf_l (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x1001F39F7: printf (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x100000F31: main (ex6.c:9)
==69691== Address 0x100809680 is 32 bytes before a block of size 32 in arena "client"
==69691==
You have 2.345000 levels of power.
==69691==
==69691== HEAP SUMMARY:
==69691== in use at exit: 39,365 bytes in 429 blocks
==69691== total heap usage: 510 allocs, 81 frees, 45,509 bytes allocated
==69691==
==69691== LEAK SUMMARY:
==69691== definitely lost: 16 bytes in 1 blocks
==69691== indirectly lost: 0 bytes in 0 blocks
==69691== possibly lost: 13,090 bytes in 117 blocks
==69691== still reachable: 26,259 bytes in 311 blocks
==69691== suppressed: 0 bytes in 0 blocks
==69691== Rerun with --leak-check=full to see details of leaked memory
==69691==
==69691== For counts of detected and suppressed errors, rerun with: -v
==69691== Use --track-origins=yes to see where uninitialised values come from
==69691== ERROR SUMMARY: 5 errors from 2 contexts (suppressed: 0 from 0)
I'm on OS X yosemite. Valgrind is installed via brew with this command $ brew install valgrind --HEAD.
So, does anyone know what's the issue here? How do I fix the valgrind errors?
If the programme you are running through Valgrind is exactly the one you posted in your question, it clearly doesn't have any memory leaks. In fact, you don't even use malloc/free yourself!
It looks to me like these are spurious errors / false positives that Valgrind detects on OS X (only!), similar to what happened to myself some time ago.
If you have access to a different operating system, e.g. a Linux machine, try to analyze the programme using Valgrind on that system.
EDIT: I haven't tried this myself, since I don't have access to a Mac right now, but you should try what
M Oehm suggested: try to use a supressions file as mentioned in this other SO question.
This issue is fixed for Darwin 14.3.0 (Mac OS X 10.10.2) using Valgrind r14960 with VEX r3124 for Xcode6.2 and Valgrind r15088 for Xcode 6.3.
If you are using Macports (at this time of writing), sudo port install valgrind-devel will give you Valgrind r14960 with VEX r3093.
Here's my build script to install Valgrind r14960 with VEX r3124:
#! /usr/bin/env bash
mkdir -p buildvalgrind
cd buildvalgrind
svn co svn://svn.valgrind.org/valgrind/trunk/#14960 valgrind
cd valgrind
./autogen.sh
./configure --prefix=/usr/local
make && sudo make install
# check that we have our valgrind installed
/usr/local/bin/valgrind --version
(reference: http://calvinx.com/2015/04/10/valgrind-on-mac-os-x-10-10-yosemite/)
My macports-installed valgrind is located at /opt/local/bin/valgrind.
If I now run
/opt/local/bin/valgrind --leak-check=yes --suppressions=`pwd`/objc.supp ./ex6
I will get exactly the same errors you described above. (Using my objc.supp file here https://gist.github.com/calvinchengx/0b1d45f67be9fdca205b)
But if I run
/usr/local/bin/valgrind --leak-check=yes --suppressions=`pwd`/objc.supp ./ex6
Everything works as expected and I do not get the system level memory leak errors showing up.
Judging from this topic, I assume that valgrind is not guaranteed to give correct results on your platform. If you can, try this code on another platform.
The culprit is either in valgrid itself or in your system's implementation of printf, both of which would be impractical for you to fix.
Rerun with --leak-check=full to see details of leaked memory. This should give you some more information about the leak you are experiencing. If nothing helps, you can create a suppression file to stop the errors from being displayed.
I'm learning C language from Learn C The Hard Way. I'm on exercise 6 and while I can make it work, valgrind repots a lot of errors.
Here's the stripped down minimal program from a file ex6.c:
#include <stdio.h>
int main(int argc, char *argv[])
{
char initial = 'A';
float power = 2.345f;
printf("Character is %c.\n", initial);
printf("You have %f levels of power.\n", power);
return 0;
}
Content of Makefile is just CFLAGS=-Wall -g.
I compile the program with $ make ex6 (there are no compiler warnings or errors). Executing with $ ./ex6 produces the expected output.
When I run the program with $ valgrind ./ex6 I get errors which I can't solve. Here's the full output:
==69691== Memcheck, a memory error detector
==69691== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==69691== Using Valgrind-3.11.0.SVN and LibVEX; rerun with -h for copyright info
==69691== Command: ./ex6
==69691==
--69691-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option
--69691-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 2 times)
--69691-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 4 times)
==69691== Conditional jump or move depends on uninitialised value(s)
==69691== at 0x1003FBC3F: _platform_memchr$VARIANT$Haswell (in /usr/lib/system/libsystem_platform.dylib)
==69691== by 0x1001EFBB6: __sfvwrite (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x1001FA005: __vfprintf (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x10021F9CE: __v2printf (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x10021FCA0: __xvprintf (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x1001F5B91: vfprintf_l (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x1001F39F7: printf (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x100000F1B: main (ex6.c:8)
==69691==
Character is A.
==69691== Invalid read of size 32
==69691== at 0x1003FBC1D: _platform_memchr$VARIANT$Haswell (in /usr/lib/system/libsystem_platform.dylib)
==69691== by 0x1001EFBB6: __sfvwrite (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x1001FA005: __vfprintf (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x10021F9CE: __v2printf (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x10021FCA0: __xvprintf (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x1001F5B91: vfprintf_l (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x1001F39F7: printf (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x100000F31: main (ex6.c:9)
==69691== Address 0x100809680 is 32 bytes before a block of size 32 in arena "client"
==69691==
You have 2.345000 levels of power.
==69691==
==69691== HEAP SUMMARY:
==69691== in use at exit: 39,365 bytes in 429 blocks
==69691== total heap usage: 510 allocs, 81 frees, 45,509 bytes allocated
==69691==
==69691== LEAK SUMMARY:
==69691== definitely lost: 16 bytes in 1 blocks
==69691== indirectly lost: 0 bytes in 0 blocks
==69691== possibly lost: 13,090 bytes in 117 blocks
==69691== still reachable: 26,259 bytes in 311 blocks
==69691== suppressed: 0 bytes in 0 blocks
==69691== Rerun with --leak-check=full to see details of leaked memory
==69691==
==69691== For counts of detected and suppressed errors, rerun with: -v
==69691== Use --track-origins=yes to see where uninitialised values come from
==69691== ERROR SUMMARY: 5 errors from 2 contexts (suppressed: 0 from 0)
I'm on OS X yosemite. Valgrind is installed via brew with this command $ brew install valgrind --HEAD.
So, does anyone know what's the issue here? How do I fix the valgrind errors?
If the programme you are running through Valgrind is exactly the one you posted in your question, it clearly doesn't have any memory leaks. In fact, you don't even use malloc/free yourself!
It looks to me like these are spurious errors / false positives that Valgrind detects on OS X (only!), similar to what happened to myself some time ago.
If you have access to a different operating system, e.g. a Linux machine, try to analyze the programme using Valgrind on that system.
EDIT: I haven't tried this myself, since I don't have access to a Mac right now, but you should try what
M Oehm suggested: try to use a supressions file as mentioned in this other SO question.
This issue is fixed for Darwin 14.3.0 (Mac OS X 10.10.2) using Valgrind r14960 with VEX r3124 for Xcode6.2 and Valgrind r15088 for Xcode 6.3.
If you are using Macports (at this time of writing), sudo port install valgrind-devel will give you Valgrind r14960 with VEX r3093.
Here's my build script to install Valgrind r14960 with VEX r3124:
#! /usr/bin/env bash
mkdir -p buildvalgrind
cd buildvalgrind
svn co svn://svn.valgrind.org/valgrind/trunk/#14960 valgrind
cd valgrind
./autogen.sh
./configure --prefix=/usr/local
make && sudo make install
# check that we have our valgrind installed
/usr/local/bin/valgrind --version
(reference: http://calvinx.com/2015/04/10/valgrind-on-mac-os-x-10-10-yosemite/)
My macports-installed valgrind is located at /opt/local/bin/valgrind.
If I now run
/opt/local/bin/valgrind --leak-check=yes --suppressions=`pwd`/objc.supp ./ex6
I will get exactly the same errors you described above. (Using my objc.supp file here https://gist.github.com/calvinchengx/0b1d45f67be9fdca205b)
But if I run
/usr/local/bin/valgrind --leak-check=yes --suppressions=`pwd`/objc.supp ./ex6
Everything works as expected and I do not get the system level memory leak errors showing up.
Judging from this topic, I assume that valgrind is not guaranteed to give correct results on your platform. If you can, try this code on another platform.
The culprit is either in valgrid itself or in your system's implementation of printf, both of which would be impractical for you to fix.
Rerun with --leak-check=full to see details of leaked memory. This should give you some more information about the leak you are experiencing. If nothing helps, you can create a suppression file to stop the errors from being displayed.
I have problems getting Helgrind and DRD working with g++ and C++11 threads.
My setup:
- RedHad Linux 2.6
- g++ 4.7.2
- Valgrind 3.7.0
I tried the program posted here, after adding the definitions listed in the first answer, thus:
#include <valgrind/helgrind.h>
#define _GLIBCXX_SYNCHRONIZATION_HAPPENS_BEFORE(addr) ANNOTATE_HAPPENS_BEFORE(addr)
#define _GLIBCXX_SYNCHRONIZATION_HAPPENS_AFTER(addr) ANNOTATE_HAPPENS_AFTER(addr)
#define _GLIBCXX_EXTERN_TEMPLATE -1
#include <thread>
int main()
{
std::thread t( []() { } );
t.join();
return 0;
}
I then build the program:
$ g++ -std=c++11 -Wall -Wextra -pthread main.cc
The program (which doesn't do much) runs correctly:
$ ./a.out
also with valgrind:
$ valgrind ./a.out
==21284== Memcheck, a memory error detector
==21284== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==21284== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==21284== Command: ./a.out
==21284==
==21284==
==21284== HEAP SUMMARY:
==21284== in use at exit: 0 bytes in 0 blocks
==21284== total heap usage: 2 allocs, 2 frees, 344 bytes allocated
==21284==
==21284== All heap blocks were freed -- no leaks are possible
==21284==
==21284== For counts of detected and suppressed errors, rerun with: -v
==21284== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6)
But then, with Helgrind, I get false positives:
$ valgrind --tool=helgrind ./a.out
==21467== Helgrind, a thread error detector
==21467== Copyright (C) 2007-2011, and GNU GPL'd, by OpenWorks LLP et al.
==21467== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==21467== Command: ./a.out
==21467==
==21467== ---Thread-Announcement------------------------------------------
==21467==
==21467== Thread #1 is the program's root thread
==21467==
==21467== ---Thread-Announcement------------------------------------------
==21467== [lines removed]
==21467==
==21467== ----------------------------------------------------------------
==21467==
==21467== Possible data race during write of size 8 at 0x5B7A058 by thread #1
==21467== Locks held: none
==21467== [lines removed]
==21467==
==21467== This conflicts with a previous write of size 8 by thread #2
==21467== Locks held: none
==21467== at 0x4EE0A25: execute_native_thread_routine (shared_ptr_base.h:587)
==21467== by 0x4C2D3AD: mythread_wrapper (hg_intercepts.c:219)
==21467== by 0x55D1850: start_thread (in /lib64/libpthread-2.12.so)
==21467== by 0x58CF90C: clone (in /lib64/libc-2.12.so)
==21467==
==21467== [lines removed]
==21467==
==21467==
==21467== For counts of detected and suppressed errors, rerun with: -v
==21467== Use --history-level=approx or =none to gain increased speed, at
==21467== the cost of reduced accuracy of conflicting-access information
==21467== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
Similar bogus reports with DRD instead of Helgrind.
Any idea what could be wrong?
I found this in drd manual. It seems you need to recompile the functions execute_native_thread_routine() and std::thread::_M_start_thread(), and link it with your program(And not using the shared library at execution time for these functions).
Actually the macros _GLIBCXX_SYNCHRONIZATION_HAPPENS_* are seen by your code but they were not seen by the internal functions of the c++ library code when this library was built. That's why you need to recompile them using the same header inclusion and macro definition you used for your code.