EQEmulator Forums - Linux Compile Broken on 0.5.0DR3

EQEmulator Forums (https://www.eqemulator.org/forums/index.php)

- Archive::Development (https://www.eqemulator.org/forums/forumdisplay.php?f=621)

- - Linux Compile Broken on 0.5.0DR3 (https://www.eqemulator.org/forums/showthread.php?t=9481)

Linux Compile Broken on 0.5.0DR3

Looks like line [client_process.cpp:4333] is not using the new item classes properly. It's passing int16 failedproduct into PutItemInInventory when an ItemInst object is expected. This causes the compile to fail when using gcc 3.2.

I suspect this was just one conversion to the new item structs that slipped through the cracks.

I changed from this:

Code:

else{

  this->Message(4,"You lacked the skills to fashion the items together.");

  if (failproduct!=0)                               

    PutItemInInventory(30,failproduct,1);                        

}

to this:

Code:

else{

  this->Message(4,"You lacked the skills to fashion the items together.");

  if (failproduct!=0) {

    const Item_Struct* myitem = database.GetItem(failproduct);         

    ItemCommonInst common(myitem, 0);                                  

    PutItemInInventory(30,(ItemInst&)common,1);                        

  }

}

I'm not sure if going to the database is appropriate here, so if there's a better solution, post away!

regards,

krich

That is strange. vs.net happily compiles that bit of code. It's not a case of being #ifdef'd out, either.

The code you put in is correct, and has been checked into our internal source code repository. Thanks for catching that.

There are some other bits of code around this bit that will need changing as well - but I can't change it at the moment because I can't test it:

Item ID is now a uint32, and an int16 runs the risk of overflow these days. Even a uint16 won't cut it. If you catch any spots in code using int16 for item id, please let us know!

It works on linux on irc chat I forget his name got to work.

Krich already posted the solution... If interested, please re-read his post.

I pushed a new CVS update out last night, should correct this issue. I also removed a couple of warnings that newer gcc's complain about.

Only problem I'm having now is with the crc32 asm code I modified for linux, the newer glibc/nasm is not compiling it properly, and I really hate to have to rewrite that function again!!! Probably only affects me as I'm using bleeding edge gentoo builds (~x86 unstable versions)

crc32.cpp probs on linux

heya trumpcard.. do you get something like this:

gcc -c -Wall -Wuninitialized -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wcomment -Wcast-align -Winline -Wno-deprecated -g -march=i686 -O -pthread -pipe -DFX -D_GNU_SOURCE -DINVERSEXY -DWORLD -DDEBUG=5 -DSHAREMEM -DCATCH_CRASH -DNO_PIDLOG -I/usr/include/mysql -I/usr/mysql/include ../common/crc32.cpp -o ../common/crc32.o
../common/crc32.cpp:105:2: warning: #warning "Comment out i386 define if your arch isn't x86"
../common/crc32.cpp: In static member function `static uint32 CRC32::Update(const int8*, unsigned int, unsigned int)':
../common/crc32.cpp:167: error: asm-specifier for variable `__crc32' conflicts with asm clobber list
make: *** [../common/crc32.o] Error 1

that's from CVS about 5 mins ago...

lol no clue wot to do about it though :P

oops...

Mandrake 9.2 RC1 is wots on the beast... i guess that's pretty recent... mmm...

Gcc specs:
Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.3.1/specs
Configured with: ../configure --prefix=/usr --libdir=/usr/lib --with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --enable-long-long --enable-__cxa_atexit --enable-languages=c,c++,ada,f77,objc,java,pascal --host=i586-mandrake-linux-gnu --with-system-zlib
Thread model: posix
gcc version 3.3.1 (Mandrake Linux 9.2 3.3.1-1mdk)

ldconfig -v | grep 'glib' :
libglib-2.0.so.0 -> libglib-2.0.so.0.200.2
libglib-1.2.so.0 -> libglib-1.2.so.0.0.10

working dev environment though, cuz i've had to recompile a helluvalot of junk :P *mumble*apache/php/mysql/etc..*mumble*

anyways...

watchin this with interest

><'>

got bored so am gettin the latest snapshot from glibc.. maybe the prob been fixed...

la la la

Yep, probably the new gcc is what I'm guessing (3.3.1)

Easiest way around this for the timebeing is to change comment out the define(i386) in common/crc32.cpp. (might have to change the elif(i386) to something like elif(i986) just to make sure it tries to use the old way of generating crc...

k...

i've updated gcc/glib/libstdc++ from the cooker rep...

gonna give it another try :)

i'll change the #elif(i386) to jump over that bit if it bangs again

:)