Source compile on Solaris

[kryptman]

Hi!

Here's my setup. Solaris 8, Ultra 10, Elite3d m3, 384Mb RAM, gcc 3.4.0, SDL v. 1.2.7.

I've compiled Exult on Solaris before, without any problems. Recently, I was forced to rebuilt my system. Having installed the same packages as before I've been trying to install exult-1.2, which, as I've said, I've done before without problems so I know it works.

Everything compiles ok up to this point:

g++ -O2 -Wno-long-long -g -O2 -o exult actions.o actorio.o actors.o alloc.o args.o bggame.o browser.o cheat.o cheat_screen.o combat.o delobjs.o devgame.o dir.o drag.o effects.o exult.o exultmenu.o game.o gameclk.o gamedat.o gamemap.o gamerend.o gamewin.o keys.o keyactions.o menulist.o monsters.o mouse.o npcnear.o npctime.o palette.o party.o paths.o readnpcs.o schedule.o segfile.o shapeid.o sigame.o tqueue.o txtscroll.o version.o xdrag.o pathfinder/.libs/libpathfinder.a audio/.libs/libaudio.a audio/midi_drivers/.libs/libmididrv.a flic/.libs/libflic.a conf/.libs/libconf.a imagewin/.libs/libimagewin.a server/.libs/libserver.a usecode/.libs/libusecode.a shapes/.libs/libshapes.a objs/.libs/libobjs.a gumps/.libs/libgumps.a files/.libs/libu7file.a files/zip/.libs/libminizip.a -L/opt/csw/lib /opt/csw/lib/libSDL.so -lm -ldl -L/usr/openwin/lib -lXext /opt/csw/lib/libSDL_mixer.so -lvorbisfile -lvorbis -logg -lSDL -lpthread -lposix4 -lsocket -lX11 -lz -lGL -R/opt/csw/lib -R/opt/csw/lib -R/usr/openwin/lib

Here it suddenly craps out with this error message:
Undefined first referenced
symbol in file
powf audio/.libs/libaudio.a(xmidi.o)

I know that this is a math function, but I can't figure out why the compile stopped working here. Please help!

Thanks

Albert

[drcode]

I don't see that function, 'powf', used in any of our source files in the audio directory, but I do see 'pow'. Have you tried doing a 'man pow' or 'man powf' to see if it's on your system, and what library it's in?

[kryptman]

pow is in the math.h library, just where is should be. I grepped math.h just to make sure it's there. I've also read that libm.so is important, so I made sure that's present and in my path, and that's all there too.

I've also found powf, which is in a file called cmath. All the stuff is present, and all the paths are there.

[kryptman]

Okay, so I managed to get the compile to work with gcc2.95. I suspect that this is an issue with the builtin compiler functions. These math functions are part of the C99 Spec and aren't included in default Solaris 8, at least i didn't found a system patch for it. This isn't just a problem when compiling exult. I found the same issue in the wine mailing list with the below fix.

I will change to gcc3.4.0 again and try to add the following to the source file:

static inline float powf (float x, float y) { return pow (x,y); }

Only problem is that I don't know which source file to edit. Can someone more familiar with the exult compile tell me which file is responsible for the error?

Thanks,

Albert

[wjp]

As Jeff mentioned earlier, we don't use powf anywhere in Exult itself. We do use 'pow' on floats in at least headers/gamma.h, so maybe that's somehow converted to powf internally? (some macro maybe?)

Or maybe a system/library header file we include somewhere is using it. The linker error points at xmidi.o, so maybe you could see if the preprocessed version of xmidi.cc uses powf somewhere.

[drcode]

Adding to WJP's advice: Don't declare 'powf' to be static inline, but you might have to make it 'extern "c"' so the linker will find it. Then it won't matter which file you put it in.

But switching to a more recent version of gcc might make the problem go away.

[kryptman]

>> 'extern "c"' so the linker will find it

How do I do that?

