Re: [AD] Irix & allegro-3.9.40

[Stepan Roh <stepan@xxxxxxxxxx>]

On Tue, 20 Nov 2001, Hein Zelle wrote:

> ---1---
>
> In file included from include/allegro/fmaths.h:38,
>                  from include/allegro.h:61,
>                  from ./src/allegro.c:23:
> include/allegro/inline/fmaths.inl:123: conflicting types for `floorf'
> /usr/include/math.h:333: previous declaration of `floorf'
>
> This is one I've seen before: Stephan Roh made a patch for Irix
> math.h, in include/allegro/platform/alucfg.h .
>
> I solved it by adding '#undef ffloor' to the list of Irix macro's that
> are undefined. Very strange: apparently the Irix compiler mangles
> ffloor and floorf. If I #undef'ed floorf, the problem remained.

Well, that's defined by some ugly magic (I saw it) in Irix system headers.
Some kind of backward compatibility issue. Not very nice, I think.

> attached: alucfg.diff
>
> ---2---
>
> param.h (included from pthread.h) defines MIN and MAX for Irix, and
> conflicts with include/allegro/base.h as follows:
>
> /usr/include/sys/param.h:370: warning: `MIN' redefined
> include/allegro/base.h:58: warning: this is the location of the
> /usr/include/sys/param.h:371: warning: `MAX' redefined
> include/allegro/base.h:59: warning: this is the location of the
>
> Since it's only a warning and there are only so many ways to define
> MAX and MIN, I've left it like this. It could probably be solved by
> including pthread before allegro.h, but in usystem.c this is not so
> trivial. Could also be solved by including <pthreads.h> in base.h for
> Irix only.

I was getting the same warning and as those macros are virtually the same,
I just left it without modification.

> ---3---
>
> old (3.9.39 had it too):
>
> some of the test programs (akaitest and afinfo, in any case) use pow,
> and cause an unresolved external when linking. (missing math library)
>
> I solved this by adding -lm to LINK_LIBALLEG in the makefile. I am not
> certain if this is the right way to solve it, but if it is, attached is
> a patch where \$(LIBS) is added to LINK_LIBALLEG for the shared library
> build. The static build already had this. \$(LIBS) contains more than
> just -lm (in my case) so perhaps it's better to just add -lm in
> configure.in, I'm not sure. It may also be possible to let configure
> detect it but I don't know how.

I think your current solution is correct.

> attached: configure.in.diff
> ---4---
>
> old (3.9.39 had it too):
>
> ld32: WARNING 1: Unknown option: export-dynamic (ignored).
> ld32: WARNING 84: /usr/lib32/libdl.so is not used for resolving any
> symbol.
>
> It seems this is still in. I discussed and testet it with Peter Wang:
> it seems the Irix linker doesn't handel the exporting of symbols for
> the modules. (At least, we couldn't find how. Stephan Roh, do you
> perhaps know how to fix this? Do you get this warning as well?)

Last version I tried on Irix was without modules support, so I was not
getting this error.

> Peter, you said we should just disable modules, right? Should I
> write a patch for the Irix documentation that configure should be run
> with , or should this be fixed in
> configure or makefile for Irix?

I think there must be some way how to do it (we can look into the
libtool), but unless we find a way, it could be disabled by default for
Irix. But I think that small notice in readme.uni (or how this file is
named now after those big restructualizings - hey! it's not Alllegro any
more :-) ) will be sufficient for now.

> ---5---
>
> on Irix machine:
>
> make clean -> command line too long.
>
> This is strange, because I use rm (GNU fileutils) 4.0, so I didn't
> expect it. Using linux it does work.

It could be generated by system, shell or make. I think it's system's
fault, but who knows. What are you using (Irix version, shell version,
make version)?

> I 'fixed' this by splitting up CLEAN_FILES (makefile.lst) into two
> parts (OBJ_CLEAN_FILES and OTHER_CLEAN_FILES) and removing those
> separately (makefile.in). Since the other make *clean targets are all
> depending on make clean, this should cause no further problems.

It won't hurt anyone/thing, so why not to apply it.

I read your patches and they all seem good to me.

I'm planning to do series of tests with Allegro on
Linux/Solaris/Irix/Irix64 this or next week. Let's see what broke since my
last tests.

Have a nice day.

Stepan Roh