Annoying tech work-related question (gcc dynamic linker errors)

[bhodi]

OK so, I'm not autoconf whiz. I'm not a linker whiz. I barely know what ldd does. Here's the situation. I've been working on it for about 2 days straight and I'm pretty much googled out. I barely understand most of the concepts, and I'm a bit out of my element. I figured I'd throw it out here to see because I'm pretty much going in circles at this point. My problem is this:

g++ is borked, even a basic g++ -o hello hello.cpp "hello world" program dumps errors such as this:

/prod/build/jsenseman/svn/gcc/src/gcc-3.4.4/i686-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:1456: undefined reference to `libintl_bindtextdomain'
/prod/build/jsenseman/svn/gcc/fakeroot/usr/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/../../../libstdc++.a(wlocale-inst.o) (.gnu.linkonce.t._ZNKSt8messagesIwE7do_openERKSsRKSt6locale+0xf): In function `std::messages<wchar_t>::do_open(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::locale const&) const':
/prod/build/jsenseman/svn/gcc/src/gcc-3.4.4/i686-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:1456: undefined reference to `libintl_textdomain'
collect2: ld returned 1 exit status

The issue can be worked around by explicitly linking at compile time:

g++ hello.cpp -o hello -L/usr/local/lib -Wl,--rpath=/usr/local/lib -lintl

but I need to compile g++ with the correct linker info built in. My issue is this. Normally I'd just throw it in the LDFLAGS but since a gcc bootstrap compile goes through 3 stages (compiles itself, then uses that to compile itself, and once more for good luck), it doesn't seem to stick by the third and final compile. I tried LIBCXXFLAGS, but no dice. I read that doing it with a -R might work, but gcc doesn't accept -R as an argument. It should be the same as --rpath anyway, if I'm not mistaken. I also can't force it through the triple make with a 'CC=gcc -L/usr/local/lib', doesn't seem to help.

The error itself comes from (I believe, anyway) a libintl dependency that it's simply not finding by itself. I think. I'm pretty lost here. I don't really understand how linker directory/paths get compiled in or how it uses dynamic linkers at runtime. I'm not really a coder :/

Anyway, any ideas or help would be appreciated. my configure flags are (this is cut and pieced from a bit more complicated makefile, but you get the idea)

export LD_RUN_PATH=/usr/local/lib
export LD_LIBRARY_PATH=/usr/local/lib
./configure --prefix=$(INSTALLDIR) \
                            --disable-nls  \
                            --enable-languages=c,c++ \
                            --with-libiconv-prefix=/usr/local \
                            --enable-threads \
                            --disable-shared \
                            --with-ld=ld \
                            && gmake bootstrap

and more relevant info:

gcc (GCC) 3.4.4
GNU ld version 2.15.92.0.2 20040927
autoconf (GNU Autoconf) 2.59
GNU Make 3.80
GNU bash, version 3.00.15(1)-release

[Trippy]

What Linux distribution is this?

[bhodi]

Linux hostname.net 2.6.9-22.ELsmp #1 SMP Mon Sep 19 18:32:14 EDT 2005 i686 i686 i386 GNU/Linux

it's RHWS4. Custom g++ from god knows where, it's not the default that came with it. I'm trying to compile either 3.4.6 or 3.4.4, same issue either way. Can't go to 4.1 and can't use the default rpm for a variety of reasons, mostly because we've replaced some glibc and it's dependencies.

It's all hacked up, and I basically started two weeks ago and am getting thrown all the stuff that others don't want to deal with ;)

[Trippy]

Have you tried setting BOOT_CFLAGS?

[bhodi]

that may be the parameter I need. I hate gcc. Why does it have to be special. I'll let you know in .. oh, about 15m. I knew there was a way to give the final stage compile flags, I just didn't know how.

[stray]

So is it a work machine? Did someone else install this bastardized version of GCC? If not, then it sounds like you'd be better off reinstalling and sticking with the default compiler version, and upgrading only through official channels. Linux can be pretty finicky about compiler upgrades, especially through RPM based distros like Red Hat.

[bhodi]

Yes, yes, and yes, I agree, but unfortunately not possible for a variety of reasons, mostly different versions of libs that I'd be hard pressed to sort out, and also I don't own this machine I've just been asked to get a working gcc on there. If it were mine, things would be different, but, alas.

the BOOT_CFLAGS didn't do much, so right now I'm trying to get a single stage working. Maybe that will pay attention to one of those exported variables.

It's reading the CFLAGS correctly on a single stage compile, but it seems to really not like CFLAGS=-L/usr/local/lib -Wl,--rpath=/usr/local/lib -lintl . looks like there's some header conflicts. Tracking down which part it doesn't like.

cplus-dem.c:55: error: conflicting types for 'malloc'
cplus-dem.c:55: error: conflicting types for 'malloc'
cplus-dem.c: In function `code_for_qualifier':
cplus-dem.c:630: warning: implicit declaration of function `abort'
cplus-dem.c: In function `squangle_mop_up':
cplus-dem.c:1154: warning: implicit declaration of function `free'
cplus-dem.c: In function `demangle_qualified':
cplus-dem.c:3310: warning: implicit declaration of function `atoi'

[bhodi]

I give up for tonight. Any time I try and link in -lintl or something from the /usr/local/lib directory, it conflicts as shown above. Any of the 3 CFLAG params do it alone. I'm goin to bed :/

I have no idea why it magically works or how to incorporate that into the end product gcc.