Anyways, I think I found the problem in the cmath library. It seems that cmath is set up to turn a pow() call to a powf() call. Here's the sample out of the cmath library:

using ::pow;

inline float
pow(float __x, float __y)
{ return __builtin_powf(__x, __y); }

This says to me that if the pow function is passed a float variable, it calls powf.

I did use the static inline bit in xmidi.cc, then it threw up on imagewin, so I doctored up imagewin.cc too. Now it stops at the same point, giving the following:

Undefined first referenced
symbol in file

Interesting, because there's no symbol and no file listed. I suspect this is a problem with the gcc implementation running on my system. I will download a different package and try it with a different compiler. As I've said before, it does work with 2.95, but not with 3.4.0. I know your code works, so it cannot be a problem with exult itself. I have done the compile on Linux and Solaris before without issue.

BTW, I hope I'm not being impertinent. If you like, I will add all of my experience together and you can add it to the FAQ as a Solaris compile option, as a thank you for your help.

[zos/X]

That's pretty weird that it works in 2.9.5 and not 3.4.0. For the record I've successfully compiled in Linux a few times under some flavor of 3. Well let me double check:

zos@thanatos:~$ gcc --version
gcc (GCC) 3.3.4 (Debian 1:3.3.4-13)

Since you are a Solaris guy and I'm definately not, I have no idea of how your GNU toolkit is set up. Since you can understand the errors the compiler is tossing off, you probably know more about C++ than me.

I could try compiling for Solaris under Linux but I don't really think that is the most elegant, or even a workable solution. Yeah, its weird. Usually, when I find that GCC can't resolve symbols it is almost always a library issue, at least when the code is known to actually compile. Maybe it would compile for you under the 3.3.x series, especially if you rolled your own, as the function you are having problems with seems to be a standard GCC library.

Isn't GCC 3.4 the newest series out right now? It might break some things, but I honestly don't know. The configure script worked perfectly? Is your GCC built properly and has produced working code before?

Here is your error message:
----------------
symbol in file
powf audio/.libs/libaudio.a(xmidi.o)
----------------
I'll run ./configure now, and look at the makefile for audio.

It doesn't find timidity (no big deal for now), but it does find SDL. Going good. So the makefile wants to build libaudio.a with all the sources in the directory. Going into the audio diretory and running make will just produce whatever files the Makefile defines, create a ./lib directory and put the completed output there.

My best guess is that your GCC setup is somehow broken, or somehow works differently than say the linux GCC, which it really shouldn't. Some guy aparantly had Exult running on Solaris before as well, but I don't know what he did to get it to run. Do you have any compilers other than GCC?

As to the pow to powf call, it is probably inheritence. pow is probably just a powf call internally to the compiler. Can you compile code that makes a pow call or a powf call? If you can't then you are probably missing libraries or something isn't set up right or the makefile in exult is breaking or something. Try make clean and what not.

zos/X

[kryptman]

I've use pow before, as I've done some playing around with numerical integration and trying to benchmark my systems with it, so I know that works. The powf function doesn't work, so again, I'm suspecting this package. I've tried two different package versions, and they both cause the same problem. 3.4.2 is the newest version available to me. I will try to install 3.3.2 tonight and see what happens. If I switch compilers I usually blow away the whole tree and untar it from the archive again. This way I start with a clean source tree. The configure script worked fine, with no problems. As I've said before, powf is part of the c99 spec, which isn't fully implented in Solaris 8. Maybe the person who built the gcc package didn't do it properly. I don't know. I do not think myself capable of compiling gcc myself yet. I suspect it's a problematic as compiling glibc and I've had a hard time doing that when I had RedHat 6 installed on my Ultra 5. Actually, I gave up and reinstalled Solaris.

I'll try again with gcc 3.3.2 and see what's up.

Thanks,

Albert

[zos/X]

Yeah, it seems like something is really broken in your implementation with GCC. Broken libraries or whatnot.

I wish you the best of luck!!!!

zos/X