Hi Probably this is the wrong forum because it should be placed in a forum like "user-caused problems" bug however, I hope you can help me. I use OpenSuSE 10.1 And now I try to compile Vavoom 1.20 (tar.bz2). While configure I already get:

zico@marvin:/media/data/downloads/vavoom-1.20> ./configure
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking how to run the C preprocessor... gcc -E
checking for ranlib... ranlib
checking for a BSD-compatible install... /usr/bin/install -c
checking for allegro-config... no
checking for sdl-config... /usr/bin/sdl-config
configure: Using SDL
checking for library containing sin... -lm
checking for library containing sin... (cached) -lm
checking for library containing recvfrom... no
configure: error: Library containing recvfrom not found

I searched around in the repos for a package named or containing recvfrom but I haven't found something. Surely it's just a PEBKAC (Problem exists between kexboard and chair).

That's very strange, because on Linux recvfrom is in glibc. Can you attach the config.log file?

Oh of course, sorry I forgot to attach it. Probably you need some version numbers: gcc - 4.1.0 glibc (-devel) - 2.4-31 Probably it just one of a SuSE-special-defaults problem (diffent paths than other distributions or something). I hope this helps for the first time. If you need more things or something you want me to try out to help you finding that bug just let me know.

You don't have SDL_mixer installed. I must add this to documentation and do a proper check for this.

Hm actually I have SDL_mixer insalled but SDL_mixer-devel is currently missing on my systems. But could this be related to the bug with "recvfrom"? <!-- s:? --><img src="{SMILIES_PATH}/icon_confused.gif" alt=":?" title="Confused" /><!-- s:? --> EDIT: Strange - after installing SDL_mixer-devel package the "recvfrom" Error message disappeared and I could compile the game very fine. And it rocks <!-- s:) --><img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /><!-- s:) -->

Of course you need a -devel package to compile against it.

[quote="Janis Legzdinsh":1o5e8u5f]Of course you need a -devel package to compile against it. Yeah I was just wondering why I need SDL_mixer-devel to get rid of the "recvfrom" error. By the way - new problem: After starting a game and the normal gl-nodes stuff I have a very "cool" effect. The player starts about 20 meters OVER the normal level. I can look down, see the level and the enemies shooting at me. This happens on all my WADs so i sugesstest a "bug" in that node builder. So i compiled glVis 1.5 from source and tried to build the nodes again: W_GetNumForName: W_GetNumForName: not found! That reminded me I had such a bug before and you suggested me to use an older version og glBSP, and so I did. Deleted the old GWA and WAD file and started a build again. But the player still starts "over" the level. In every game (except heretic I guess - there i start BELOW the level iirc).

Yeah I was just wondering why I need SDL_mixer-devel to get rid of the "recvfrom" error.

The test failed because linker couldn't to find SDL_mixer library.

By the way - new problem: After starting a game and the normal gl-nodes stuff I have a very "cool" effect. The player starts about 20 meters OVER the normal level. I can look down, see the level and the enemies shooting at me. This happens on all my WADs so i sugesstest a "bug" in that node builder.

It can't be a bug in node builder because it ignores height. And it works fine for me (and nobody else complaied so far). Does the player at least fall down?

No the player does not fall down. I tried to get it working with the shareware version of doom1 so i could try a new WAD but there i start 20 meters below the map (as in heretic). I don't know what's wrong again here with my build. <!-- s:( --><img src="{SMILIES_PATH}/icon_sad.gif" alt=":(" title="Sad" /><!-- s:( --> I believe it's just a bug happening on my system - otherwise someone else would have it, too... but now I'm out of ideas... I tried to use my wads with prboom yesterday and it worked there - and with the test of the shareware wad i'm almost sure my WADs seem to be okay. I tried to cread GLnodes with standalone progs: glbsp 2.10 than ran glvis that came with vavoom1.20 same result. v1.19 ran good but I don't have the source on my harddisc so i would try this version (because I haven't used that version on my current suse 10.1 system and my new 64bit cpu) I'm out of ideas.

Oh, 64-bit, that sounds suspicoius, bit I see that you are compiling as 32-bit so it should be OK. Maybe gcc miscompiles, try to rebuild it configuring like this: CXXFLAGS="-g" ./configure

Wow this WORKS now <!-- s:shock: --><img src="{SMILIES_PATH}/icon_eek.gif" alt=":shock:" title="Shocked" /><!-- s:shock: --> Sorry i didn't tell you earlier about my CPU (i should have known this) <!-- s:oops: --><img src="{SMILIES_PATH}/icon_redface.gif" alt=":oops:" title="Embarassed" /><!-- s:oops: --> Just for interest: I haven't searched the gcc manpage now and I just don't know why it does work with this variable. Could you explain "what" I have done actually? Or if the configure will set this automatically in next versions? I will try some further tests in the next days, trying to compile the game in a 64Bit environment because I'm jut too curious.

Just for interest: I haven't searched the gcc manpage now and I just don't know why it does work with this variable. Could you explain "what" I have done actually? Or if the configure will set this automatically in next versions?

Default value of CXXFLAGS is "-g -O2" that is -g - output debug information -O2 - use level 2 optimisations. Basicly you disable optimisations. I should upgrade my gcc to latest version and see if I'll have the same problem.

I will try some further tests in the next days, trying to compile the game in a 64Bit environment because I'm jut too curious.

It won't work as 64-bit, I'm working on this right now.

Just upgraded to gcc 4.1.1 and got the same problem. But it looks it's just the wrong position/orientation of the player's view (in Doom 2 I was able to pick up the chainsaw). Time for some debugging.

Fixed.