gtkdoc-fixref problem på Gentoo Linux
For nylig, når du opdaterer Gentoo Linux på min amd64 boks jeg fik fejl, når du bygger pakker med doc USE-flag. Alle der ikke pakker blev ved hjælp af gtkdoc værktøj til generering af dokumentation. Intetsteds i nettet var et emne om dette problem. Alle disse pakker ikke svarer til eksempel libbonobo nedenfor. Men mange andre ebuilds, dvs GLib, gedit osv. Der blev også påvirket.
Skriver libbonobo-Bonobo-vedvarende-fil.html for refentry (libbonobo-Bonobo-vedvarende-fil)
Skriver libbonobo-Bonobo-vedvarende-stream.html for refentry (libbonobo-Bonobo-vedvarende-stream)
Skriver libbonobo-Bonobo-vedvarende-client.html for refentry (libbonobo-Bonobo-vedvarende-klient)
Skriver persist.html for kapitel (fortsætter)
Skriver debugging.html for refentry (debugging)
Skriver libbonobo-faq.html for refentry (libbonobo-faq)
Skriver libbonobo-Bonobo-config-database.html for refentry (libbonobo-Bonobo-config-databasen)
Skriver misc.html for kapitel (misc)
Skriver ix01.html til index
At skrive index.html for bog (index)
Skriver index.sgml for bog (index)
Skriver libbonobo.devhelp for bog (index)
Skriver libbonobo.devhelp2 for bog (index)
gtk-doc: Fastsættelse krydshenvisninger
prøv Vitry vish: / usr / bin / vim: Datei oder Verzeichnis nicht gefunden
readline () på lukket filehandle NEWFILE i / usr / bin / gtkdoc-fixxref line 467.
Anvendelse af uinitialiseret værdi i substitution (s / / /) i / usr / bin / gtkdoc-fixxref line 470.
Anvendelse af uinitialiseret værdi i substitution (s / / /) i / usr / bin / gtkdoc-fixxref line 471.
Anvendelse af uinitialiseret værdi i substitution (s / / /) i / usr / bin / gtkdoc-fixxref line 475.
Anvendelse af uinitialiseret værdi i substitution (s / / /) i / usr / bin / gtkdoc-fixxref line 476.
Anvendelse af uinitialiseret værdi i substitution (s / / /) i / usr / bin / gtkdoc-fixxref line 477.
Anvendelse af uinitialiseret værdi i substitution (s / / /) i / usr / bin / gtkdoc-fixxref line 478.
Anvendelse af uinitialiseret værdi i substitution (s / / /) i / usr / bin / gtkdoc-fixxref line 479.
Anvendelse af uinitialiseret værdi i substitution (s / / /) i / usr / bin / gtkdoc-fixxref line 480.
Anvendelse af uinitialiseret værdi i substitution (s / / /) i / usr / bin / gtkdoc-fixxref line 481.
Kan ikke slette html/_temp_src.15046.h.html: Datei oder Verzeichnis nicht gefunden i / usr / bin / gtkdoc-fixxref line 486.
gøre [1]: *** [html-build.stamp] Fehler 2
gøre [1]: Leaving directory `/ var/tmp/portage/gnome-base/libbonobo-2.24.3/work/libbonobo-2.24.3/doc/api '
gøre: *** [all-recursive] Fehler 1
Efter nogle dage for at søge jeg var i stand til at spore problemet ned til den del af gtk-docfixref der bruger vim til at fremhæve. Måske er min gtk-doc version (gtk-doc-1,13-r2) er ikke kompatibel til min vi-version (vim-7.2.303). Selv afinstallere vi til testformål var ikke vellykket, da i det mindste denne version af gtk-docfixref forsøger at bruge vi, selv om det ikke er installeret.
Linie 290 gtkdoc fixref:
hvis ("/ usr / bin / vim" ne "") {
Ændring af denne linie til
hvis ("/ usr / bin / vim" ne "/ usr / bin / vim") {
for at tvinge gtk-docfixref altid at ignorere vi var (midlertidig) løsning for mig. Bagefter var jeg igen i stand til at bygge alle de pakker bruger gtk-doc for dokumentation.
Da jeg ikke finde nogen oplysninger om problemet i nettet er jeg meget usikker på om jeg skulle åbne en fejlrapport for det, eller hvis det kun er et lokalt problem. Så hvis du oplever det samme problem du efterlade en kommentar.
Jürgen





![Valider min RSS-feed [Valid RSS]](http://validator.w3.org/feed/images/valid-rss.png)



































18 August 2010 kl 3:21 am
Jeg oplevede samme problem, hurtig undersøgelse (begrænset til vim takket være dit indlæg) viste, at problemet er i vejen gtk-doc kalder vim (eller deromkring). Vim skaber. Xhtml filer, mens fixxref forventer. Html ext.
Jeg fyldte bug for gtk-doc, lad os se, hvad opstrøms siger:
https://bugzilla.gnome.org/show_bug.cgi?id=627223
14 juli 2011 kl 7:09 am
[...] 元 々 ここ に 書い て あっ た カテゴリー: Linux タグ: コメント (0) トラックバック (0) コメント を どうぞ トラックバック URL [...]