Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[[007_Band]]

Hi

hab nach langer Zeit ein Update (wegen Hardware Problemen) auf Suse 10 gemacht
und nun ein Problem beim kompilieren von aMule.

Den Fehler bekomme ich sowohl bei 2.0.3 (siehe Log) und bei CVS.
Die aktuell verwendete wxGTK Version ist die letzte CVS Version (mit 2.6.2 hatte ich
das gleiche Problem):

Code: [Select]

AICHSyncThread.cpp:(.gnu.linkonce.t._ZNSt10_List_baseI9CAICHHashSaIS0_EE7__clearEv+0x61): undefined reference to `std::__default_alloc_template::_S_node_allocator_lock'
AICHSyncThread.cpp:(.gnu.linkonce.t._ZNSt10_List_baseI9CAICHHashSaIS0_EE7__clearEv+0x74): undefined reference to `std::__default_alloc_template::_S_node_allocator_lock'
amule-AICHSyncThread.o: In function `std::_List_base >::__clear()':
AICHSyncThread.cpp:(.gnu.linkonce.t._ZNSt10_List_baseIP10CKnownFileSaIS1_EE7__clearEv+0x37): undefined reference to `std::__default_alloc_template::_S_force_new'
AICHSyncThread.cpp:(.gnu.linkonce.t._ZNSt10_List_baseIP10CKnownFileSaIS1_EE7__clearEv+0x4d): undefined reference to `std::__default_alloc_template::_S_free_list'
AICHSyncThread.cpp:(.gnu.linkonce.t._ZNSt10_List_baseIP10CKnownFileSaIS1_EE7__clearEv+0x57): undefined reference to `std::__default_alloc_template::_S_free_list'
AICHSyncThread.cpp:(.gnu.linkonce.t._ZNSt10_List_baseIP10CKnownFileSaIS1_EE7__clearEv+0x61): undefined reference to `std::__default_alloc_template::_S_node_allocator_lock'
AICHSyncThread.cpp:(.gnu.linkonce.t._ZNSt10_List_baseIP10CKnownFileSaIS1_EE7__clearEv+0x74): undefined reference to `std::__default_alloc_template::_S_node_allocator_lock'
amule-AICHSyncThread.o: In function `std::list >::erase(std::_List_iterator)':
AICHSyncThread.cpp:(.gnu.linkonce.t._ZNSt4listIP10CKnownFileSaIS1_EE5eraseESt14_List_iteratorIS1_RS1_PS1_E+0x1c): undefined reference to `std::__default_alloc_template::_S_force_new'
AICHSyncThread.cpp:(.gnu.linkonce.t._ZNSt4listIP10CKnownFileSaIS1_EE5eraseESt14_List_iteratorIS1_RS1_PS1_E+0x4a): undefined reference to `std::__default_alloc_template::_S_free_list'
AICHSyncThread.cpp:(.gnu.linkonce.t._ZNSt4listIP10CKnownFileSaIS1_EE5eraseESt14_List_iteratorIS1_RS1_PS1_E+0x57): undefined reference to `std::__default_alloc_template::_S_free_list'
AICHSyncThread.cpp:(.gnu.linkonce.t._ZNSt4listIP10CKnownFileSaIS1_EE5eraseESt14_List_iteratorIS1_RS1_PS1_E+0x63): undefined reference to `std::__default_alloc_template::_S_node_allocator_lock'
AICHSyncThread.cpp:(.gnu.linkonce.t._ZNSt4listIP10CKnownFileSaIS1_EE5eraseESt14_List_iteratorIS1_RS1_PS1_E+0x74): undefined reference to `std::__default_alloc_template::_S_node_allocator_lock'
amule-AICHSyncThread.o: In function `std::list >::insert(std::_List_iterator, CKnownFile* const&)':
AICHSyncThread.cpp:(.gnu.linkonce.t._ZNSt4listIP10CKnownFileSaIS1_EE6insertESt14_List_iteratorIS1_RS1_PS1_ERKS1_+0x11): undefined reference to `std::__default_alloc_template::allocate(unsigned int)'
amule-AICHSyncThread.o: In function `std::list >::insert(std::_List_iterator, CAICHHash const&)':
AICHSyncThread.cpp:(.gnu.linkonce.t._ZNSt4listI9CAICHHashSaIS0_EE6insertESt14_List_iteratorIS0_RS0_PS0_ERKS0_+0x15): undefined reference to `std::__default_alloc_template::allocate(unsigned int)'
amule-ExternalConn.o: In function `pair':
/usr/include/c++/4.0.2/bits/stl_pair.h:85: undefined reference to `CValueMap::CValueMap(CValueMap const&)'
amule-ExternalConn.o: In function `~pair':
/usr/include/c++/4.0.2/bits/stl_pair.h:69: undefined reference to `CValueMap::~CValueMap()'
amule-ExternalConn.o: In function `pair':
/usr/include/c++/4.0.2/bits/stl_pair.h:69: undefined reference to `CValueMap::CValueMap(CValueMap const&)'
amule-ExternalConn.o: In function `__gnu_cxx::new_allocator::destroy(CMD4Hash*)':
/usr/include/c++/4.0.2/ext/new_allocator.h:109: undefined reference to `CMD4Hash::~CMD4Hash()'
amule-ExternalConn.o: In function `std::map, std::allocator > >::operator[](void* const&)':
/usr/include/c++/4.0.2/bits/stl_map.h:339: undefined reference to `CValueMap::~CValueMap()'
/usr/include/c++/4.0.2/bits/stl_map.h:339: undefined reference to `CValueMap::~CValueMap()'
/usr//lib/libwx_gtk2u_adv-2.7.so: undefined reference to `SetInvokingWindow(wxMenu*, wxWindow*)'
collect2: ld returned 1 exit status
make[3]: *** [amule] Fehler 1
make[3]: Leaving directory `/home/berniyh/temp/amule/aMule-2.0.3/src'
make[2]: *** [all-recursive] Fehler 1
make[2]: Leaving directory `/home/berniyh/temp/amule/aMule-2.0.3/src'
make[1]: *** [all-recursive] Fehler 1
make[1]: Leaving directory `/home/berniyh/temp/amule/aMule-2.0.3'
make: *** [all] Fehler 2

Ich hab was ähnliches im Compiling Problems Thread gefunden, aber da ging es wohl
nur um die CVS Version, während ich den Fehler auch mit 2.0.3 hab.
Meine Vermutung liegt eher beim gcc Version 4.0.2
Auch die Workarounds hab ich ausprobiert und keinen Erfolgt gehabt.

Vielleicht kann mir einer von euch helfen.

[wuischke]

Das lustige GCC-4-Spielchen hatte ich auch mal, ich hatte dann die gcc-3.3 installiert und als unsauberen Workaround halt die Symlinks geändert.
In etwa:

Code: [Select]

cd /usr/bin/
su
mv gcc gcc-old
ln -s gcc-3.3 gcc
mv g++ g++-old
ln -s g++-3.3 gcc
mv cpp cpp-old
ln -s cpp-3.3 cppEdit: Nachher halt wieder zurückschreiben, geht sicher auch einfacher, aber ich war da froh überhaupt eine Lösung gefunden zu haben...

[[007_Band]]

aber es muss doch möglich sein, amule mit gcc 4 zu kompilieren, oder lieg ich da falsch?

[wuischke]

Es geht - eigentlich - auch mit gcc-4.0.2 (in meinem Fall mit gcc-Version 4.0.2 20050808 (prerelease)) zu kompilieren, aber da du vermutet hast, dass es daran liegt, wollte ich sehen, ob der Fehler auch mit der gcc-3.3 kommt.

[Gerd78]

Poste mal zusätzlich die Zeile direkt über der Fehlermeldung mit dem Compileraufruf. Der Compiler scheint nämlich die C++-Standardbibliothek aus irgendeinem Grund nicht mitgelinkt zu haben. Das ist übrigens grundsätzlich bei Kompilierfehlern immer nützlich.

Welche GCCs hast Du denn überhaupt installiert? C++-Code von GCC 3.3 und 4.0 kann man nicht kombinieren. Wenn *alle* beteiligten Bibliotheken mit dem GCC 4.0.2 kompiliert sind, gibt es eigentlich normalerweise kein Problem.

PS: Dieser Fehler hier

Code: [Select]

/usr//lib/libwx_gtk2u_adv-2.7.so: undefined reference to `SetInvokingWindow(wxMenu*, wxWindow*)'tritt mit wxWidgets CVS >= 20051224 auf, probier wxWidgets CVS 20051223 von hier:

