FreeBSD8 buildworld scheitert an gnu/libstdc++

grisu

Active Member
Hallo zusammen,
ich versuch gerade, nach der Anleitung aus dem FreeBSD handbuch, eine Jail zu bauen. Jedoch bricht das ganze schon bei einem
Code:
make buildworld
nach einiger Zeit in Stage 4.2 mit dem Fehler
Code:
cc -O2 -pipe -march=pentium4 -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libstdc++ -I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libstdc++/../../../contrib/gcc -I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/include -I/usr/src/gnu/lib/libstdc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/include -I. -frandom-seed=RepeatabilityConsideredGood -std=gnu99 -fstack-protector  -c /usr/src/gnu/lib/libstdc++/../../../contrib/gcc/debug.c
In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/gcc/debug.c:19:
/usr/src/gnu/lib/libstdc++/../../../contrib/gcc/system.h:418: error: conflicting types for 'strsignal'
/usr/obj/usr/src/tmp/usr/include/string.h:116: error: previous declaration of 'strsignal' was here
/usr/src/gnu/lib/libstdc++/../../../contrib/gcc/debug.c:21:16: error: tm.h: No such file or directory
*** Error code 1

Stop in /usr/src/gnu/lib/libstdc++.
*** Error code 1

Ein "find . -name tm.h" fand die datei auch nicht in /usr/src. weiterhin macht mit der " conflicting types " error da stützig. Vor dem build world habe ich /usr/obj gelehrt und in /usr/src ein make clean gemacht. Die sourcen sind von der 8.0-release frisch von CD eingespielt und mit freebsd-update auf dem neusten stand. Ich hab extra noch CCACHE und -j Options beim make weggelassen, was zu keiner Veränderung führte. Die einzigen sachen die gesetzt sind, sind -O2 -pipe und -march=pentium4 um das ganze ein bischen an meine Maschine anzu passen.

Ich wäre über alle hinweise dankbar.
 
Wird tm.h in /usr/obj gefunden?

%find /usr/obj -name 'tm.h'

Am besten mal alles unter /usr/obj/ löschen und dann buildworld wiederholen.

Was dann noch auffällt - hat aber nichts mit dem Buildfehler zu tun -, die "-O2" Optimierung sollte wohl besser nicht benutzt werden. Zumindest war das durchaus Konsens vor einigen Jahren, weil optimierte Builds wohl eher nicht so erprobt sind wie welche ohne obwohl das in make.conf(5) als supportet gilt.
 
Ich habe nach der Datei in /usr/obj nicht gesucht, jedoch habe ich /usr/obj vor dem build komplett geleert, daran kann es wohl nicht liegen.

Die fehler sind aber, so denke ich, nicht von -O2 abhängig weil die Optimierung sich ja nicht auf fehlende dateien oder falsche redefinitionen auswirkt. (Aber danke für den tipp, falls es dann, wenn es mal baut, probleme gibt, werf ich das -O2 raus)
 
