florian.heigl@gmail.com wrote:
> How did You switch over to bash? is it enough to simply call the
> configure from inside a bash?
>
> I definitely want to try this (after the next build break, that is...)
>

RTFM. I believe you point to it by setting the CONFIG_SHELL env
variable, but trust the docs, not my memory.

No, if you tmp file is full (inode or size), this won't fix that - but
it does alleviate the performance issue.

Why they won't fix ksh remains a mystery to me. Support refused to
acknowledge the problem over 2 years ago.

Cheers.

Timothy J. Bogart schrieb:

> RTFM. I believe you point to it by setting the CONFIG_SHELL env
> variable, but trust the docs, not my memory.

Calling bash, and then exporting SHELL and CONFIG_SHELL convinced the auto*

From what I have seen, one main problem is the configuration of the C++
lib. On AIX GCC there are different runtime libs built for the different
CPU architectures. No problem so far. But when later the C++ libs are
tried to configure, the corresponding libs are loaded/executed. This
will fail if the code cannot be executed on the host CPU. aix64 on a
PPC604e, or the powerpc on an old power machine. I have no idea how it
works on the GCC developers machines. They discuss dropping support for
AIX 4.3.3 instead.

I believe the automagic's main purpose is to prevent the source from
being used outside the religious GNU universe.

I don't understand why it should be easier to tweak
automake/autoconf/auto* compared to editing a line in a commented Makefile.
The first usually takes longer then the subsequent compile, the second
less than a minute include a search over the Makefile.
The compilation can further slowed down with the use of "libtool".
Another complex solution for a simple problem.

Most GNUish packages don't know anything about building/using shared
libs or threads on AIX. Some claim to be portable, but are never built
on anything but Linux/GCC.

But there is Perl. I learned much about AIX by looking through the
config scripts of Perl tarballs. It is possible!

The last out-of-tarball working GCC on AIX 4.3.3 was GCC 3.2.3.

If there is a need for using GCC instead of XLC, I would simply
recommend using the GCC from AIX' toolbox.

--
Uli

Uli Link wrote:
> Timothy J. Bogart schrieb:
>
>> RTFM. I believe you point to it by setting the CONFIG_SHELL env
>> variable, but trust the docs, not my memory.
>
>
> Calling bash, and then exporting SHELL and CONFIG_SHELL convinced the auto*
>
> From what I have seen, one main problem is the configuration of the C++
> lib. On AIX GCC there are different runtime libs built for the different
> CPU architectures. No problem so far. But when later the C++ libs are
> tried to configure, the corresponding libs are loaded/executed. This
> will fail if the code cannot be executed on the host CPU. aix64 on a
> PPC604e, or the powerpc on an old power machine. I have no idea how it
> works on the GCC developers machines. They discuss dropping support for
> AIX 4.3.3 instead.

IIRC, there was invented a thing called 'common mode' when the PPC came
out with a subset of functions, and there are different *optimized*
runtimes for different CPU architectures.

When one thinks about it, one either never adds functions in newer CPUs
or you never have optimized code for newer machines. Perhaps I am
missing something here.
>
> I believe the automagic's main purpose is to prevent the source from
> being used outside the religious GNU universe.

Don't cut yourself on your tinfoil hat.....
>
> I don't understand why it should be easier to tweak
> automake/autoconf/auto* compared to editing a line in a commented Makefile.
> The first usually takes longer then the subsequent compile, the second
> less than a minute include a search over the Makefile.
> The compilation can further slowed down with the use of "libtool".
> Another complex solution for a simple problem.
>
> Most GNUish packages don't know anything about building/using shared
> libs or threads on AIX. Some claim to be portable, but are never built
> on anything but Linux/GCC.

Shared libs are the default on AIX, and always has been, at least in the
Power world. You have to do extra work to make static libraries. I
suspect you are falling for the historical .so baloney. A library name
does not need to end in .so to be a shared library.
>
> But there is Perl. I learned much about AIX by looking through the
> config scripts of Perl tarballs. It is possible!
>
> The last out-of-tarball working GCC on AIX 4.3.3 was GCC 3.2.3.
>
> If there is a need for using GCC instead of XLC, I would simply
> recommend using the GCC from AIX' toolbox
>

And a look at the toolbox shows that more than one, er, ten, er whatever
, packages that are portable to AIX. You will find notes in the major
packages for almost exactly umpteen different architectures/OSes.

Looking over the last 15 years or so since spending any significant time
building gnu stuff on different platforms - for fun, or for developers
who request it - my conclusion is that some packages are more friendly
for porting than others, and some packages (notably gcc) go thru phases
of having problmes on some platforms.

Ever bothered to go thru bugzilla for your issues?

Guess it is just easier to whine. I know that works for me often. 8-)

