FreeBSD 4.11 linking..bin ich zu blöd?

Status
Für weitere Antworten geschlossen.

holm

Well-Known Member
..oder hab ich mittlerweile was vergessen?

Ich habe das Problem das ich auf einem bockbeinalten FreeBSD 4.11 Firewall das ich mal gebaut habe einen neueren Squid basteln muß,
weil irgend eine BehördenIT Hals über Kopf das Transferprotokoll Irgend einer Applikation auf http 1.1 geändert hat. Der ganze Laden wird
demnächst zwangsweise sowieso an das Behördennetz angeschlossen...das ist also ein Provisorium.

Einen aktuellen Squid kann man nicht bauen, die Sourcen verlangen einen c11 kompatibeln Compiler, das letzte as ich als Pakackagfe habe auftreiben können ist ein gcc4.0 und damit läßt sich auch nur ein squid 3.5.27 übersetzen..wenn es denn funktioniert.

Ich stoße allerdings beim bauen auf dieses Problem:

# make
/bin/sh ../../../libtool --tag=CXX --mode=link /usr/local/bin/c++40 -Wall -Wpointer-arith -Wwrite-strings -Wcomments -Wshadow -Woverloaded-virtual -Werror -pipe -D_REENTRANT -g -O2 -I/usr/local/include -g -L/usr/local/lib -Wl,-R/usr/local/lib -pthread -o basic_pam_auth basic_pam_auth.o ../../../lib/libmiscencoding.la ../../../compat/libcompat-squid.la -lpam -lm
libtool: link: /usr/local/bin/c++40 -Wall -Wpointer-arith -Wwrite-strings -Wcomments -Wshadow -Woverloaded-virtual -Werror -pipe -D_REENTRANT -g -O2 -I/usr/local/include -g -Wl,-R/usr/local/lib -pthread -o basic_pam_auth basic_pam_auth.o -L/usr/local/lib ../../../lib/.libs/libmiscencoding.a ../../../compat/.libs/libcompat-squid.a -lpam -lm -pthread
basic_pam_auth.o: In function `main':
/usr/home/wheel/holm/src/squid-3.5.27/helpers/basic_auth/PAM/basic_pam_auth.cc:257: undefined reference to `pam_end(pam_handle*, int)'
/usr/home/wheel/holm/src/squid-3.5.27/helpers/basic_auth/PAM/basic_pam_auth.cc:264: undefined reference to `pam_start(char const*, char const*, pam_conv const*, pam_handle**)'
/usr/home/wheel/holm/src/squid-3.5.27/helpers/basic_auth/PAM/basic_pam_auth.cc:296: undefined reference to `pam_end(pam_handle*, int)'
/usr/home/wheel/holm/src/squid-3.5.27/helpers/basic_auth/PAM/basic_pam_auth.cc:305: undefined reference to `pam_end(pam_handle*, int)'
/usr/home/wheel/holm/src/squid-3.5.27/helpers/basic_auth/PAM/basic_pam_auth.cc:292: undefined reference to `pam_set_item(pam_handle*, int, void const*)'
/usr/home/wheel/holm/src/squid-3.5.27/helpers/basic_auth/PAM/basic_pam_auth.cc:249: undefined reference to `pam_start(char const*, char const*, pam_conv const*, pam_handle**)'
/usr/home/wheel/holm/src/squid-3.5.27/helpers/basic_auth/PAM/basic_pam_auth.cc:274: undefined reference to `pam_set_item(pam_handle*, int, void const*)'
/usr/home/wheel/holm/src/squid-3.5.27/helpers/basic_auth/PAM/basic_pam_auth.cc:276: undefined reference to `pam_set_item(pam_handle*, int, void const*)'
/usr/home/wheel/holm/src/squid-3.5.27/helpers/basic_auth/PAM/basic_pam_auth.cc:279: undefined reference to `pam_authenticate(pam_handle*, int)'
/usr/home/wheel/holm/src/squid-3.5.27/helpers/basic_auth/PAM/basic_pam_auth.cc:281: undefined reference to `pam_acct_mgmt(pam_handle*, int)'
collect2: ld returned 1 exit status
*** Error code 1

# nm --dynamic /lib/libpam.so.1|grep "T pam"

00003544 T pam_acct_mgmt
0000345c T pam_authenticate
00003098 T pam_authenticate_secondary
000030f4 T pam_chauthtok
000038a4 T pam_clear_option
00003050 T pam_close_session
000031c8 T pam_end
00004730 T pam_fail_delay
00004884 T pam_get_data
00006678 T pam_get_item
00002084 T pam_get_pass
00006788 T pam_get_user
00003ec8 T pam_getenv
00004068 T pam_getenvlist
00002b0c T pam_misc_copy_env
00002b30 T pam_misc_drop_env
00002ba0 T pam_misc_paste_env
00002bec T pam_misc_setenv
00003008 T pam_open_session
000038c4 T pam_prompt
00003b9c T pam_putenv
0000478c T pam_set_data
00006254 T pam_set_item
00003884 T pam_set_option
000034ec T pam_setcred
00002cc0 T pam_start
00003630 T pam_std_option
00005a18 T pam_strerror
00006a0c T pam_system_log
00003858 T pam_test_option
000069e0 T pam_vsystem_log
#

Warum kann der Linker meine libpam.so.1 nicht leiden? Hab ich irgendwas Wesentliches vergessen?

Gruß,

Holm
 
Das einzige was mir dazu einfällt: Liegt vielleicht in /usr/local/lib auch eine libpam?

Aber ist da nicht auch langsam der Punkt erreicht, wo eine Neuinstallation mit FreeBSD 11 oder 12 weniger schmerzhaft wäre? :o
 
Der squid konnte m.W. http1.1 ab Version 3.2 - ggf kannst ne solche gut abgehangene Version noch downloaden und die kompilieren?

Kenn jetzt die ganze Situation natürlich ned, aber ggf wäre ne alte Maschine welche u.U. noch irgendwo in nem Regal rumdümpelt mit ner OPNsense Installation und proxy ne schnellere Lösung (und genauso provisorisch) aber halt mit modernem OS?
 
-Nein, es liegt nirgendwo anders eine libpam, allerdings ist /usr/src drauf und ich habe die auch schon neu gebaut und installiert, einen Unterschied macht das nicht.

"Das Netz" ist sehr unterschiedlicher Ansicht ab wann squid http 1.1 kann, irgendwo ab 3.1, 3.2..unvollständig, z.B. antwortet er auf Requests mit 1.1 mit Antworten in 1.0 oder so..hatte quer drüber gelesen.

Das was über die Maschine rollert ist nicht ganz trivial, aber sie soll noch 2 - 4 Wochen laufen. Klappt das mit dem Squid nicht, kann die Gemeinde keine Kindergeldanträge bearbeiten...

Es ist völlig Rille welche Version ich am Wickel habe, ich habe jetzt aus lauter Spaß an der Freude den Fetch für die 3.4.14 Sourcen angestoßen, ich vermute das geht nicht anders aus, PAM war bei 4.11 nicht so neu...
Findet Jemand evtl. eine Package eines neueren GCC als 4.0.0 irgendwo? Das Ding aus den Sourcen zu bauen wäre für die Mühle wirklich Tierquälerei...

CPU: Intel Pentium III (701.59-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0x683 Stepping = 3
Features=0x383f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PA
T,PSE36,MMX,FXSR,SSE>
real memory = 201314304 (196596K bytes)
avail memory = 191930368 (187432K bytes)

Immerhin ein 700er P3... auf einem Intel BX440..erklärt warum der noch läuft :-)

Gruß,
Holm

Update: Das Problem ist mit squid 3.4.14 exakt das Selbe.

Ich habe probehalber /usr/src/secure/libexec/telnetd gebaut, der wirtd auch gegen libpam gelinkt, das funktioniert einwandfrei,
allerdings mit dem System Compiler, IMHO gcc 2.9.5.

Gruß,
Holm
 
Zuletzt bearbeitet:
Das was über die Maschine rollert ist nicht ganz trivial, aber sie soll noch 2 - 4 Wochen laufen. Klappt das mit dem Squid nicht, kann die Gemeinde keine Kindergeldanträge bearbeiten...

Das wollen wir natürlich nicht. :) FreeBSD 4.11 ist echt lange her... gcc 4 zum Glück nicht nicht allzu lange, das Ding ist fast unsterblich. FreeBSD hat ihn nun ja erfolgreich tot geschlagen, aber einfach war das nicht. Vorweg: gcc 2.9.5 hat noch das alte C++-Frontend. Squid wird damit wahrscheinlich nicht bauen. Da Arbeit reinzustecken ist sinnlos.

Ich würde gerne erst einmal das Linkerkommando sehen. Also was gcc genau aufruft um das Programm zu linken. Dafür gehst du einmal ein das gleiche Verzeichnis, in dem du auch make aufrufst und rufst den Compiler einmal manuell auf:

Code:
/usr/local/bin/c++40 -Wall -Wpointer-arith -Wwrite-strings -Wcomments -Wshadow -Woverloaded-virtual -Werror -pipe -D_REENTRANT -g -O2 -I/usr/local/include -g -Wl,-R/usr/local/lib -pthread -o basic_pam_auth basic_pam_auth.o  -L/usr/local/lib ../../../lib/.libs/libmiscencoding.a ../../../compat/.libs/libcompat-squid.a -lpam -lm -pthread

Das sollte zu dem exakt gleichen Fehler wie oben führen. Wenn es das nicht tut, müsstest du einmal die neue Fehlermeldung zeigen. Klappt es, also bekommst du den gleichen Fehler, führst du das Kommando einmal im Verbose Mode aus:

Code:
/usr/local/bin/c++40 -v -Wall -Wpointer-arith -Wwrite-strings -Wcomments -Wshadow -Woverloaded-virtual -Werror -pipe -D_REENTRANT -g -O2 -I/usr/local/include -g -Wl,-R/usr/local/lib -pthread -o basic_pam_auth basic_pam_auth.o  -L/usr/local/lib ../../../lib/.libs/libmiscencoding.a ../../../compat/.libs/libcompat-squid.a -lpam -lm -pthread

Ich habe da ein -v eingefügt. Das wird einiges an Ausgabe generieren. Du brauchen wir einmal komplett. Daraus kann man idealerweise ableiten, was schief geht.
 
..den ersten Teil spare ich mir mal..denn der Fehler ist identisch, damit eiere ich schon die ganze Zeit herum und versuche herauszufinden was lost ist

Hier mal mit -v

# /usr/local/bin/c++40 -v -Wall -Wpointer-arith -Wwrite-strings -Wcomments -Wshadow -Woverloaded-virtual -Werror -pipe -D_REENTRANT -g -O2 -I/usr/local/include -g -Wl,-R/u
sr/local/lib -pthread -o basic_pam_auth basic_pam_auth.o -L/usr/local/lib ../../../lib/.libs/libmiscencoding.a ../../../compat/.libs/libcompat-squid.a -lpam -lm -pthread
Using built-in specs.
Configured with: ./..//gcc-4.0-20041226/configure --disable-nls --with-system-zlib --with-libiconv-prefix=/usr/local --program-suffix=40 --with-gxx-include-dir=/usr/local/lib/gcc/i386-portbld-freebsd4.11/4.0.0/include/c++/ --disable-shared --disable-libgcj --prefix=/usr/local i386-portbld-freebsd4.11
Thread model: posix
gcc version 4.0.0 20041226 (experimental) [FreeBSD]
/usr/local/libexec/gcc/i386-portbld-freebsd4.11/4.0.0/collect2 -V -dynamic-linker /usr/libexec/ld-elf.so.1 -o basic_pam_auth /lib/crt1.o /lib/crti.o /usr/local/lib/gcc/i386-portbld-freebsd4.11/4.0.0/crtbegin.o -L/usr/local/lib -L/usr/local/lib/gcc/i386-portbld-freebsd4.11/4.0.0 -L/usr/local/lib/gcc/i386-portbld-freebsd4.11/4.0.0/../../.. -R/usr/local/lib basic_pam_auth.o ../../../lib/.libs/libmiscencoding.a ../../../compat/.libs/libcompat-squid.a -lpam -lstdc++ -lm -lgcc -lc_r -lgcc /usr/local/lib/gcc/i386-portbld-freebsd4.11/4.0.0/crtend.o /lib/crtn.o
basic_pam_auth.o: In function `main':
/usr/home/wheel/holm/src/squid-3.5.27/helpers/basic_auth/PAM/basic_pam_auth.cc:257: undefined reference to `pam_end(pam_handle*, int)'
/usr/home/wheel/holm/src/squid-3.5.27/helpers/basic_auth/PAM/basic_pam_auth.cc:264: undefined reference to `pam_start(char const*, char const*, pam_conv const*, pam_handle**)'
/usr/home/wheel/holm/src/squid-3.5.27/helpers/basic_auth/PAM/basic_pam_auth.cc:296: undefined reference to `pam_end(pam_handle*, int)'
/usr/home/wheel/holm/src/squid-3.5.27/helpers/basic_auth/PAM/basic_pam_auth.cc:305: undefined reference to `pam_end(pam_handle*, int)'
/usr/home/wheel/holm/src/squid-3.5.27/helpers/basic_auth/PAM/basic_pam_auth.cc:292: undefined reference to `pam_set_item(pam_handle*, int, void const*)'
/usr/home/wheel/holm/src/squid-3.5.27/helpers/basic_auth/PAM/basic_pam_auth.cc:249: undefined reference to `pam_start(char const*, char const*, pam_conv const*, pam_handle**)'
/usr/home/wheel/holm/src/squid-3.5.27/helpers/basic_auth/PAM/basic_pam_auth.cc:274: undefined reference to `pam_set_item(pam_handle*, int, void const*)'
/usr/home/wheel/holm/src/squid-3.5.27/helpers/basic_auth/PAM/basic_pam_auth.cc:276: undefined reference to `pam_set_item(pam_handle*, int, void const*)'
/usr/home/wheel/holm/src/squid-3.5.27/helpers/basic_auth/PAM/basic_pam_auth.cc:279: undefined reference to `pam_authenticate(pam_handle*, int)'
/usr/home/wheel/holm/src/squid-3.5.27/helpers/basic_auth/PAM/basic_pam_auth.cc:281: undefined reference to `pam_acct_mgmt(pam_handle*, int)'
GNU ld version 2.12.1 [FreeBSD] 2002-07-20
Supported emulations:
elf_i386
collect2: ld returned 1 exit status