Schade, dass es daran nicht lag. :-(

Richtig, das hatte ich im zweiten Absatz geschrieben, dass es nichts mit dem Buildfehler zu tun hat. Das war nur ein genereller Hinweis.

---

Zeig bitte mal die Ausgabe von

%mount -v

und dann auch gleich mal die /etc/make.conf .
 
Last edited:
Ich weiß zwar nicht was mount damit zu tun haben soll.. aber da

Code:
% mount -v 
/dev/ad4s2a on / (ufs, local, fsid adca7b4b50b570b2)
devfs on /dev (devfs, local, multilabel, fsid 00ff000404000000)
/dev/ad4s7 on /LOCAL/home (ext2fs, local, fsid 7400000001000000)
/dev/ad4s8 on /LOCAL/data3 (ext2fs, local, fsid 7500000001000000)
/dev/ad6s1 on /LOCAL/data1 (ext2fs, local, fsid 6d00000001000000)
/dev/ad6s2 on /LOCAL/data2 (ext2fs, local, fsid 6e00000001000000)
/dev/ad4s5 on /LOCAL/linux (ext2fs, local, fsid 7200000001000000)
/dev/ad4s1 on /LOCAL/linux_boot (ext2fs, local, fsid 6a00000001000000)
linprocfs on /usr/compat/linux/proc (linprocfs, local, fsid 01ff000808000000)
ritter:/home on /net/ritter_home (nfs, fsid 02ff000707000000)


und die make.conf
Code:
OVERRIDE_LINUX_BASE_PORT=f10
OVERRIDE_LINUX_NONBASE_PORTS=f10
PERL_VERSION=5.10.1
CPUTYPE?=pentium4
CFLAGS= -O2 -pipe
CXXFLAGS= -O2 -pipe

CUPS_OVERWRITE_BASE=yes
NO_LPR=yes
WITH_CUPS=yes


# /usr/local/etc/buildflags.conf
BUILDFLAGS=     /usr/local/share/bsdadminscripts/buildflags.mk
.if exists(${BUILDFLAGS})
.include "${BUILDFLAGS}"
.endif

Die buildflags.conf stellt für den Pfad /usr/src nur das -DNOCLEAN ein mehr nicht.
 
Wenn mehrere Filesysteme benutzt werden und die mit einschränkenden Attributen wie z.B. 'noexec' montiert werden, dann kann es zu Übersetzungsproblemen kommen. Aber das ist bei dir nicht der Fall.
 
der buildworld/buildkernel betreffende teil der buildflags.conf
Code:
# ---< configure buildworld/buildkernel >--------------------------------------
/usr/src | /usr/src/*{                                                         
#       USE_DISTCC                                                             
#       USE_CCACHE                                                             
#       THREADS=                3                                              
#       THREADS= 1                                                             
        # Don't clean.                                                         
        NO_CLEAN                                                               
}                                                                              
# -----------------------------------------------------------------------------

btw... ein buildkernel und install kernel geht.

--- EDIT ---
ich habe jetzt mal die sourcen nicht von der CD oder aus dem FTP-release Verzeichnis genommen, sondern von svn.freebsd.org/base/release/8.0.0 ausgecheckt, welche ja an sich die gleichen sein sollten, bis auf wichtige updates. Jedoch scheint jetzt der ganze spaß durchzulaufen, es ist im moment noch dabei, jedenfalls wurden in /usr/obj einige dateien tm.h erstellt. Das interessante wäre nun zu wissen, wieso die release sourcen, wie sie auf CD/DVD ausgeliefert sind, diese nicht erstellen, bzw. freebsd-update dieses fehler in den sourcen nicht auf den neusten stand bringt.
 
Last edited:
Das wäre irgendwann der nächste Tipp gewesen, die Sourcen aus dem Repository auszuchecken.

Gib bitte mal deine URL an, von der du das CD/DVD-ISO bezogen hast.
 
Moin grisu,

Die sourcen sind von der 8.0-release frisch von CD eingespielt und mit freebsd-update auf dem neusten stand. Ich hab extra noch CCACHE und -j Options beim make weggelassen, was zu keiner Veränderung führte. Die einzigen sachen die gesetzt sind, sind -O2 -pipe und -march=pentium4 um das ganze ein bischen an meine Maschine anzu passen.

Ich wäre über alle hinweise dankbar.

Laut manpage zu freebsd-update(8) werden NUR die Binaries aktualisiert, aber nicht die Sourcen:
The freebsd-update tool is used to fetch, install, and rollback binary updates to the FreeBSD base system.
Außerdem sollten die Sourcen IMMER zum Kernel passen, damit es nicht zu Schwierigkeiten kommen kann. Daher hat sich - aus meiner Erfahrung! - folgender Weg immer als praktikabel erwiesen: Aktualisieren wie im Handbuch beschrieben mit csup und make-Klamotte.

So long
 
Code:
CFLAGS= -O2 -pipe
CXXFLAGS= -O2 -pipe
Solltest du dringenst weglassen. Du schießt dir gerade selbst den Hintern weg. Es mag funktionieren, muss es aber nicht! Grundsätzlich hat FreeBSD für jedes Modul in /usr/src und auch fast jeden Port eigene CFLAGS und CXXFLAGS, welche von den Entwicklern als sicher betrachtet werden. Die überschreibst du hier lustig, was zu üblen Nebenwirkungen führen kann. Ein Beispiel: Wird die Boot-Kette in /usr/src/sys/boot mit zu hohen Optimierungen gebaut, landet sie im undefinierten Bereich. Auf einigen Rechnern wird sie nicht mehr funktionieren, du kannst dein System nicht mehr starten. Das der Fehler an den CFLAGS liegt, ist dann alles andere als leicht zu erkennen.
 
freebsd-update(8) aktualisiert auch den Coe in /usr/src, wenn er vorhanden ist. Ich würde aber dennoch zu csup(1) raten. Erscheint mir vom Gefühl her irgendwie sicherer.
 
Code:
CFLAGS= -O2 -pipe
CXXFLAGS= -O2 -pipe
Solltest du dringenst weglassen. Du schießt dir gerade selbst den Hintern weg. Es mag funktionieren, muss es aber nicht! Grundsätzlich hat FreeBSD für jedes Modul in /usr/src und auch fast jeden Port eigene CFLAGS und CXXFLAGS, welche von den Entwicklern als sicher betrachtet werden. Die überschreibst du hier lustig, was zu üblen Nebenwirkungen führen kann. Ein Beispiel: Wird die Boot-Kette in /usr/src/sys/boot mit zu hohen Optimierungen gebaut, landet sie im undefinierten Bereich. Auf einigen Rechnern wird sie nicht mehr funktionieren, du kannst dein System nicht mehr starten. Das der Fehler an den CFLAGS liegt, ist dann alles andere als leicht zu erkennen.

Ja das mit den CFLAGS wurde mir ja gesagt, aber meien Programmierkenntnisse sagen mir halt, dass solche Fehler nichts mit der Optimierung zu tun haben. Ich entferne da mal die FLAGSl, wenn es mal durchbaut und untersuche mal den unterschied zwischen den SVN und den "beigelegten" Sourcen von der DVD
 
Ja das mit den CFLAGS wurde mir ja gesagt, aber meien Programmierkenntnisse sagen mir halt, dass solche Fehler nichts mit der Optimierung zu tun haben.

Wenn der Parser oder ein entsprechedes Teilprogramm, was zum bauen benutzt wird, fehlerhaft gebaut ist, dann kann es sehr wohl zu solchen Fehlern aufgrund der Optimierungen kommen.

Nicht umsonst überschreiben Source-Distries von Linux wie Gentoo auch gerne mal CFLAGS um den Nutzer zu "schützen". Das macht FreeBSD nicht.

Bugfrei ist GCC ja nun auch nicht...
 
Bug frei nicht, dass stimmt schon. Mir sind da auch schon einige schräge sachen unter gekommen was die optimierung so kann, gerade im bezug auf flasch geschriebene schleifen und rekursionenen.

Ich hab das ganze jetzt mal ohne -O2 gebaut und es passiert mit den DVD sourcen immer noch.

Jedoch mit den SVN sourcen geht es, damit bin ich jetzt erstmal zufrieden ( auch wenn der rest nach wie vor komisch ist)


---edit---
nachtrag zu der CFLAGS debatte. Auf nicht ARM maschinen fügt die /usr/src/share/mk/sys.mk z.T. die -O2 -pipe den CFlags hinzu.
 
Last edited:
Gib bitte mal deine URL an, von der du das CD/DVD-ISO bezogen hast.
*push*

Oder kopier von dem Medium das Verzeichnis 8.0-RELEASE/src (sind nur ~100MB) auf den ftp -Server

%ftp -P79 anonymous@194.116.186.213

Mich interessiert auch was das Problem bei dem Paket ist.
 
Last edited:
Back
Top