> IIRC, there was invented a thing called 'common mode' when the PPC came
> out with a subset of functions, and there are different *optimized*
> runtimes for different CPU architectures.

When optimizing for the different architectures GCC does it's compiler
optimization and puts the directories (-blibpath with the libs
optimized for this target in front of the common ones.

> When one thinks about it, one either never adds functions in newer CPUs
> or you never have optimized code for newer machines. Perhaps I am
> missing something here.

I expect, that when I give the top-level configure the switch for
completly disabling multilibs, the aix64 target is disabled too!
If there is a configure, first it's the job of the configure to find out
what can be build and what not, second I will always accept that the
configure needs help in form of flags, if they are guessable or
preferred documented in INSTALL, README or README.platform.

If the build depends on the 64bit target, the 32bit target must declared
obsolete. The docs still talk about AIX 4.x (which also AIX 4.1.5 or
4.2.1 clearly is)

>> Most GNUish packages don't know anything about building/using shared
>> libs or threads on AIX. Some claim to be portable, but are never built
>> on anything but Linux/GCC.
>
> Shared libs are the default on AIX, and always has been, at least in the
> Power world.

I know this is true for the system, but before 4.2.1 building shared
libs was only possible by calling ld after manually building the list
with the symbols to be exported.
On Linux or Solaris building shared libs *was* easier. So the default of
the system made it into the Open Source packages, not so with AIX.

> You have to do extra work to make static libraries. I
> suspect you are falling for the historical .so baloney. A library name
> does not need to end in .so to be a shared library.

The name does not really matter.
An simple Example we all know: libz
When you install the Toolbox, you'll find an archive /usr/lib/libz.a
This contains the member libz.so.1 which is the real shared lib.

The libz from Bull is build different, The one from UCLA different.
Each one cannot replace the other without relinking the application.

What does a typical (not all!) source package on AIX? Statically linking .
Why? Because the build system with the tarball cannot really guess which
"style" the libs should be build.

This lack of a stringent style guide is IMHO a lack of AIX.

My personal rule is: when there is a lib from IBM, I want to replace
with a newer version, I build this lib the IBM Toolbox way.
So I replaced libz.a with version 1.2.2 and all apps were happy by
replacing a single file (+ headers for future builds).

> And a look at the toolbox shows that more than one, er, ten, er whatever
> , packages that are portable to AIX. You will find notes in the major
> packages for almost exactly umpteen different architectures/OSes.

Yes. Investigating the (sometimes small) difference between the original
source and the corresponding IBM patch shows how little change is
needed. But it must be an impossible job to tell this all the auto*
stuff, isn't it?
Can you point me to the RTFM solution with autoconf?
I will read and try to understand it.

> Looking over the last 15 years or so since spending any significant time
> building gnu stuff on different platforms - for fun, or for developers
> who request it - my conclusion is that some packages are more friendly
> for porting than others, and some packages (notably gcc) go thru phases
> of having problmes on some platforms.

Full ACK.
The KISS principle helps to keep things portable.
All this auto* stuff claims to make things easier. And it is great if
things works, all is recognized and configured in a working manner.
But on AIX this stuff fails much more often than on other platforms.
If something fails, it is very, very hard to understand where the
one-little-magic-compiler-flag must be set.
This stuff is readable as C code with all blanks removed and all
variables/functions named by 4-digit random hex.


> Ever bothered to go thru bugzilla for your issues?

Yes. Found several seems-to-be-the-same-matter bugs reported.
Later I found a machine with VACPP 5.0 installed and a nodelocked
license on ebay :-) And for me many problems were solved.

But you didn't anwer to my question what "libtool" is easier with than
without.

--
Uli

