This is the mail archive of the gcc@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]

Re: libtool (was: GCC 3.0: sparc-sun-solaris2.8 fails to build today)


On Jun 10, 2001, Mark Mitchell <mark@codesourcery.com> wrote:

>>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:
Alexandre> shell, called /bin/ksh, so I'm inclined to simply
Alexandre> document that Solaris users should set
Alexandre> CONFIG_SHELL=/bin/ksh and be done with it.  What do you
Alexandre> think?

> I think this is good.  In fact, I think that if we can do this
> automatically in some way, we should try to do so.

I wouldn't go that far.  Out of 4 Solaris boxes in which I test GCC
weekly, only one of them fails, and even then, it doesn't fail
consistently.  After you get a failure, it's easy enough to fix the
problem and proceed from where it stopped.  Both of these workarounds
have consistently worked for me:

        make SHELL=/bin/ksh bootstrap 

and

        rm *-solaris*/config.cache
        make bootstrap


Another problem I've been investigating is that of building libgcj on
Solaris 8 using the same prefix as that of a previously-installed copy
of libgcj.  Solaris' linker apparently tries to out-smart the user, by
claiming the already-installed library conflicts with the one in the
build tree, even though the program being linked is only going to be
run after the libraries in the build tree are already installed.  I
couldn't find any way to tell the linker that what we're telling it to
do is actually ok, so, should we want to enable libgcj on Solaris 8
(it's currently disabled), I see only two alternatives:

- Recommend the use of --disable-fast-install as a configure switch on
Solaris 8.  This libtool configure switch causes the build not to be
optimized for installation, but for execution in the build tree.  This
will have the effect of the installable programs only being built at
install time, when the libraries have already been installed.  I
haven't had time to investigate whether this will actually fix the
problem, particularly because I haven't been able to create a simple
scenario in which the problem shows up.  But, in theory, it might
help.

- Recommend the use of GNU ld, since it works correctly.


Opinions?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me


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