...sieht nur bunter aus ---

Gruß,
Holm
 
Dagegen kann ich nicht mal was sagen...immerhin hat es die Release 4 bis zu Version 11 geschafft. Danach kam die Featuritis.. nur ungern erinnere ich mich an die 5er Versionen...

hilft mir nur leider gar nicht.

Gruß,

Holm
 
Also, das letztendlich aufgerufener Linkerkommando ist:

Code:
/usr/local/libexec/gcc/i386-portbld-freebsd4.11/4.0.0/collect2 -V -dynamic-linker /usr/libexec/ld-elf.so.1 -o basic_pam_auth /lib/crt1.o /lib/crti.o /usr/local/lib/gcc/i386-portbld-freebsd4.11/4.0.0/crtbegin.o -L/usr/local/lib -L/usr/local/lib/gcc/i386-portbld-freebsd4.11/4.0.0 -L/usr/local/lib/gcc/i386-portbld-freebsd4.11/4.0.0/../../.. -R/usr/local/lib basic_pam_auth.o ../../../lib/.libs/libmiscencoding.a ../../../compat/.libs/libcompat-squid.a -lpam -lstdc++ -lm -lgcc -lc_r -lgcc /usr/local/lib/gcc/i386-portbld-freebsd4.11/4.0.0/crtend.o /lib/crtn.o