Uli Link wrote:
>
>> IIRC, there was invented a thing called 'common mode' when the PPC
>> came out with a subset of functions, and there are different
>> *optimized* runtimes for different CPU architectures.
>
>
> When optimizing for the different architectures GCC does it's compiler
> optimization and puts the directories (-blibpath with the libs
> optimized for this target in front of the common ones.
>
>> When one thinks about it, one either never adds functions in newer
>> CPUs or you never have optimized code for newer machines. Perhaps I
>> am missing something here.
>
>
> I expect, that when I give the top-level configure the switch for
> completly disabling multilibs, the aix64 target is disabled too!
> If there is a configure, first it's the job of the configure to find out
> what can be build and what not, second I will always accept that the
> configure needs help in form of flags, if they are guessable or
> preferred documented in INSTALL, README or README.platform.
>
> If the build depends on the 64bit target, the 32bit target must declared
> obsolete. The docs still talk about AIX 4.x (which also AIX 4.1.5 or
> 4.2.1 clearly is)

Agreed. Odd, but I remember that in the 3 days, this was something of
an issue, and as of 4, common-mode was to be the default. Seems that
with the introduction of 64 bit, things have foofed again.

I just tried the 4.1 build on my 44p-170 in 64 bit mode and got that
error about '64 bit not allowed in 32 bit mode. For fun, I have booted
into 32 bit mode just to see if it is a clean build there.

Will look more at the libpath stuff, especially if 32bit builds clean.

Oops, just popped over to the box, and it doesn't even boot clean in 32
bit mode, as too many system component - like networking and fsck (!)
are 64 bit - or so it claims.

Guess I will be looking at the 64 bit stuff earlier than I expected. 8-(
>
>>> Most GNUish packages don't know anything about building/using shared
>>> libs or threads on AIX. Some claim to be portable, but are never
>>> built on anything but Linux/GCC.
>>
>>
>> Shared libs are the default on AIX, and always has been, at least in
>> the Power world.
>
>
> I know this is true for the system, but before 4.2.1 building shared
> libs was only possible by calling ld after manually building the list
> with the symbols to be exported.
> On Linux or Solaris building shared libs *was* easier. So the default of
> the system made it into the Open Source packages, not so with AIX.

Hmmm, so you are saying that my memory is faulty and shared libs were
not the system norm in 3.x? Not that my memory being faulty would be a
surprise 8-), but I want to be clear on what you are saying.
>
>> You have to do extra work to make static libraries. I suspect you are
>> falling for the historical .so baloney. A library name does not need
>> to end in .so to be a shared library.
>
>
> The name does not really matter.

That is my point. My alleged mind goes back to dealing with support
folks on installation of some product or another, and the support person
was telling me that 'it is not supported on AIX because it doesn't do
shared libs'. This is back in the 3.x days. Of course the product was
clearly supported on AIX, and IIRC shared libraries were the default,
but this support person was confused because the library names didn't
end in .so, and I had to insist on the supervisor being called in to
explain this.

> An simple Example we all know: libz
> When you install the Toolbox, you'll find an archive /usr/lib/libz.a
> This contains the member libz.so.1 which is the real shared lib.
>
> The libz from Bull is build different, The one from UCLA different.
> Each one cannot replace the other without relinking the application.
>
> What does a typical (not all!) source package on AIX? Statically linking .
> Why? Because the build system with the tarball cannot really guess which
> "style" the libs should be build.

Well, -bstatic (IIRC) is available, but if you don't specifically call
it, what does the system default to? If you don't do something
specific, AIX builds shared libs. No?
>
> This lack of a stringent style guide is IMHO a lack of AIX.

?????? I hadn't noticed a particular lack of documentation for AIX over
the years. More typically, if it wasn't the 'Solaris way' (the Windows
of the UNIX world), too many programmers just never bothered to read. 8-(
>
> My personal rule is: when there is a lib from IBM, I want to replace
> with a newer version, I build this lib the IBM Toolbox way.
> So I replaced libz.a with version 1.2.2 and all apps were happy by
> replacing a single file (+ headers for future builds).
>
>> And a look at the toolbox shows that more than one, er, ten, er
>> whatever , packages that are portable to AIX. You will find notes in
>> the major packages for almost exactly umpteen different
>> architectures/OSes.
>
>
> Yes. Investigating the (sometimes small) difference between the original
> source and the corresponding IBM patch shows how little change is
> needed. But it must be an impossible job to tell this all the auto*
> stuff, isn't it?
> Can you point me to the RTFM solution with autoconf?
> I will read and try to understand it.
>

I haven't looked at it much, but will try to get to it.

I was catching up on a book bought years ago, but just got around to
reading (that pretty much says it, doesn't it?). Open Sources. Guy
from Cygnus wrote a chapter which includes a discussion of exactly why
autoconf was built. Specifically to support multiple platforms. They
claimed 100 different target environments at the time of writing - 1999.

So, it may be or seem unwieldy and complicated, but I would ask someone
to point to a different solution that supports 100 (or even 10) target
environments in a cleaner way.

That is not to say whether it is good or bad - as I said, I haven't
looked much at it. I will go out on a limb and say it can be improved -
since there isn't much, if anything, ever built that cannot be. But to
just dismiss something that has been used with some degree of success
for so long just doesn't ring true at first blush.


>> Looking over the last 15 years or so since spending any significant
>> time building gnu stuff on different platforms - for fun, or for
>> developers who request it - my conclusion is that some packages are
>> more friendly for porting than others, and some packages (notably gcc)
>> go thru phases of having problmes on some platforms.
>
>
> Full ACK.
> The KISS principle helps to keep things portable.
> All this auto* stuff claims to make things easier. And it is great if
> things works, all is recognized and configured in a working manner.
> But on AIX this stuff fails much more often than on other platforms.
> If something fails, it is very, very hard to understand where the
> one-little-magic-compiler-flag must be set.
> This stuff is readable as C code with all blanks removed and all
> variables/functions named by 4-digit random hex.
>
>

Well, that is downright harsh. 8-)

>> Ever bothered to go thru bugzilla for your issues?
>
>
> Yes. Found several seems-to-be-the-same-matter bugs reported.

Most of what I see are checked off as 'duplicate non-problems'. Guess
we need to look at specific bugzilla report numbers. And start with
looking at the 'successfull build' sections more closely.

> Later I found a machine with VACPP 5.0 installed and a nodelocked
> license on ebay :-) And for me many problems were solved.