http://biolpc22.york.ac.uk/pub/CVS_HEAD/files/wx-cvs-Gtk-2005-12-23.tar.bz2

PPS: Um mehrere GCCs abwechselnd zu benutzen, muss man keine Symlinks ändern. Bei autoconf-basierten Paketen reicht es, die Umgebungsvariablen "CC" und "CXX" vorher auf den gewünschten gcc bzw. g++ zu setzen.

Dabei muss man allerdings darauf achten, dass man "CXX" wirklich auf den gewünschten g++ und nicht auf den entsprechenden gcc setzt, andernfalls werden C++-Sourcen als C-Sourcen übersetzt, was spätestens beim Linken nicht klappen kann, da die C++-Standardlibliothek nicht mitgelinkt wird.

[[007_Band]]

Meinst du das hier:

Code: [Select]

g++  -DUSE_EMBEDDED_CRYPTO -W -Wall -g -ggdb -fno-inline -D__DEBUG__ -fmessage-length=0 -O2   -lpthread -o amule  amule-AddFriend.o amule-AddFileThread.o amule-AICHSyncThread.o amule-amule.o amule-amule-gui.o amule-amuleDlg.o amule-BarShader.o amule-BaseClient.o amule-ChatSelector.o amule-ChatWnd.o amule-CatDialog.o amule-CFile.o amule-ClientCredits.o amule-ClientDetailDialog.o amule-ClientList.o amule-ClientListCtrl.o amule-ClientUDPSocket.o amule-ColorFrameCtrl.o amule-CommentDialog.o amule-CommentDialogLst.o amule-DataToText.o amule-DeadSourceList.o amule-DirectoryTreeCtrl.o amule-DownloadClient.o amule-DownloadListCtrl.o amule-DownloadQueue.o amule-ECSocket.o amule-ECPacket.o amule-ECSpecialTags.o amule-ED2KLink.o amule-EditServerListDlg.o amule-EMSocket.o amule-ExternalConn.o amule-FileDetailDialog.o amule-FileDetailListCtrl.o amule-filefn.o amule-Format.o amule-Friend.o amule-FriendList.o amule-FriendListCtrl.o amule-HTTPDownload.o amule-IPFilter.o amule-KnownFile.o amule-KadDlg.o amule-KnownFileList.o amule-ListenSocket.o amule-listctrl.o amule-Logger.o amule-MemFile.o amule-MD5Sum.o amule-MuleGifCtrl.o amule-MuleListCtrl.o amule-MuleNotebook.o amule-MuleTextCtrl.o amule-muuli_wdr.o amule-NetworkFunctions.o amule-OScopeCtrl.o amule-OtherFunctions.o amule-Packet.o amule-PartFile.o amule-Preferences.o amule-PrefsUnifiedDlg.o amule-Proxy.o amule-SafeFile.o amule-SearchDlg.o amule-SearchList.o amule-SearchListCtrl.o amule-Server.o amule-ServerConnect.o amule-ServerList.o amule-ServerListCtrl.o amule-ServerSocket.o amule-ServerUDPSocket.o amule-ServerWnd.o amule-SharedFileList.o amule-SharedFilesCtrl.o amule-SharedFilesWnd.o amule-SHA.o amule-SHAHashSet.o amule-Statistics.o amule-StatisticsDlg.o amule-StateMachine.o amule-StringFunctions.o amule-TransferWnd.o amule-UploadClient.o amule-UploadQueue.o amule-ByteIO.o amule-DataIO.o amule-FileIO.o amule-IOException.o amule-UInt128.o    amule-MuleTrayIcon.o amule-CryptoPP.o -L/usr//lib -pthread   -L/usr/X11R6/lib  -lwx_gtk2u_xrc-2.7 -lwx_gtk2u_qa-2.7 -lwx_gtk2u_html-2.7 -lwx_gtk2u_adv-2.7 -lwx_gtk2u_core-2.7 -lwx_baseu_xml-2.7 -lwx_baseu_net-2.7 -lwx_baseu-2.7  -lz   -lbfd -liberty
Also ich bin jetzt mal daran, das von dir empfohlene wxCVS zu kompilieren, dann
versuch ich es nochmal.