Miene Vermutung, dass er -static mit gibt, hat sich leider nich bewahrheitet. Auch sieht das Kommando syntaktisch korrekt aus, erst die Objekte und dann die Bibliotheken. Der Search Path sieht auch okay aus. Name Mangeling kann man wohl auch ausschließen, die Symbolnamen stimmen ja. Wahrscheinlich ist, dass er irgendeine falsche libpam.so aufgreift oder vielleicht noch, dass gcc 4.0 (genauer der zugehörige Linker, aber das ist beim GNU trotz unterschiedlicher Projektnamen im Großen und Ganzen eine Suppe) mit der von gcc 2.9.5 gebauten Bibliothek nicht klarkommt.

Bevor man das nun lange dran rumrätselt, behaupte ich mal, dass du da eh keinen PAM Auth oder sonstige Auth-Helfer brauchst. Also warum den Mist nicht einfach abschalten? Probiere mal: ./configure --disable-auth-basic
 
libtool: link: /usr/local/bin/c++40 -Wall -Wpointer-arith -Wwrite-strings -Wcomments -Wshadow -Woverloaded-virtual -Werror -pipe -D_REENTRANT -g -O2 -I/usr/local/include -g -Wl,-R/usr/local/lib -pthread -o ext_kerberos_ldap_group_acl kerberos_ldap_group.o support_group.o support_netbios.o support_member.o support_krb5.o support_ldap.o support_sasl.o support_resolv.o support_lserver.o support_log.o -L/usr/local/lib ../../../lib/.libs/libmiscencoding.a ../../../compat/.libs/libcompat-squid.a -lsasl2 -L/usr/lib -lgssapi -lkrb5 -lasn1 -lcrypto -lroken -lcrypt -lcom_err -lm -pthread
/lib/libc.so.4: WARNING! setkey(3) not present in the system!
/lib/libc.so.4: warning: this program uses gets(), which is unsafe.
/lib/libc.so.4: warning: mktemp() possibly used unsafely; consider using mkstemp()
/lib/libc.so.4: WARNING! des_setkey(3) not present in the system!
/lib/libc.so.4: WARNING! encrypt(3) not present in the system!
/lib/libc.so.4: warning: tmpnam() possibly used unsafely; consider using mkstemp()
/lib/libc.so.4: warning: this program uses f_prealloc(), which is not recommended.
/lib/libc.so.4: WARNING! des_cipher(3) not present in the system!
/lib/libc.so.4: warning: tempnam() possibly used unsafely; consider using mkstemp()
kerberos_ldap_group.o: In function `main':
/usr/home/wheel/holm/src/squid-3.5.28-20190909-r8e657e8/helpers/external_acl/kerberos_ldap_group/kerberos_ldap_group.cc:431: undefined reference to `__gxx_personality_v0'
collect2: ld returned 1 exit status
*** Error code 1


