|
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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