Da bei S10 der gcc 4 standart ist sollte es da eigentlich keine Probleme bezüglich
Versionsunterschiede geben. Selbstkompiliert hab ich eigentlich nur wxCVS und
aMule, da es erfahrungsgemäß bei Suse ziemlich viele Probleme gibt, wenn man
Tarballs für libs o.ä. verwendet.

[Gerd78]

Originally posted by [007_Band]
Meinst du das hier:

Ja, genau. Ich seh da allerdings auch nichts auffälliges drin...

Originally posted by [007_Band]
Also ich bin jetzt mal daran, das von dir empfohlene wxCVS zu kompilieren, dann
versuch ich es nochmal.

OK, tu das.

Originally posted by [007_Band]
Da bei S10 der gcc 4 standart ist sollte es da eigentlich keine Probleme bezüglich
Versionsunterschiede geben.

Richtig, gibt es auch normalerweise nicht. Ich nehm den GCC 4.0.2 für alles und hatte zwar diverse Probleme, die alle GCC 4-Benutzer haben, aber nicht mit aMule.

Originally posted by [007_Band]
Selbstkompiliert hab ich eigentlich nur wxCVS und
aMule, da es erfahrungsgemäß bei Suse ziemlich viele Probleme gibt, wenn man
Tarballs für libs o.ä. verwendet.