..den Höllenhund samt LDAP braucht auch keine Sau..also morgen raus. Den Quatsch mit "undefined reference to `__gxx_personality_v0" hatte ich so ähnlich auch schon mal..
Morgen weiter.

Gruß,

Holm
 
Mal ein anderer Lösungsansatz von mir zu diesem Thema. Ich kenne die Umgebung ja nicht aber warum stellst du nicht eine zweite Maschine mit aktuellem OS und Proxy ins Netz und leitest die Ports vom alten FreeBSD 4.11 auf den neuen um? Das sollte doch mit SSH oder stunnel, socat sehr einfach sein.

Oder: Warum stellst du nicht diesen einen PC, der die Anträge abschicken muss temp. in ein anderes Netzt oder gar ohne Proxy?
 
@foxit: Weil das Beides mit da hin fahren und stundenlangem "Basteln" zu tun hat, dafür ist auch in keinem Topf Geld geplant, da Sowieso eine Umstellung erfolgt und ich dann gar nicht mehr da involviert bin.

Der Kürzere Weg wäre herauszufinden was da dem Linker nicht an den Bibliotheken paßt.

Gruß,
Holm
 
Na nicht da hin fahren. Wozu gibts SSH?

Leute, ich frage hier nach der Lösung eines Problems das ich habe, dabei handelt es sich um den Linker Fehler beim Bau einer Software.
Das man das Problem auch mit "Alles neu macht der März und Corona" vertreiben kann weiß ich selber, ich bitte deshalb von dahingehenden Lösungsvorschlägen abzusehen, nicht weil die vielleicht nicht schlau sind, sondern weil sie einfach nicht sachdienlich sind.

