opencog / cogutil

Very low-level C++ programming utilities used by several components

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

CMake BFD_FOUND false

williampma opened this issue · comments

On Ubuntu 14.04 LTS, even with binutils-dev installed, cmake is not detecting it (and BFD_FOUND is false in the CMakeLists.txt).

Manually commenting out the #IF (BFD_FOUND) check works to enable pretty print, so binutils-dev is indeed installed.

BFD_LIBRARY in FindBFD.cmake is found, but CHECK_INCLUDE_FILES (bfd.h HAVE_BFD_H) is unable to find bfd.h, even though it is in /usr/include

Its probably not found because the following fails to compile:

#include <bfd.h>
main() {}

Can you see if the above works, and if not, what the error is? Just use plain cc, no flags.

#include <bfd.h>
#include <stdio.h>

int main()
{
    printf("test\n");
    return 0;
}

compiles with no error and runs with no problem.

how about without the stdio? The cmake function tried to autocompile a
minimal program that only does #include <bfd.h> and that is failing for
some reason, thus cmake concludes you don't have bfd.h

Unlike automake, though cmake does not tell you what it tried to compile,
or how it failed, so its harder to debug. You can somtimes catch a glimpse
of the failure in the cmake log files... (in the build/CMakefiles/
directory)

On Wed, May 6, 2015 at 9:36 PM, William Ma notifications@github.com wrote:

#include <bfd.h>
#include <stdio.h>

int main()
{
printf("test\n");
return 0;
}

compiles with no error and runs with no problem.


Reply to this email directly or view it on GitHub
#1 (comment).

Without stdio also compiles without error.

I will take a look at the directory you mentioned to see if there's anything that solve this.

Ah, found the error from CMake:

Determining if files bfd.h exist failed with the following output:
Change Dir: /home/william/cogutils/build/CMakeFiles/CMakeTmp

Run Build Command:/usr/bin/make "cmTryCompileExec2562422766/fast"
/usr/bin/make -f CMakeFiles/cmTryCompileExec2562422766.dir/build.make CMakeFiles/cmTryCompileExec2562422766.dir/build
make[1]: Entering directory `/home/william/cogutils/build/CMakeFiles/CMakeTmp'
/usr/bin/cmake -E cmake_progress_report /home/william/cogutils/build/CMakeFiles/CMakeTmp/CMakeFiles 1
Building C object CMakeFiles/cmTryCompileExec2562422766.dir/CheckIncludeFiles.c.o
/usr/bin/cc   -Wl,--copy-dt-needed-entries    -o CMakeFiles/cmTryCompileExec2562422766.dir/CheckIncludeFiles.c.o   -c /home/william/cogutils/build/CMakeFiles/CMakeTmp/CheckIncludeFiles.c
In file included from /home/william/cogutils/build/CMakeFiles/CMakeTmp/CheckIncludeFiles.c:2:0:
/usr/include/bfd.h:38:34: fatal error: <libiberty/ansidecl.h>: No such file or directory
 #include "<libiberty/ansidecl.h>"
                                  ^
compilation terminated.
make[1]: Leaving directory `/home/william/cogutils/build/CMakeFiles/CMakeTmp'
make[1]: *** [CMakeFiles/cmTryCompileExec2562422766.dir/CheckIncludeFiles.c.o] Error 1
make: *** [cmTryCompileExec2562422766/fast] Error 2

Source:
/* */
#include <bfd.h>


int main(){return 0;}

ansidecl.h exists in /usr/include/libiberty, no idea why it complains about that.

ooh, must be related to opencog/opencog#696

Bingo. answer seems to be to .. uninstall libiberty-dev !?? or hack

sudo vim /usr/include/bfd.h +38
and deleting " from "< libiberty/ansidecl.h >" (i.e making it < libiberty/ansidecl.h >) made it compile. I think " is misleading gcc/g++ to look in the wrong directory.

Well, after various uninstall and reinstall of both binutils-dev and libiberty-dev, suddenly it works, even though both packages are installed, and there's still 2 versions of ansidecl.h in 2 different directories.

So I guess I can close this now. Thanks!

nah, read issue #696 to the end: there are two ansidecls.h or something
like that; one defines needed things, the other doesn't ... both use the
same file protection #ifdef. its a mess.

On Wed, May 6, 2015 at 11:11 PM, Misgana Bayetta notifications@github.com
wrote:

sudo vim /usr/include/bfd.h +38
and deleting " from "" (i.e making it ) made it compile. I think " is
misleading gcc/g++ to look in the wrong directory.


Reply to this email directly or view it on GitHub
#1 (comment).

Yes, there are two ansidecl.h ( one in /usr/include and one in usr/include/libiberty). But according to my understanding " tells g++ to look in the current directory and fails to find libiberty directory inside libiberty directory. Removing " proved my understanding. changing the include to "ansidecl.h" or < ansidecl.h > are also another hacks that worked.

ah, yes, right. good point.

On Wed, May 6, 2015 at 11:26 PM, Misgana Bayetta notifications@github.com
wrote:

yes there are two ansidecl.h ( one in /usr/include and one in
usr/include/libiberty). But according to my understanding " tells g++ to
look in the current directory and fails to find libiberty directory inside
libiberty directory. Removing " it proved my understanding. changing the
include to "ansidecl.h" and also is another hack that worked.


Reply to this email directly or view it on GitHub
#1 (comment).

it was working yesterday when I pulled. but now it has stopped working and again gives the same error that BFD not found.

Ainish, hopefully, your code will not be provoking crashes and so you don't really need this.

William needed this because he's an old-timer who is working on the internals of the system; I don't expect that you will touch any of the internals.