Gilt nicht für SuSE 10.0, das dort mitgelieferte wx-RPM ist OK.

[[007_Band]]

Ich meinte jetzt eher, wenn man andere libs oder programme kompiliert
(z.B. vlc+libs,xmms+libs,o.ä.)
Meistens geht da irgendwas schief.

Wenn man eine Dist zum kompilieren sucht finde ich Gentoo bequemer
oder noch Debian. Allerdings ist mir Gentoo für den Server hier zu stressig.
Verrichtet aber an dem PC hier einen guten Job :-)

[Gerd78]

Originally posted by [007_Band]
Ich meinte jetzt eher, wenn man andere libs oder programme kompiliert
(z.B. vlc+libs,xmms+libs,o.ä.)
Meistens geht da irgendwas schief.

Warum sollte da bei einer Distribution mehr schief gehen als bei einer anderen?

VLC ist verdammt unangenehm selber zu bauen, das ist aber keine Distributionsfrage, sondern liegt daran, dass es selbst aus mindestens einem Dutzend Paketen besteht, die wiederum Dutzende von Abhängigkeiten zu anderen Paketen haben. Das ist so bei aMule nicht der Fall. Bei sowas ist eine Hilfestellung wie ein ebuild wirklich nötig.

Originally posted by [007_Band]
Wenn man eine Dist zum kompilieren sucht finde ich Gentoo bequemer
oder noch Debian.

Gentoo ist darauf ausgelegt, dass man selber kompiliert, aber eben auch nur, wenn es um distributionseigene oder von Drittparteien zur Verfügung gestellte ebuilds geht. Beim "richtigen" Selberbauen ohne Hilfestellung mittels ebuild gibt es eigentlich keinen Unterschied.

Bei Debian ist die Paketverwaltung angenehm, was aber auch wieder mehr oder weniger wegfällt, wenn man z.B. wxWidgets unabhängig von der Paketverwaltung selber baut, und die paar anderen *-devel-Pakete kriegt man doch bestimmt auch so zusammen.

Aber nochmal zum eigentlichen Thema. Das hier:

Code: [Select]

AICHSyncThread.cpp:(.gnu.linkonce.t._ZNSt10_List_baseI9CAICHHashSaIS0_EE7__clearEv+0x61): undefined reference to `std::__default_alloc_template::_S_node_allocator_lock'
AICHSyncThread.cpp:(.gnu.linkonce.t._ZNSt10_List_baseI9CAICHHashSaIS0_EE7__clearEv+0x74): undefined reference to `std::__default_alloc_template::_S_node_allocator_lock'gefällt mir ganz und gar nicht - "undefined reference to `std::__default_alloc_template::_S_node_allocator_lock'" sieht auf den ersten Blick nach einem Problem mit der C++-Standardbibliothek aus. Bist Du sicher, dass das wirklich die komplette Fehlermeldung ist und dass das Paket "libstdc++-devel" korrekt installiert ist?

[[007_Band]]

Originally posted by Gerd78

Originally posted by [007_Band]
Ich meinte jetzt eher, wenn man andere libs oder programme kompiliert
(z.B. vlc+libs,xmms+libs,o.ä.)
Meistens geht da irgendwas schief.

Warum sollte da bei einer Distribution mehr schief gehen als bei einer anderen?

Wenn ich das wüsste, wieso ich bei Suse mehr Probleme damit hatte als bei anderen
Distributionen, dann wäre es wahrscheinlich kein Problem ;-)
Wobei sich das bei den letzten paar Versionen auch gebessert hat.