Gruß,
Holm
 
Code:
/usr/home/wheel/holm/src/squid-3.5.28-20190909-r8e657e8/helpers/external_acl/kerberos_ldap_group/kerberos_ldap_group.cc:431: undefined reference to `__gxx_personality_v0'

__gxx_personality_v0 wird durch libstdc++.so bereit gestellt. Das Programm wird durch c++4 gelinkt, was wahrscheinlich ein normaler g++ ist und der sollte die Bibliothek automatisch mit linken. Was er entweder nicht tut oder er wählt die falsche Version. Wobei die falsche Version fast sicher weitere Fehler verursachen würde.

Aber trotzdem, hilft es in den Aufruf ein explizites -lstdc++ ans Ende zu operieren? Also etwa so:
Code:
/usr/local/bin/c++40 -Wall -Wpointer-arith -Wwrite-strings -Wcomments -Wshadow -Woverloaded-virtual -Werror -pipe -D_REENTRANT -g -O2 -I/usr/local/include -g -Wl,-R/usr/local/lib -pthread -o ext_kerberos_ldap_group_acl kerberos_ldap_group.o support_group.o support_netbios.o support_member.o support_krb5.o support_ldap.o support_sasl.o support_resolv.o support_lserver.o support_log.o   -L/usr/local/lib ../../../lib/.libs/libmiscencoding.a ../../../compat/.libs/libcompat-squid.a -lsasl2 -L/usr/lib -lgssapi -lkrb5 -lasn1 -lcrypto -lroken -lcrypt -lcom_err -lm -pthread -lstdc++

Wenn nicht, wäre ein komplettes Build-Log, angefangen bei ./configure schön :)
 
Na nicht da hin fahren. Wozu gibts SSH?

Leute, ich frage hier nach der Lösung eines Problems das ich habe, dabei handelt es sich um den Linker Fehler beim Bau einer Software.
Das man das Problem auch mit "Alles neu macht der März und Corona" vertreiben kann weiß ich selber, ich bitte deshalb von dahingehenden Lösungsvorschlägen abzusehen, nicht weil die vielleicht nicht schlau sind, sondern weil sie einfach nicht sachdienlich sind.

Gruß,
Holm
Ich verstehe, dass du Stress hast. Ich verstehe auch, dass Antworten, die nicht auf die Fragen eingehen häufig nicht helfen (wenn sie nicht sachdienlich sind). Ich erkenne aber sehr wohl, dass die Idee, die keine Antwort ist, sachdienlich ist. Ich habe auch weitere Ideen, wie du dein Problem umschiffen kannst. Aber weißt du was? Ich schenke mir die Antwort. Brüte einfach weiter darüber, wie du dein Problem löst, denn dein Weg ist ganz sicher [/Ironie] der einzige Weg, effektiv weiter zu kommen.
 
@Columbo0815:
Sorry, Deine Art ist das Allerletzte was man sich erlauben sollte "Hihi ich weiß was, aber ich sag Dirs nicht!" ..über dieses Alter bin ich etwa seit Kindergartenzeiten hinaus, soviel dazu. Laß bitte stecken. Dein Statement ist ne Beleidigung für jede vernünftige Konversation.

Zum Problem:

libtool: compile: /usr/local/bin/c++40 -DHAVE_CONFIG_H -I../.. -I../../include -I../../lib -I../../src -I../../include -I/usr/include -I/usr/include -I../../libltdl -Wall -Wpointer-arith -Wwrite-strings -Wcomments -Wshadow -Woverloaded-virtual -Werror -pipe -D_REENTRANT -g -O2 -I/usr/local/include -MT ChildConfig.lo -MD -MP -MF .deps/ChildConfig.Tpo -c ChildConfig.cc -o ChildConfig.o >/dev/null 2>&1
depbase=`echo Reply.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`; /bin/sh ../../libtool --tag=CXX --mode=compile /usr/local/bin/c++40 -DHAVE_CONFIG_H -I../.. -I../../include -I../../lib -I../../src -I../../include -I/usr/include -I/usr/include -I../../libltdl -Wall -Wpointer-arith -Wwrite-strings -Wcomments -Wshadow -Woverloaded-virtual -Werror -pipe -D_REENTRANT -g -O2 -I/usr/local/include -MT Reply.lo -MD -MP -MF $depbase.Tpo -c -o Reply.lo Reply.cc && mv -f $depbase.Tpo $depbase.Plo
libtool: compile: /usr/local/bin/c++40 -DHAVE_CONFIG_H -I../.. -I../../include -I../../lib -I../../src -I../../include -I/usr/include -I/usr/include -I../../libltdl -Wall -Wpointer-arith -Wwrite-strings -Wcomments -Wshadow -Woverloaded-virtual -Werror -pipe -D_REENTRANT -g -O2 -I/usr/local/include -MT Reply.lo -MD -MP -MF .deps/Reply.Tpo -c Reply.cc -fPIC -DPIC -o .libs/Reply.o
../../src/helper.h:134: error: base 'HelperServerBase' with only non-default constructor in class without a constructor
../../src/helper.h:147: error: base 'HelperServerBase' with only non-default constructor in class without a constructor
*** Error code 1

Stop in /usr/home/wheel/holm/src/squid-3.5.28-20190909-r8e657e8/src/helper.
*** Error code 1


Forschungen dazu ergaben den Hinweis "Squid 3 benötigt gcc4.x". 4.0 habe ich, höhere Versionen scheint es als Package nicht zu geben.
Ich habe genau diesen Bug mit Google ausgegraben, da versucht Jemand das Ding mit gcc3.45 zu übersetzen, mit gcc4.9 gehts, das hilft mir nur nicht.

Kann und möchte sich das Jemand genauer ansehen ob sich das umschiffen läßt, dann drösele ich Weiteres auf, ansonsten lasse ich das bleiben und gebe Bescheid "geht nicht mit dieser Maschine".

Gruß,

Holm
 
Es ist wirklich schwer dir zu folgen, wenn man immer nur Ausschnitte sieht. Ohne zu wissen, was zwischendurch gemacht wurde. Also:

Code:
../../src/helper.h:134: error: base 'HelperServerBase' with only non-default constructor in class without a constructor
../../src/helper.h:147: error: base 'HelperServerBase' with only non-default constructor in class without a constructor

Die abgeleitete Klasse hat keinen Constructor, daher versucht der Compiler einen Default Constructor zu bauen. Er würde wiederum den Default Constructor der Basisklasse aufrufen. Das geht allerdings nicht, da die Basisklasse über keinen Default Constructor verfügt. Warum das nun mit neueren Compilern geht, kann man nur erraten. Ich würde mal darauf tippen, dass HelperServerBase über einen Konstruktor verfügt, den neuere g++ Versionen vom generierten Default Constructor aus aufrufen können. Also ein Bug im alten C++-Frontend, eine andere Interpretierung des alten C++98-Standards, irgendwas was mit dem TR kam... Egal. Die Lösung ist in der abgeleiteten Klasse einen Default Constructor zu definieren, der den Constructor der Basisklasse aufruft.
 
Ich kann zwar C halbwegs programmieren, C++ aber nicht, (ich mache meist nur Controllerkram) ich habe keine Ahnung von Klassen Construktoren und Default Construktoren..genau deshalb fragte ich auf die Art und Weise. Wenn Du helfen möchtest..walze ich das weiter aus. Mir ist völlig klar das das oben nur wenig nützlich ist.

Gruß,
Holm
 
So also nochmal:
$ configure --disable-auth-basic --disable-auth-digest --disable-auth-negotiate --disable-auth-nt
lm --disable-external-acl-helpers --disable-log-daemon-helpers --disable-kerberos --disable-ipv6 --
disable-auto-locale --disable-snmp --disable-wccp --disable-wccp2 --disable-icap-client


CPP=/usr/local/bin/cpp40
GCC=/usr/local/bin/gcc40
CXXCPP=/usr/local/bin/cpp40
CC=/usr/local/bin/gcc40


Making all in compat
Making all in lib
Making all in rfcnb
Making all in smblib
Making all in libltdl
make all-am
Making all in scripts
Making all in icons
Making all in errors
Making all in doc
Making all in manuals
Making all in release-notes
Making all in helpers
Making all in basic_auth
Making all in digest_auth
Making all in external_acl
Making all in log_daemon
Making all in negotiate_auth
Making all in url_rewrite
Making all in fake
Making all in storeid_rewrite
Making all in file
Making all in src
make all-recursive
Making all in base
Making all in anyp
Making all in helper
depbase=`echo Reply.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`; /bin/sh ../../libtool --tag=CXX --mode=compile /usr/local/bin/c++40 -DHAVE_CON
FIG_H -I../.. -I../../include -I../../lib -I../../src -I../../include -I/usr/include -I/usr/include -I../../libltdl -Wall -Wpointer-a
rith -Wwrite-strings -Wcomments -Wshadow -Woverloaded-virtual -Werror -pipe -D_REENTRANT -g -O2 -I/usr/local/include -MT Reply.lo -MD -MP -MF $
depbase.Tpo -c -o Reply.lo Reply.cc && mv -f $depbase.Tpo $depbase.Plo
libtool: compile: /usr/local/bin/c++40 -DHAVE_CONFIG_H -I../.. -I../../include -I../../lib -I../../src -I../../include -I/usr/include -I/usr/i
nclude -I../../libltdl -Wall -Wpointer-arith -Wwrite-strings -Wcomments -Wshadow -Woverloaded-virtual -Werror -pipe -D_REENTRANT -g -O2 -I/usr/
local/include -MT Reply.lo -MD -MP -MF .deps/Reply.Tpo -c Reply.cc -fPIC -DPIC -o .libs/Reply.o
../../src/helper.h:134: error: base 'HelperServerBase' with only non-default constructor in class without a constructor
../../src/helper.h:147: error: base 'HelperServerBase' with only non-default constructor in class without a constructor
*** Error code 1

Stop in /usr/home/wheel/holm/src/squid-3.5.28-20190909-r8e657e8/src/helper.
*** Error code 1

Stop in /usr/home/wheel/holm/src/squid-3.5.28-20190909-r8e657e8/src.
*** Error code 1

Stop in /usr/home/wheel/holm/src/squid-3.5.28-20190909-r8e657e8/src.
*** Error code 1

Stop in /usr/home/wheel/holm/src/squid-3.5.28-20190909-r8e657e8.

src/helper.h

Zeile 133:
class helper_stateful_server : public HelperServerBase
{
public:
/* MemBuf wqueue; */
/* MemBuf writebuf; */

statefulhelper *parent;
Helper::Request *request;

void *data; /* State data used by the calling routines */

private:
CBDATA_CLASS2(helper_stateful_server);
};

/* helper.c */
void helperOpenServers(helper * hlp);
void helperStatefulOpenServers(statefulhelper * hlp);
void helperSubmit(helper * hlp, const char *buf, HLPCB * callback, void *data);
void helperStatefulSubmit(statefulhelper * hlp, const char *buf, HLPCB * callback, void *data, helper_stateful_server * lastserver);
void helperStats(StoreEntry * sentry, helper * hlp, const char *label = NULL);
void helperStatefulStats(StoreEntry * sentry, statefulhelper * hlp, const char *label = NULL);
void helperShutdown(helper * hlp);
void helperStatefulShutdown(statefulhelper * hlp);
void helperStatefulReleaseServer(helper_stateful_server * srv);
void *helperStatefulServerGetData(helper_stateful_server * srv);

[..]

Gruß,
Holm


Attach files
 
Ich habe da leider keine Zeit für und ich bin in C++ auch nicht mehr so fit, seitdem ich vor allem Go mache. Da müsste ich mich erst wieder einlesen. Ich versuche es mal mit einem Highlight auf Kamikaze, wenn jemand C++ kann, dann er: @Kamikaze

Ansonsten wüsste ich aber auch nicht mehr, was du noch tun könntest. Außer vielleicht einen eigenen GCC zu bauen. Aber ganz ehrlich, das willst du nicht. Das Build-System von dem Monster ist die Steigerung zur Hölle. :(
 
Villeicht noch ne Idee: Wenn du da per remote vill. auf nen ausgedienten Desktop-Rechner mit Windows oder so vorort kommst, da du ja SSH-Zugriff hast, villeicht auf den eben nen proxy (Squid oder so) installieren und Anfragen irgendwie weiterleiten oder so?

In ähnlichen fällen haben wir auch schonmal nen altes Notebook aus der Grabbelkiste mit dem passenden OS fertig gemacht und dann vorort geschickt, das muss dann nur jemand vorort irgendwie ans Netzwerkklemmen, aber mit Skype, Facetime & Co. ja u.U. auch erklärbar.

Ich hab gelesen das Mittel wie Geld & Zeit knapp sind, aber irgendwelchen krams auf nen Vorkriegs FreeBSD zu kompolieren ist ja auch nicht in 2 Minuten erledigt
 
@Yamagi: ..ich kenne den gcc Buildprozeß recht gut..ich war in den 90ern Systemi hier an der Uni in FG, auf unseren HP9000 PA-Risc 1.1 war das Basteln der Toolchain meine Standardaufgabe. Ich habe den gcc auch auf FreeBSD als Crosscompiler in den obskursten Varainten gebaut (68k, 6809 oder H8 aus Zobbygründen). Ich weiß das das ätzend ist. Mich ärgert das auf dem Zielsystem kein alter Portstree mehr drauf ist, ich hätte ggf. da was aufgebohrt.. aber zu der Zeit gabs noch kein SVN ..ich müßte ne alte Ports Package da drauf installieren, Hmm. Evtl. rufe ich morgen mal nach kamikaze.

@CommanderZed: Ja..wenn ich nicht weiter komme ist das eine Möglichkeit, es gibt aber auch noch andere Proxies, evtl. komme ich da was gebacken. Neuerdings basieren aber viele Packages auf Python oder o.Ä...da beißt sich die Katze in den Schwanz.
Morgen habe ich wieder mehr Zeit für das Problem..ich war die Tage dauernd unterwegs..

Gruß,
Holm
 
@Columbo0815:
Sorry, Deine Art ist das Allerletzte was man sich erlauben sollte "Hihi ich weiß was, aber ich sag Dirs nicht!"

Er meinte bestimmt nicht, dass er eine Lösung für dieses konkrete Problem hat. Die Hilfsbereitschaft Aller in Ehren, aber was hier hilft, ist einmal mächtig auf die Fresse fliegen und so einen Blödsinn nie wieder zu veranstalten.

Sind ja nur Kindergeldanträge über ein OS, was seit anderthalb Jahrzehnten gammelt. Wer ist eigtl. verantwortlich für diesen groben Unfug? Wie ist das mit irgendwelchen Richtlinien auch nur annähernd vereinbar?

Kleb dir einen Bart an, setz dich ins Ausland ab und bestreite, je damit was zu tun gehabt zu haben. Das ist mein Tipp.
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben