Re: how to break out of the libtool rathole ?

[Dennis Clarke]

> 
> libtool the script is built locally before it is used to build 
> libltdl, though there is some fiddling involved in calling autoreconf 
> correctly so that it doesn't get confused about not having an 
> installed libtool available, or try to use an different version of 
> libtool from the search PATH in preference to the one in the current 
> build tree.
> 
> > A circular dependency on itself, is just plain EVIL.

Let me rephrase :  I should not need tool A installed into my PATH
                              in order to build tool A.  

It looked, that is to say "appeared" as if libtool was required to build 
libtool. 

 
> You mean, like autoconf, or even gcc?

Hold on a sec, I build autoconf from source without autoconf being installed
anywhere so that isn't a great example.  GCC is a tougher nut to crack
and I have been doing GCC builds and tests for well over a decade. 

See : http://gcc.gnu.org/gcc-4.8/buildstat.html

    therein we have a few guys that work quite hard to get reliable GCC 
    builds on the Solaris SPARC environment, myself and Rainer Orth being
    the two resident old grey haired guys. 

In fact, you have revealed my nefarious purpose for this old Solaris 8 
server.  You may look at all of the XXX-pc-solaris2.XX reports on that 
page and see that Rainer has posted results.  In the GCC 4.7 tree we
have some results in the Solaris 8 world 
http://gcc.gnu.org/gcc-4.7/buildstat.html
however no one has been able to get a build in the Solaris 8 world 
for GCC 4.8.x.  The discussion internally was that GCC should drop 
the Solaris 8 platform as a primary supported OS and yes, all 
agree.  However, those of us in the old SPARC world know that the
kernel interfaces within the last released edition of Solaris 8 are in
fact the same interfaces supported all the way up to Solaris 11.
What this means is that a GCC build within Solaris 8 will work with
absolute flawless reliability all the way up to the latest releases on
the latest Oracle SPARC T5 servers. 

Why such passion for getting a GCC out to the world on the Solaris 
SPARC platform?  Because the switchover from Sun to Oracle had a 
lot of fallout upon us open source types.  Not the least of which was
that the compilers ( Sun Forte -> Sun Studio -> Oracle Studio ) all 
became very expensive to maintain.  You can download them for 
free but then find out that you need a pile of patches and updates 
to use them with reliability.  Here comes thousands of dollars for 
the OS support before you pay thousands of dollars for the compilers.

That implies a reliance upon GCC, which, in my opinion, is a wonderful
compiler. 

However, no one has been able to get good results and I figure it will
take three months work. 

Then I fell upon too much coffee and libtool.   ;-)

> Back to the last libtool-2.4.2 release tarball my environment is a 
> little different to yours, though I set things up to match as closely 
> as I could for each of your many emails in this thread (I note that 
> you've called configure with different shell tools among other things 

I tried a number of things to get a result.  I was, to be honest, flailing.

However my build of bash 4.2 seems to work very well and I know that
perl passed all its tests as did the other bits I built from scratch first.

> in each case - on Solaris in particular which has well known problems 
> with sh, make, sed, tar and others, 

God yes. 

Hence the builds of GNU sed, GNU bash, etc. 

> I recommend putting links to a 
> known good set of utilities in, say, /opt/fsw and adding that to the 
> front of your PATH to save picking up any of Sun's brain damaged 
> utilities by mistake).

I think you mean old XPG4 compliant tools in /usr/xpg4/bin and yes 
I have the necessary tools in /usr/local/bin .

>  In all cases I was able to get a functioning 
> build that did not fail any of the supplied self tests.

holy hell.

> The only other things I can think of that might be tripping you up are:
> 
>   1. Your extraction process is screwing up the timestamps (I couldn't 
> find 'sx' online, the tool you use in one of your reports), I just 
> used GNU tar, because Sun's tar doesn't cope will with some tar files 
> that gtar produces - and pretty much everything you download from 
> gnu.org was packed with GNU tar.

That is an alias.  Sorry.  I have to type the old gzip -dc foo | tar -xf - over
and over and over and so sx does that.  I also use Jorg Schillings "star" 
all the time because it can extract anything from anything with perfect
reliability as well as POSIX compliance. 

>   2. Your filesystem is screwing up timestamps - are you building on a 
> network mount?  Try extracting to and building on a local disk, say /tmp.

Nope.  This is all local disks on the machine. 

So I will however take a close look at what NTP is doing.  Just in case. 

>   3. You're using Sun's make (although since you are calling gmake, I 
> suspect not) -

Yes, using GNU make.  This is in fact, the very FIRST tool I create every
time. Then I create and test libiconv and GNU gettext and then rebuild
GNU make with --enable-nls and then run all the tests.  One must have a 
GNU make first before all else. 

> make for subprocesses.  After a successful configure, try 'gmake 
> MAKE=gmake' to prevent that happening.

yes, I have MAKE=/usr/local/bin/gmake 

> Hope that helps,

yes, this does.  This really does and I thank you for it.  At no point did you
point a finger and tell me I was off my meds and clearly hacking files in
the source tree. 

Enough of that ... I will go back to square one and try again and with very
special care paid to previous tools build. 

Dennis