Originally posted by Gerd78
VLC ist verdammt unangenehm selber zu bauen, das ist aber keine Distributionsfrage, sondern liegt daran, dass es selbst aus mindestens einem Dutzend Paketen besteht, die wiederum Dutzende von Abhängigkeiten zu anderen Paketen haben. Das ist so bei aMule nicht der Fall. Bei sowas ist eine Hilfestellung wie ein ebuild wirklich nötig.

VLC ist wirklich unangenehm, aber nicht unmachbar.
Allerdings grenzt das wirklich an masochismus

Originally posted by Gerd78
Aber nochmal zum eigentlichen Thema. Das hier:

Code: [Select]

AICHSyncThread.cpp:(.gnu.linkonce.t._ZNSt10_List_baseI9CAICHHashSaIS0_EE7__clearEv+0x61): undefined reference to `std::__default_alloc_template::_S_node_allocator_lock'
AICHSyncThread.cpp:(.gnu.linkonce.t._ZNSt10_List_baseI9CAICHHashSaIS0_EE7__clearEv+0x74): undefined reference to `std::__default_alloc_template::_S_node_allocator_lock'gefällt mir ganz und gar nicht - "undefined reference to `std::__default_alloc_template::_S_node_allocator_lock'" sieht auf den ersten Blick nach einem Problem mit der C++-Standardbibliothek aus. Bist Du sicher, dass das wirklich die komplette Fehlermeldung ist und dass das Paket "libstdc++-devel" korrekt installiert ist?

Mit dem anderen Tarball für wxCVS hat es funktioniert. Ich hatte zwar noch ein anderes
probiert, aber da muss man wohl auch ein bisschen Glück haben.
Aber vielen Dank für die Hilfe.

[thedude0001]

SuSE hat die Unart ihre Pakete massiv zu patchen. Das funktioniert solange (relativ) gut wie es ein reines SuSE-System ist, wenn selbstkompilierte Pakete ins Spiel kommen wird es sehr schnell häßlich ^^

[Gerd78]

Originally posted by thedude0001
SuSE hat die Unart ihre Pakete massiv zu patchen.

Naja, wenn man wirklich mal in die Source-Pakete reinschaut und zum Vergleich die Source-Pakete anderer Distris dazunimmt, stelle zumindest ich eigentlich relativ schnell fest, dass das so nicht ganz stimmt. Bei RPM-basierten Distris liegen die Source-Pakete meistens auf dem FTP, bei Debian kann man die Patches sogar direkt online ansehen - das sind auch nicht gerade wenige, manchmal sogar deutlich mehr. Wenn man mal den Kernel als Beispiel nimmt, patcht SuSE genau gleich viel wie Fedora und Mandrake und weniger als Ubuntu. Diese Feststellung beruht teilweise auch wirklich auf Vorurteilen. Eine Binärdistribution, die kaum gepatchte Pakete enthält, wird man so schnell nicht finden.

Übrigens: Patches, die entweder die API oder ABI einer Bibliothek ändern und somit das Kompilieren oder Laufenlassen anderer Anwendungen erschweren, sind laut Policy sämtlicher Distributionen einschließlich SuSE strengstens verboten. Wenn man trotzdem mal auf sowas stößt und auch mal direkt ins Source-Paket reinschaut, um festzustellen, dass es wirklich an einem distributionseigenen Patch liegt, dann handelt es sich um einen Bug, der zu melden wäre. Was die Distributoren nicht wissen, können sie auch nicht fixen. => Deswegen: http://www.opensuse.org/Submit_a_bug

[thedude0001]

OKOK, ich gebe ja zu, das ist größtenteils kein begründetes, auf wissenschaftlich erhobenen Fakten basierendes Wissen sondern vielleicht eher Vorurteil. Ich will das auch nicht weiter verfolgen und statistische Aufstellungen machen wer wieviel patcht und welche Policies wo herrschen, ich habe absolut keine Lust auf einen Distr-Flame-War ^^

Ich ziehe meinen Einwurf zurück und arbeite lieber mit meinem Gentoo-Rechner noch ein wenig an der allgemeinen Energieknappheit und der globalen Erwärmung

[Gerd78]

Originally posted by thedude0001
Ich ziehe meinen Einwurf zurück und arbeite lieber mit meinem Gentoo-Rechner noch ein wenig an der allgemeinen Energieknappheit und der globalen Erwärmung

OK, dann wären ja alle Klischees bedient.