Odd, but the random use of C for AIX (which I though was the C component
of VACPP) hasn't helped in the cases I tried - Python and GCC. Hmmm?
>
> But you didn't anwer to my question what "libtool" is easier with than
> without.
>

Well, I don't even remember that question - I tripped on autoconf.

Timothy J. Bogart schrieb:

>> I know this is true for the system, but before 4.2.1 building shared
>> libs was only possible by calling ld after manually building the list
>> with the symbols to be exported.
>
>
> Hmmm, so you are saying that my memory is faulty and shared libs were
> not the system norm in 3.x? Not that my memory being faulty would be a
> surprise 8-), but I want to be clear on what you are saying.
>

AIX 3 and 4.1.x loader supports shared libs. Many system libs (X11 for
e.g.) are shared libs. The system linker loads and resolves at load time.

The compiler driver flags -brtl and -G were introduced in 4.2.1

Before this it was a rather complicated way to build shared libraries
from the obj by directly calling ld.
If you get OpenSSL and configure it on AIX 4.1.5 the libs are for static
linking only. Same on AIX 4.2.1 and even 4.3.3.


>> An simple Example we all know: libz
>> When you install the Toolbox, you'll find an archive /usr/lib/libz.a
>> This contains the member libz.so.1 which is the real shared lib.
>>
>> The libz from Bull is build different, The one from UCLA different.
>> Each one cannot replace the other without relinking the application.
>>
>> What does a typical (not all!) source package on AIX? Statically
>> linking .
>> Why? Because the build system with the tarball cannot really guess
>> which "style" the libs should be build.
>
>
> Well, -bstatic (IIRC) is available, but if you don't specifically call
> it, what does the system default to? If you don't do something
> specific, AIX builds shared libs. No?
>
>>
>> This lack of a stringent style guide is IMHO a lack of AIX.
>
>
> ?????? I hadn't noticed a particular lack of documentation for AIX over
> the years. More typically, if it wasn't the 'Solaris way' (the Windows
> of the UNIX world), too many programmers just never bothered to read. 8-(
>

Well, the linker and it's features is well documented.


> I was catching up on a book bought years ago, but just got around to
> reading (that pretty much says it, doesn't it?). Open Sources. Guy
> from Cygnus wrote a chapter which includes a discussion of exactly why
> autoconf was built. Specifically to support multiple platforms. They
> claimed 100 different target environments at the time of writing - 1999.
>

In 1999 the complexity has medium to high. In 2005 the complexity is
beyond the universe.

> So, it may be or seem unwieldy and complicated, but I would ask someone
> to point to a different solution that supports 100 (or even 10) target
> environments in a cleaner way.

If the GNU toolchain of m4, automake, autoconf, libtool knows of your
specific configuration and all is configured o.k. it's great. But if
even the smallest errord occurs, the system admin who want's the build a
package from tarball is completely lost.

Ugly, recursively generated, monolithic stuff.

Another example: If you want to optimize the result, you may want to try
different flags.

What's easier? Setting CFLAGS / LDFLAGS in environment or finding the
place and reconfigure the source tree?

"libtool" helps much during the incremental builds of the development.
But it slows down and unnecessarily complicates a fresh clean build.


> That is not to say whether it is good or bad - as I said, I haven't
> looked much at it. I will go out on a limb and say it can be improved -
> since there isn't much, if anything, ever built that cannot be. But to
> just dismiss something that has been used with some degree of success
> for so long just doesn't ring true at first blush.

Perhaps "libtool" isn't that bad and I simply haven't understood it's
intention and usage.
Last year I build the mp3 encoder "lame" for a small benchmark suite.
The older version didn't mention AIX, but was easy to build on AIX. The
freshly "autoconf'ed libtool" not. End of the Show.

My wishes? Breaking down these monoliths into understandable and
more-easy-to-understand-and-fix modules.

It much like the german upper-class cars. When they won't drive because
some little helper refuses it's work. A fault that simply never can
occur on a 15 year old japanese car.
KISS.

--
Uli