Bug #14177 2008-07-10 05:08

sdbtietz

~ is corrupted when used in an include path

I have not characterized this completely, but what I know is that a source file in my project has this line:

#include "bfd/bfd.h"

If I add this to Project -> Build Options... -> Search directories -> Compiler, it works:

/home/<me>/src/binutils-2.17

...then it works.  But if I add this instead:

~/src/binutils-2.17

Then compilation fails with this error:
error: bfd/bfd.h: No such file or directory

I know that it is not gcc that is barfing on -I~/src/binutils-2.17 because the project builds fine with this in its makefile:

ifndef BINUTILS_SRC_PATH
	BINUTILS_SRC_PATH   := ~/src/binutils-2.17
endif
INC_PATH       += -I $(BINUTILS_SRC_PATH)

You may be asking why does this matter...  I have a not-yet-released open source project.  One of the services in the core library is an augmented assert implementation which, when an assert fires, generates a call stack in an AssertLog.txt file that can be sent back to the developer by an end user.  To generate a meaningful assert log though, I'm using parts of binutils to get the names of the functions on the call stack.  Problem: it's open source, so not only does binutils need to be present, but budemang.o, libbfd.a, and libiberty.a need to be present along with the necessary headers.  Slightly painful for coders wanting to use this library, but that's what README.TXT is for.  During development (playing with my lib under linux at work) I found that /usr/src isn't adequate because often, the user doesn't have the ability to ensure that /usr/src/binutils-2.17 is present and its contents populated with build outputs.  Wasn't there for me, and IT said no when I asked for access.  So I fell back to ~/src unless an environment variable specifies otherwise.  Best I could do.  Anyway I've been using makefiles for this project but would love to be able to code in a decent IDE on linux.  Code::Blocks looks to be just that, so I've spent the evening porting my project to that environment.  If it "just works" or the path to making it work can be clearly documented, I wouldn't mind Code::Blocks being a prerequisite for other developers using my lib on linux.

Might as well report another bug too...  At least on Fedora FC7, the compiler autodetect doesn't work right.  It ends up mapping to /usr/lib.  But...

$ ls /usr/lib/gcc
.  ..  i386-redhat-linux
$ ls /usr/lib/gcc/i386-redhat-linux/
.  ..  4.1.2
$ ls /usr/lib/gcc/i386-redhat-linux/4.1.2/
.   crtbegin.o   crtbeginT.o  crtendS.o      include   libgcc_eh.a  libgcov.a  libgomp.so    libstdc++.a   libsupc++.a
..  crtbeginS.o  crtend.o     crtfastmath.o  libgcc.a  libgcc_s.so  libgomp.a  libgomp.spec  libstdc++.so  SYSCALLS.c.X

Even this gives the wrong answer:
$ which gcc
/usr/lib/ccache/gcc

because...
$ ls -l /usr/lib/ccache/gcc
lrwxrwxrwx 1 root root 15 2008-03-12 21:20 /usr/lib/ccache/gcc -> /usr/bin/ccache

and...
$ ls -l /usr/bin/ccache 
-rwxr-xr-x 1 root root 40300 2007-03-15 07:08 /usr/bin/ccache

The only way I got the toolchain to work at all is setting "Compiler's installation directory" to /usr/bin.

Anyway...I'm giving up on Code::Blocks for now but other than these hiccups I like what I see so far.  Keep up the good work.  I hope these deficiencies can be address soon because I'd love to come back to it.

Category

Compiler

Group

 

Status

Open

Close date

 

Assigned to