aMule Forum
English => Compilation problems => Topic started by: IhmSelbst on January 20, 2006, 08:04:12 AM
-
according to expectations after Kry´s posting http://forum.amule.org/thread.php?threadid=8893, there are some problems with today´s cvs now. - it doesnt´t compile on SuSE9.3, neither without, nor with debug enabled, whereas, on SuSE10.0 and 10.1alpha4, it did. (compiling cvs from yesterday and the day before worked on suse9.3, too.)
it´s last words, before it died on the 9.3-box were:
...
SafeFile.h:204:2: Warnung: #warning DOCS
In Datei, eingefügt von kademlia/kademlia/Search.h:45,
von PartFile.cpp:74:
kademlia/io/ByteIO.h:48:2: Warnung: #warning Marked for deletion
PartFile.cpp:334:18: Warnung: #warning Code for full file alloc - should be done on thread.
PartFile.cpp:478:50: Warnung: #warning Kry - UPDATE
PartFile.cpp:483:50: Warnung: #warning Kry - UPDATE
PartFile.cpp:488:50: Warnung: #warning needs setfiletype string
PartFile.cpp:610:58: Warnung: #warning Kry - UPDATE
PartFile.cpp:869:18: Warnung: #warning Kry - UPDATE
PartFile.cpp:871:18: Warnung: #warning Kry - UPDATE
PartFile.cpp:944:26: Warnung: #warning UPGRADE!
PartFile.cpp: In member function `bool CPartFile::SavePartFile(bool)':
PartFile.cpp:945: error: Syntaxfehler before `,' token
PartFile.cpp:950: error: Syntaxfehler before `,' token
PartFile.cpp:2962:2: Warnung: #warning Kry - serious review. I did some, and seems to be ok, but...
make[3]: *** [amuled-PartFile.o] Fehler 1
make[3]: *** Warte auf noch nicht beendete Prozesse...
make[3]: Leaving directory `/usr/src/packages/BUILD/amule-cvs/src'
make[2]: *** [all-recursive] Fehler 1
make[2]: Leaving directory `/usr/src/packages/BUILD/amule-cvs/src'
make[1]: *** [all-recursive] Fehler 1
make[1]: Leaving directory `/usr/src/packages/BUILD/amule-cvs'
make: *** [all] Fehler 2
error: Bad exit status from /var/tmp/rpm-tmp.66189 (%build)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.66189 (%build)
cu
-
Same on Debian Sarge with today's (20060121) snapshot.
-
It does compile and run on Ubuntu Breezy. Seems to be a problem with 'older' distributions.
-
The problem is I see no problem on the code and it works here.
-
old gcc probably...
works here on gentoo, gcc-3.4.5 and 4.0.2
-
No trouble on Mandriva 2006.0
gcc --version
gcc (GCC) 4.0.1 (4.0.1-5mdk for Mandriva Linux release 2006.0)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
As said :D
-
Originally posted by stefanero
old gcc probably...
works here on gentoo, gcc-3.4.5 and 4.0.2
On Debian Sarge I have gcc 3.3.5 as standard compiler :(
-
Originally posted by Radek
On Debian Sarge I have gcc 3.3.5 as standard compiler :(
also here on the suse9.3-box 8o ;( :( :
gcc --version
gcc (GCC) 3.3.5 20050117 (prerelease) (SUSE Linux)
Copyright © 2003 Free Software Foundation, Inc.
Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es
gibt KEINE Garantie; auch nicht für VERKAUFBARKEIT oder FÜR SPEZIELLE ZWECKE.
cu
-
I had a little time right now and fooled around with PartFile.cpp. This was, what I did
--- src/PartFile.cpp
+++ src/PartFile.cpp
@@ -938,12 +938,14 @@
snprintf(number,9,"%hu",(unsigned short int)i_pos);
namebuffer[0] = FT_GAPSTART;
#warning UPGRADE!
- CTagInt32( char2unicode(namebuffer), (uint32)gaplist.GetAt(pos)->start ).WriteTagToFile( &file );
+ wxString sJunk = char2unicode( namebuffer ); // 20060122/Radek TEST
+ CTagInt32( sJunk, (uint32)gaplist.GetAt(pos)->start ).WriteTagToFile( &file );
// gap start = first missing byte but gap ends = first non-missing byte
// in edonkey but I think its easier to user the real limits
namebuffer[0] = FT_GAPEND;
- CTagInt32( char2unicode(namebuffer), (uint32)(gaplist.GetAt(pos)->end + 1) ).WriteTagToFile( &file );
+ sJunk = char2unicode( namebuffer ); // 20060122/Radek TEST
+ CTagInt32( sJunk, (uint32)(gaplist.GetAt(pos)->end + 1) ).WriteTagToFile( &file );
++i_pos; Afterwards, the compilation went through without further complaints.
This code should do the same as the original one. It is slightly less elegant ;) but if it works...
I have no real idea, what the older compiler versions have against the original version of the code.. Also I'm not sure, what optimizations make out of it. Maybe it would be better to define sJunk outside of the loop (I have no experience with gcc, I normally use Keil or Watcom)
-
The tag constructor takes a wxString reference, but char2unicode returns a char-buffer, which it seems gcc-3.3 has trouble implicitly converting to a wxString. I'm making some changes that will fix the problem.
-
As long as you don't make it slower like radek's one...
-
Originally posted by stefanero
old gcc probably...
works here on gentoo, gcc-3.4.5 and 4.0.2
indeed, after having installed gcc 3.4.5 here now, it seems to work on SuSE9.3 again.
-
Well today's one should work on all anyway
-
It does compile on Debian Sarge now without complaints.
@Kry
My experiment was of course not intended for production. I could see that this part of code was work in progress and didn't have the time to really grasp the surrounding context. I just wanted to find out what the problem was, because I couldn't see any. Call it professional curiosity ;)
But why do you think my ugly fix would work slower? IMHO, the only difference to your code is that the conversion normally done implicitly by the compiler was done explicitly. And the question of the variable assignment inside the loop being a slow down depends on the optimizer. With a standard optimizer the resulting code could very well be the same.
I often have to work around compiler bugs or similar problems, because I have inherited projects that are old enough (>>20 years), that the compilers used at that time were still quite buggy. And no one pays for renewing, so all have to live with the work hours that go into programming around such annoying problems (Sometimes the code doesn't work anymore if I remove a comment line :) ).
-
Originally posted by Radek
It does compile on Debian Sarge now without complaints.
@Kry
My experiment was of course not intended for production. I could see that this part of code was work in progress and didn't have the time to really grasp the surrounding context. I just wanted to find out what the problem was, because I couldn't see any. Call it professional curiosity ;)
But why do you think my ugly fix would work slower? IMHO, the only difference to your code is that the conversion normally done implicitly by the compiler was done explicitly. And the question of the variable assignment inside the loop being a slow down depends on the optimizer. With a standard optimizer the resulting code could very well be the same.
I often have to work around compiler bugs or similar problems, because I have inherited projects that are old enough (>>20 years), that the compilers used at that time were still quite buggy. And no one pays for renewing, so all have to live with the work hours that go into programming around such annoying problems (Sometimes the code doesn't work anymore if I remove a comment line :) ).
Sure the variable creation and assignment inside the loop was slower, and optimizations are not involved because we always work with debug and no optimizations anyway. There was nothing wrong on your code and I know it was not intended for final purposes. That was a warning for Xaignar, and he did well on the change ;)
-
Some people just perfer to let the compiler do the lowlevel optimizations. ;)