Re: Tn5250 compile under IBM Aix 5.3

On Fri, 14 May 2010, Scott Klement wrote:

My changes aren't exactly huge, so it probably doesn't matter which
method we use. I figured people would rather keep the structure
intact.

Seems to me, the problem is that we used pointers in our structure that
were the same name as the system APIs (accept and connect). When the
macro runs, it renames accept to naccept and connect to nconnect, and
then our code doesn't work anymore.

How else would you fix that? If you disable the macro, then it's
calling the wrong system API, right? Otherwise, you'd have to be
careful to have it enabled in some places and disabled in other
places... which seems a lot more complicated than renaming the pointers.

As I said, I'm fine with just changing the structure. At least I got some more experience with autoconf which may come in handy later. Let's just revert my changes and commit what you've done.

conf.c: In function 'tn5250_config_replacedata':
conf.c:716: warning: incompatible implicit declaration of built-in
function 'snprintf'

Hmm... I didn't get any snprintf, strncpy, strlen, strcpy or vsyslog
errors.

I discovered that these errors are because on my iSeries stdio.h has to have _XOPEN_SOURCE defined to a value 500 or higher in order to define snprintf. I added "#define _XOPEN_SOURCE 500" to config.h which fixes the snprintf issues, but opens a whole 'nother can of worms:

sslstream.c: In function 'ssl_stream_connect':
sslstream.c:590: error: 'u_long' undeclared (first use in this function)
sslstream.c:590: error: (Each undeclared identifier is reported only once
sslstream.c:590: error: for each function it appears in.)
sslstream.c:590: error: parse error before 'ioctlarg'
sslstream.c:611: error: parse error before ')' token
sslstream.c:622: error: 'u_short' undeclared (first use in this function)
sslstream.c:622: error: parse error before 'atoi'
sslstream.c:721: error: 'ioctlarg' undeclared (first use in this function)
sslstream.c: In function 'ssl_stream_accept':
sslstream.c:748: error: 'u_long' undeclared (first use in this function)
sslstream.c:748: error: parse error before 'ioctlarg'
sslstream.c: In function 'ssl_stream_host_sb':
sslstream.c:1153: warning: pointer targets in passing argument 2 of 'tn5250_buffer_append_data' differ in signedness
make: The error code from the last command is 1.

So far, compiling this on my iSeries isn't turning out too easy :(

This appears to be caused by the fact that the AIX malloc() function is
not 100% compliant with the GNU malloc function. So autoconf creates
that macro to rename malloc to rpl_malloc with the anticipation that we
(the tn5250 project) will provide a function called rpl_malloc() that
replaces malloc() to make it GNU compatible.

As far as I can tell, the only difference between the GNU malloc() and
the AIX one is what happens when you try to call it as malloc(0). And
tn5250 never does that -- so the difference doesn't matter to us.

So I just commented out that macro in config.h.

Right, autoconf knows that the implementations of malloc() differ and so renames malloc to rpl_malloc. IMO the best thing to do is to write a simple rpl_malloc.c that uses malloc() the AIX way. As you mention, it would be just like that way we currently use malloc(), but I think it is the "right" way from an autoconf point of view. I started something similar for x5250 years ago that I can dust off for this purpose.

But at this point, I _do_ have tn5250 running successfully in PASE.
Well... sort of, anyway. It doesn't seem to accept any keyboard input,
and I don't know why. But it doesn't give me errors, and it displays
the sign-on screen without problems.

I'm jealous, you're doing better than I am!

I'm running GCC 4.1.1 compiled for AIX 5.2. I don't remember exactly
where I got it, I've had it on i for years and years.. I probably
originally got it from UCLA's AIXPDSLIB.

That indicates to me that the different gcc versions and possibly AIX version (I don't know how to check that) are the causes of the different compile results. I guess we could tell people to only use a specific version of gcc/AIX but that doesn't seem like a good solution. Some autoconf-fu sounds like the only path.

James Rich

if you want to understand why that is, there are many good books on
the design of operating systems. please pass them along to redmond
when you're done reading them :)
- Paul Davis on ardour-dev