#25 Porting to OS/400

[Patrick Monnerat]

A port of the library to OS/400 would be great.
I started doing it, using an ASCII runtime (on an EBCDIC machine). The library compiles and runs providing you apply the attached patch (against CVS 11 june 2007).

It is quite long, since it maps tabs to spaces, trims right spaces and limits line length to 80 chars.

In addition there are a few files added. All these changes were needed for the OS/400... which is not standard at all.

For the moment, there is no SSL support (SSL on OS/400 is not OpenSSL), and no EBCDIC support. I plan to do it...

This is a work in progress and if it please you (the development team!), a write access to CVS would be of great benefit for it ...

Thanks in advance for a reply !

[Patrick Monnerat]

[Dan Fandrich]

Logged In: YES
user_id=236775
Originator: NO

Are the whitespace and 80 column limit changes strictly necessary for OS/400? Those completely hide within the diff the actual changes necessary for OS/400 support. The 80 column limit especially can really reduce the readability of the code on all platforms. If the OS/400 compiler is so truly broken as to not accept the code otherwise, then those changes could be done in a preprocessing phase using indent(1) and expand(1).

For the libcurl-os400.bndsrc file, isn't there some way to generate it at compile time? I'm assuming it's just a list of libcurl exports that are already marked with CURL_EXTERN in the source. Similarly, the file Makefile.inc ought to be used instead of hard-coding the source files into makefile-os400.sh. Both these changes will future-proof the OS/400 build mechanism from future libcurl changes. It's too bad the autotools won't work (I assume).

[Daniel Stenberg]

Logged In: YES
user_id=1110
Originator: NO

I second the objection to all the unnecessary white spaces changes.

Further, why are so many Curl_* functions mentioned in the libcurl-os400.bndsrc file? The ones with uppercase C are library internal only.

Also, I suggest you subscribe to the curl-library list and continue this effort there. Post patches and discuss approach with the lot there, as it offers a better way for discussions within the entire libcurl community.

[Patrick Monnerat]

Logged In: YES
user_id=322655
Originator: YES

OS/400 has a kind of shell clone, but no real unix-like environment. I.e.: cc, gcc, ld, autotools, indent and expand commands do not exist.
This OS is almost completely built on a database: modules (object files) and executable programs may only reside in database libraries. Even the sources are located in DB files. This explains the 80 col. limit.
Recently IBM added the ability to compile sources from the hierarchical (unix-like) file system (seldom used in the AS/400 world), allowing to overcome this limit. I will try this...
The object and program files MUST be in the DB (no way to store them in the unix-like file system); DB naming scheme reduces the allowed character set and length (upper alpha num + few punct and max 10 chars); this is the reason why I listed the source files and changed object file names in my script. I may try using Makefile.inc, providing it stays compatible with a shell script and all source names differs in the 1st 10 characters.
The libcurl-os400.bndsrc is needed by the ".so linker" (called CRTSRVPGM !) to get the building directives and export list. I generated it automatically from the object files at a time other object files (libtest modules) were not in the object library. I can try to generate it dynamically in the build script from the libcurl.def or libcurl.imp file.

Thanks for your hints !
I'll continue OS/400 discussion and proposals on the libcurl-library list.

Patrick

[Daniel Stenberg]

Logged In: YES
user_id=1110
Originator: NO

OS/400 support is now in CVS