This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Tru64 5.1 bootstrap fails with missing symbols: libiconv et al.


--- Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> wrote:
> Dara Hazeghi <dhazeghi@yahoo.com> writes:
> 
> What --prefix did you use.  Is this an empty
> directory, or is any software
> installed there?  What was the exact configure line
> used?

../gcc/configure --prefix=/tmp/gcc33


> > 
> > Strange thing is that the libiconv is being linked
> > against... Any ideas? Thanks,
> 
> Sure: this libiconv stuff is currently a terrible
> mess ;-(  Do you happen
> to have GNU libiconv installed in $prefix?

Nope, its an empty directory.

> This regularly happens for me in the following
> situation:
> 
> * I start bootstrap with gcc 3.1 installed in the
> same directory hierarchy
>   as GNU libiconv, so the bootstrap compiler finds
> and uses it.
> 
> * The new compiler uses a different $prefix, and
> doesn't search the
>   bootstrap compiler's hierarchy.  While during
> stage1, GNU libiconv and
>   it's iconv.h were used, stage2 uses the system
> iconv.h and libiconv,
>   which doesn't provide the libiconv_* functions.

I see! Looking at config.log, I see...

configure:4104: checking for working vfork
configure:4294: checking for iconv
configure:4312: cc -o conftest -g   conftest.c  1>&5
ld:
Unresolved:
iconv_open
iconv
iconv_close
configure: failed program was:
#line 4302 "configure"
#include "confdefs.h"
#include <stdlib.h>
#include <iconv.h>
int main() {
iconv_t cd = iconv_open("","");
       iconv(cd,NULL,NULL,NULL,NULL);
       iconv_close(cd);
; return 0; }
configure:4334: cc -o conftest -g   conftest.c  
-liconv 1>&5
configure:4355: checking for iconv declaration
configure:4380: cc -c -g  conftest.c 1>&5
configure:4418: checking whether getenv is declared

So what I don't understand is that the test obviously
failed, yet its still trying to link...

I see, there's a GNU libiconv in /usr/local.

Adding it to INTLLIBS seems to get me past that
failure point. I'll continue bootstrapping...

> 
> As you can see, a terrible mess.  I haven't yet
> gotten around to
> properly fixing this.

Does Zack's work on mainline help with this problem at
all? Right now it seems ...unintuitive... :-) But if
you don't have GNU libiconv installed, this problem
shouldn't happen, right (bootstrapping on a clean
system should work)?


> > P.S. Is the -oldas option still required to
> bootstrap
> > on this platform (as described in
> install/specific.html)?
> 
> Why do you think so?  install.texi clearly states
> that you only need this
> if bootstrapping starting from an old version of gcc
> built for Tru64 UNIX
> V4.0.  But you are right: if you start bootstrap
> with a version of GCC
> already built properly for Tru64 UNIX V5, this
> becomes unnecessary.

Well, I take issue with the _clearly_ part. It says
you need to use -oldas, but immediately after talks
about using Compaq's C compiler. I took that to mean
that when using Compaq's compiler, you'd need this
option. From what you say above, this isn't so?

Thanks for the help,

Dara

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]