Unix Programming - libmba port to Solaris

Author

libmba port to Solaris

Heny Townsend

2005-02-20, 6:19 pm

[I posted this to the libmba mailing list first but it doesn't seem to
have appeared there for reasons involving (of course) spam. Posting here
because it may be of general interest and I know the author reads here.]

Has anyone ever ported libmba (http://www.ioplex.com/~miallen/libmba/)
to Solaris? I just tried to build it on Sol9 and things did not go
smoothly. This is strange because its companion library DOMC requires
libmba (which is why I'm building it - I need DOMC) and that web page
says "It is known to compile on Linux, Solaris, and Windows."

I've got a few diffs (attached) which allow it to build but which are
not pretty.

First, hashmap.c needs an explicit include of <wchar.h>. Also, the
redefine of _A() and _R() to two completely different macros is pretty
awful IMHO. I just suppressed the warning but the local ones in
hashmap.c should really be renamed.

Second, the use of uint32 fails on Solaris because of the -ansi flag to
gcc. Comments in <inttypes.h> imply that these types haven't been
accepted by ANSI so Solaris doesn't define them when -ansi is on. I
removed -ansi to fix this.

Third, I also had to add -D__USE_GNU to CFLAGS.

Fourth, I had lots of trouble with shellout.c. It looks pretty
Linux-centric. I'm sure it could be ported but I don't need that feature
so I just removed it from the Makefile.

Fifth, there's no builtin -lutil on Solaris. I removed it and everything
linked fine.

Did I do something wrong? I'm not too comfortable with this hacked version.

--
Henry Townsend

James Antill

2005-02-20, 6:20 pm

On Fri, 18 Feb 2005 10:02:20 -0500, Heny Townsend wrote:

> [I posted this to the libmba mailing list first but it doesn't seem to
> have appeared there for reasons involving (of course) spam. Posting here
> because it may be of general interest and I know the author reads here.]

You'd probably have been better off posting directly to the author.

> I've got a few diffs (attached) which allow it to build but which are
> not pretty.

The diffs are backwards.

> First, hashmap.c needs an explicit include of <wchar.h>. Also, the
> redefine of _A() and _R() to two completely different macros is pretty
> awful IMHO. I just suppressed the warning but the local ones in
> hashmap.c should really be renamed.

Indeed.

> Second, the use of uint32 fails on Solaris because of the -ansi flag to
> gcc. Comments in <inttypes.h> imply that these types haven't been
> accepted by ANSI so Solaris doesn't define them when -ansi is on. I
> removed -ansi to fix this.

You mean uint32_t ? ... that is now part of ISO 9899:1999, your compiler
is out of date.

> Third, I also had to add -D__USE_GNU to CFLAGS.

Never add this, this is an internal symbol on Linux ... the correct
define on Linux is -D_GNU_SOURCE=1

--
James Antill -- james@and.org
Need an efficient and powerful string library for C?
http://www.and.org/vstr/

Heny Townsend

2005-02-20, 6:20 pm

James Antill wrote:
> You'd probably have been better off posting directly to the author.

I didn't see an address for the author. Do you know one?

>
>
> You mean uint32_t ? ... that is now part of ISO 9899:1999, your compiler
> is out of date.

Actually, I meant uint64_t, sorry. And my compiler is gcc 3.4.1. Check
it out:

% cat intt.c
#include <inttypes.h>
static uint64_t xyz;

% gcc -c -ansi intt.c
intt.c:2: error: parse error before "xyz"
intt.c:2: warning: data definition has no type or storage class
%

% gcc -c intt.c
%

% gcc --version
sparc-sun-solaris2.9-gcc (GCC) 3.4.1

--
Henry Townsend

Michael B Allen

2005-02-20, 6:20 pm

On Fri, 18 Feb 2005 10:02:20 -0500, Heny Townsend wrote:

> [I posted this to the libmba mailing list first but it doesn't seem to
> have appeared there for reasons involving (of course) spam. Posting here
> because it may be of general interest and I know the author reads here.]

Only members can post to the list because of spam. I'll reply to this
now but in the future just email me directly. This is OT for cup.

> Has anyone ever ported libmba (http://www.ioplex.com/~miallen/libmba/)
> to Solaris? I just tried to build it on Sol9 and things did not go
> smoothly. This is strange because its companion library DOMC requires
> libmba (which is why I'm building it - I need DOMC) and that web page
> says "It is known to compile on Linux, Solaris, and Windows."

DOMC is getting a little old now whereas libmba has moved on. I used
to check all my packages on a variety of platforms but I've slacked off
some since.

Most of the problems you're having are pretty simple I think. Everything
should build on Solaris without *too* much trouble (including shellout -
terminal stuff can be a little fickle about the platform).

> Did I do something wrong? I'm not too comfortable with this hacked
> version.

I can't be sure but I think your ok because DOMC only uses hashmap,
stack, and msgno. So if something that you don't need isn't compiling
(e.g. shellout) just search and destroy that module's name from the
Makefile (i.e. remove src/shellout.o from OBJS and src/mba/shellout.h
from HDRS).

I don't have access to a Solaris machine with dev tools on and I'm
not the langauge lawyer type so it's a little difficult for me to keep
everything building cleanly.

Good luck,
Mike

Ian Zimmerman

2005-02-20, 6:20 pm

Heny> Actually, I meant uint64_t, sorry. And my compiler is gcc
Heny> 3.4.1. Check it out:

Heny> % cat intt.c #include <inttypes.h> static uint64_t xyz;

Heny> % gcc -c -ansi intt.c intt.c:2: error: parse error before "xyz"
Heny> intt.c:2: warning: data definition has no type or storage class %

Heny> % gcc -c intt.c %

Heny> % gcc --version sparc-sun-solaris2.9-gcc (GCC) 3.4.1

Use gcc -std=c99

--
I wonder which is the best virus for unix and if I can write
a better one in Microsoft BASIC ?
Hans-Marc Olsen in comp.unix.programmer

Heny Townsend

2005-02-20, 6:20 pm

Ian Zimmerman wrote:

> Heny> Actually, I meant uint64_t, sorry. And my compiler is gcc
> Heny> 3.4.1. Check it out:
>
> Heny> % cat intt.c #include <inttypes.h> static uint64_t xyz;
>
> Heny> % gcc -c -ansi intt.c intt.c:2: error: parse error before "xyz"
> Heny> intt.c:2: warning: data definition has no type or storage class %
>
> Heny> % gcc -c intt.c %
>
> Heny> % gcc --version sparc-sun-solaris2.9-gcc (GCC) 3.4.1
>
> Use gcc -std=c99

% gcc -c -std=c99 intt.c
intt.c:2: error: parse error before "xyz"
intt.c:2: warning: type defaults to `int' in declaration of `xyz'
intt.c:2: warning: data definition has no type or storage class
%

Also, just for the record (and I agree this was probably not the right
forum, for which I apologize) it's not a matter of *me* using -ansi or
-std=c99. I'm trying to build someone else's SW which has -ansi embedded.

--
Henry Townsend

Michael B Allen

2005-02-20, 6:20 pm

On Sat, 19 Feb 2005 07:58:27 -0500, Heny Townsend wrote:
> Ian Zimmerman wrote:
>
> % gcc -c -std=c99 intt.c
> intt.c:2: error: parse error before "xyz" intt.c:2: warning: type
> defaults to `int' in declaration of `xyz' intt.c:2: warning: data
> definition has no type or storage class %

And did you change <inttypes.h> to <stdint.h>? An implementation isn't
required to define every uintN_t type but I would be shocked if this
didn't really work with your machine and compiler. Hell, sparc is a 64
bit machine.

> Also, just for the record (and I agree this was probably not the right
> forum, for which I apologize) it's not a matter of *me* using -ansi or
> -std=c99. I'm trying to build someone else's SW which has -ansi
> embedded.

Well I think Ian was just trying to demonstrate how you can build with
C99 behavior. Libmba should not require C99. Not properly importing types
is just a mistake on my part. The proper fix is probably something like:

#if defined(__sparc__) && !defined(__USE_ISOC99)
#include <inttypes.h>
#elif defined(_WIN32)
#define MILLISECONDS_BETWEEN_1970_AND_1601 11644473600000Ui64
typedef unsigned __int64 uint64_t;
#else
#include <stdint.h>
#endif

But I haven't tested this and I would have to look at the sparc-sun C
library headers to determine that it's truely the correct way to go.

Mike

Heny Townsend

2005-02-20, 6:20 pm

Michael B Allen wrote:
> And did you change <inttypes.h> to <stdint.h>? An implementation isn't
> required to define every uintN_t type but I would be shocked if this
> didn't really work with your machine and compiler. Hell, sparc is a 64
> bit machine.

There is no <stdint.h> on Solaris. It does define uint64_t, of course,
just not in the -ansi or -std=c99 scenarios. Here's the relevant code
from <sys/int_types.h> (which is available via "#include <sys/types.h>"
or "#include <inttypes.h>"):

typedef unsigned char uint8_t;
typedef unsigned short uint16_t;
typedef unsigned int uint32_t;

#ifdef _LP64
typedef unsigned long uint64_t;
#else /* _ILP32 */
#if __STDC__ - 0 == 0 && !defined(_NO_LONGLONG)
typedef unsigned long long uint64_t;
#endif
#endif

So uint64_t is available to 64-bit code under all conditions, and to
32-bit code when (__STDC__ - 0 == 0).

> #if defined(__sparc__) && !defined(__USE_ISOC99)
> #include <inttypes.h>
> #elif defined(_WIN32)
> #define MILLISECONDS_BETWEEN_1970_AND_1601 11644473600000Ui64
> typedef unsigned __int64 uint64_t;
> #else
> #include <stdint.h>
> #endif

Actually, one of the porting points I'd make is that __sparc__ should be
replaced with __sun__ or similar. Seems much more likely to work on
Solaris X86.

--
Henry Townsend

Bjorn Reese

2005-02-20, 6:20 pm

Heny Townsend wrote:

> Actually, one of the porting points I'd make is that __sparc__ should be
> replaced with __sun__ or similar. Seems much more likely to work on
> Solaris X86.

It is better to start with the standards, then the compilers, and
then the platforms. Each of these may require som compiler or platform
specific workarounds.

For example:

#if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L)
# include <stdint.h> /* C99 */
#elif defined(_XOPEN_SOURCE) && (_XOPEN_VERSION >= 500)
# include <inttypes.h> /* UNIX98 */
#else
/* Do the compiler and platforms specific stuff */
#endif

--
mail1dotstofanetdotdk

Michael B Allen

2005-02-21, 2:48 am

On Sun, 20 Feb 2005 09:49:56 -0500, Bjorn Reese wrote:

> Heny Townsend wrote:
>
>
> It is better to start with the standards, then the compilers, and then
> the platforms. Each of these may require som compiler or platform
> specific workarounds.
>
> For example:
>
> #if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L)
> # include <stdint.h> /* C99 */
> #elif defined(_XOPEN_SOURCE) && (_XOPEN_VERSION >= 500)
> # include <inttypes.h> /* UNIX98 */
> #else
> /* Do the compiler and platforms specific stuff */ #endif
>

Yup. I looked at your website for this. Unfortunately I don't know enough
about the standards to know what definition / feature was introduced with
whatever standard. And I really don't like autoconf so I guess I'm stuck
(unless you instruct me like you did in this case :-).

Thanks,
Mike