# webkit Kompilierung hängt

## pablo_supertux

Hi

Nach dem letzten world update, bekam ich Meldung, ich sollte emerge @preserved-rebuild ausführen. In der Liste befindet sich =net-libs/webkit-gtk-2.0.4:3/25.

Schon 3 Mal ist es mir aufgefallen, dass das Kompilieren "hängt". Ich komme immer zur Stelle

```

g-ir-scanner: link: /bin/sh ./libtool --mode=link --tag=CC x86_64-pc-linux-gnu-gcc -o /var/tmp/portage/net-libs/webkit-gtk-2.0.4/work/webkitgtk-2.0.4/tmp-introspectCZQvm7/WebKit2-3.0 -export-dynamic -O2 -pipe -std=c99 -Wl,-O1 -Wl,--as-needed -Wl,--no-keep-memory /var/tmp/portage/net-libs/webkit-gtk-2.0.4/work/webkitgtk-2.0.4/tmp-introspectCZQvm7/WebKit2-3.0.o -L. -lwebkit2gtk-3.0 -ljavascriptcoregtk-3.0 -Wl,--export-dynamic -lgmodule-2.0 -pthread -lrt -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lsoup-2.4 -lgio-2.0 -lgobject-2.0 -lglib-2.0

libtool: link: x86_64-pc-linux-gnu-gcc -o /var/tmp/portage/net-libs/webkit-gtk-2.0.4/work/webkitgtk-2.0.4/tmp-introspectCZQvm7/.libs/WebKit2-3.0 -O2 -pipe -std=c99 -Wl,-O1 -Wl,--no-keep-memory /var/tmp/portage/net-libs/webkit-gtk-2.0.4/work/webkitgtk-2.0.4/tmp-introspectCZQvm7/WebKit2-3.0.o -Wl,--export-dynamic -pthread -Wl,--export-dynamic  -Wl,--as-needed -L. /var/tmp/portage/net-libs/webkit-gtk-2.0.4/work/webkitgtk-2.0.4/.libs/libwebkit2gtk-3.0.so -L/usr/lib64 -lenchant -lharfbuzz-icu -lharfbuzz -lgailutil-3 -lgeoclue -ldbus-glib-1 -ldbus-1 -lgstapp-1.0 -lgstaudio-1.0 -lgstfft-1.0 -lgstpbutils-1.0 -lgstvideo-1.0 -lgstbase-1.0 -lgstreamer-1.0 -ljpeg -lxslt -lxml2 -lGL -ldl -lpangoft2-1.0 -lfreetype -lfontconfig -lpng16 -lsqlite3 -lwebp -lXrender -lXcomposite -lXdamage -lXfixes -lXt -lX11 -lz /var/tmp/portage/net-libs/webkit-gtk-2.0.4/work/webkitgtk-2.0.4/.libs/libjavascriptcoregtk-3.0.so -lpthread -licui18n -licuuc -licudata -lgthread-2.0 -lgmodule-2.0 -lrt -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lsoup-2.4 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -pthread

(process:21613): GLib-GObject-CRITICAL **: g_object_class_install_property: assertion `class->set_property != NULL' failed

Source/WebKit2/UIProcess/API/gtk/WebKitJavascriptResult.cpp:91: Warning: WebKit2: webkit_javascript_result_get_global_context: return value: Unresolved type: 'JSGlobalContextRef'

Source/WebKit2/UIProcess/API/gtk/WebKitJavascriptResult.cpp:105: Warning: WebKit2: webkit_javascript_result_get_value: return value: Unresolved type: 'JSValueRef'

Source/WebKit2/UIProcess/API/gtk/WebKitWebView.cpp:2477: Warning: WebKit2: webkit_web_view_get_javascript_global_context: return value: Unresolved type: 'JSGlobalContextRef'

DerivedSources/webkitdom/WebKitDOMCustom.h:31: Warning: WebKit2: webkit_dom_blob_webkit_slice: return value: Missing (transfer) annotation

DerivedSources/webkitdom/WebKitDOMCustom.h:34: Warning: WebKit2: webkit_dom_html_element_get_class_list: return value: Missing (transfer) annotation

DerivedSources/webkitdom/WebKitDOMEventTarget.h:61: Warning: WebKit2: webkit_dom_event_target_add_event_listener: argument handler: Missing (scope) annotation for callback without GDestroyNotify (valid: call, async)

DerivedSources/webkitdom/WebKitDOMEventTarget.h:67: Warning: WebKit2: webkit_dom_event_target_remove_event_listener: argument handler: Missing (scope) annotation for callback without GDestroyNotify (valid: call, async)

DerivedSources/webkitdom/WebKitDOMCustom.h:39: Warning: WebKit2: webkit_dom_webkit_named_flow_get_content_nodes: return value: Missing (transfer) annotation

DerivedSources/webkitdom/WebKitDOMCustom.h:40: Warning: WebKit2: webkit_dom_webkit_named_flow_get_regions_by_content_node: return value: Missing (transfer) annotation

/usr/bin/g-ir-compiler --includedir ./Source/WebKit2 --includedir . WebKit2-3.0.gir -o WebKit2-3.0.typelib

```

und beim g-ir-compiler bleibt es einfach stehen.  Ich hab schon bis 3 Stunden gewartet, bis ich mit ctrl+c den emerge Prozess abgebrochen habe. Jedes Mal ist es dasselbe. Das komische ist, ein g-ir-compiler Prozess scheint nicht zu laufen (nur g-ir-scanner, siehe htops Auszug) oder ist die letzte Zeile nur Output von g-ir-scanner?

htop:

```

make -j9

  make all-am

    /usr/bin/python2.7 /usr/bin/g-ir-scanner -v --warn-all ...

      /var/tmp/portage/net-libs/webkit-gtk-2.0.4./work/webkitgtk-2.0.4/tmp-introspected5x7HN/.libs/WebKit-3.0 ...

        /var/tmp/portage/net-libs/webkit-gtk-2.0.4./work/webkitgtk-2.0.4/tmp-introspected5x7HN/.libs/WebKit-3.0 ...

        /var/tmp/portage/net-libs/webkit-gtk-2.0.4./work/webkitgtk-2.0.4/tmp-introspected5x7HN/.libs/WebKit-3.0 ...

        /var/tmp/portage/net-libs/webkit-gtk-2.0.4./work/webkitgtk-2.0.4/tmp-introspected5x7HN/.libs/WebKit-3.0 ...

```

wenn ich aber mache

```

cd /var/tmp/portage/net-libs/webkit-gtk-2.0.4/work/webkitgtk-2.0.4

make -j9 && echo "yeah"

```

beomme ich dasselbe Output und yeah am Ende. Mit emerge scheint es aber für immer zu hängen...

Weiß jemand, was hier passiert? Hat jemand eine ähnliche Erfahrung?

----------

## Josef.95

Klingt nach https://forums.gentoo.org/viewtopic-t-983012.html  :Smile: 

----------

## schmidicom

Unabhängig davon ob nVidia hier wieder mal mit Instabilität um sich schmeißt kannst du es ja mal mit FEATURES="-sandbox -usersandbox" vor dem emerge versuchen. Wenn es klappt würde es zumindest erklären warum ein make außerhalb von emerge funktioniert und innerhalb von emerge nicht mehr.

----------

## Josef.95

FEATURES="-sandbox" würde ich vermeiden - wenn es mit der sandbox nicht geht ist es ein Bug.

----------

## schmidicom

Ja und?

Selbst wenn es ein Bug ist hilft ihm das im Moment auch nicht wirklich weiter denn ohne dieses Paket dürfte einiges nicht mehr funktionieren. Und der Bug kann nachträglich immer noch gefixt werden wenn das Update durch ist.

----------

## Josef.95

@schmidicom

Der Bug ist doch bekannt, und eine Lösung steht auch bereit - ich sehe keinen Grund sich Zeugs ohne Sandbox direkt ins System hauen zu müssen.

Die Sandbox zu deaktivieren ist immer ne schlechte Idee.

Und ne, webkit-gtk ist idR nicht wirklich wichtig (ich habs nicht mal installiert)

zumal es dank preserve-libs Feature auch noch alles funktionieren sollte.

Fazit: Die sandbox zu deaktivieren sollte nicht wirklich nötig sein.

----------

## pablo_supertux

Ich habe es gelöst, indem ich:

```

cd /var/tmp/portage/net-libs/webkit-gtk-2.0.4/work/webkitgtk-2.0.4/

make

ebuild /usr/portage/net-libs/webkit-gtk/webkit-gtk-2.0.4.ebuild compile

ebuild /usr/portage/net-libs/webkit-gtk/webkit-gtk-2.0.4.ebuild install

ebuild /usr/portage/net-libs/webkit-gtk/webkit-gtk-2.0.4.ebuild postinst

emerge @preserved-rebuild

```

ebuild compile lief ohne Probleme. Danach lief emerge @preserved-rebuild auch ohne Probleme, keine Ahnung, wo das nur Zufall war oder das Problem tatsächlich gelöst hat

----------

## schmidicom

@Josef.95

Ich vermute mal das webkit-gtk als Abhängigkeit von Gnome (oder einem anderem DE mit GTK-Basis) dazugekommen ist und dadurch schon als relevant/wichtig angesehen werden kann, zumindest dann wenn man vorhat das jeweilige Programm zu benutzen das davon Gebrauch macht. Unter KDE wäre das dann wohl "kde-misc/kwebkitpart" mit seiner Abhängigkeit zu qtwebkit, welches dann ja auch "wichtig" wäre.

Aber Egal, ich hallte das Abschalten der sandbox in solchen fällen für akzeptabel vor allem wem im build-Verzeichnis bereits ein make ohne sandbox ausprobiert wurde.

 *pablo_supertux wrote:*   

> ebuild compile lief ohne Probleme. Danach lief emerge @preserved-rebuild auch ohne Probleme, keine Ahnung, wo das nur Zufall war oder das Problem tatsächlich gelöst hat

 

Wird bei einem "ebuild compile" das compilieren auch in einer sandbox ausgeführt?

----------

## musv

 *Josef.95 wrote:*   

> Und ne, webkit-gtk ist idR nicht wirklich wichtig 

 

Beim mir in den Use-Flags steht u.a. 

```
-gnome
```

Trotzdem ist webkit-gtk ziemlich begehrt im System:

```
equery d webkit-gtk

dev-java/swt-3.8.2 (>=net-libs/webkit-gtk-1.2:2)

dev-java/swt-4.2-r2 (>=net-libs/webkit-gtk-1.2:2)

dev-util/devhelp-3.10.2 (>=net-libs/webkit-gtk-2:3)

gnome-extra/yelp-3.10.2 (>=net-libs/webkit-gtk-1.3.10:3)

gnome-extra/zenity-3.8.0-r2 (>=net-libs/webkit-gtk-1.4.0:3)

mail-client/claws-mail-3.9.3 (>=net-libs/webkit-gtk-1.0:2)

media-gfx/gimp-2.8.10-r1 (>=net-libs/webkit-gtk-1.6.1:2)

net-libs/libproxy-0.4.11-r1 (>=net-libs/webkit-gtk-1.6:3)

net-news/liferea-1.10.3 (>=net-libs/webkit-gtk-1.6.1:3)

x11-libs/wxGTK-3.0.0.0 (net-libs/webkit-gtk:2)
```

Und seit der 2.x ist es wenigstens brauchbar compilierfähig. Die 1.8-er Versionen (r200 und r300) wurden immer beide gebraucht und ließen sich bei mir nur mit MAKEOPTS="-j1" bauen, was die Compilierzeit über die von Libreoffice hat steigen lassen. Deswegen hab ich die Dinger noch so gut in Erinnerung.   :Twisted Evil: 

----------

## Josef.95

Sorry, meine Aussage bezüglich "Und ne, webkit-gtk ist idR nicht wirklich wichtig"

bezog sich eher auf das von pablo_supertux genannte @preserved-rebuild (war meinerseits ein wenig unglücklich formuliert).

Das schöne am preserve-libs Feature ist ja das die alten libs nicht einfach entfernt werden sofern noch Pakete ohne rebuild die alten libs benötigen - sprich das noch installierte webkit-gtk sollte zunächst auch ohne rebuild noch funktionsfähig sein.

Eventuell noch interessant zu dem Thema (auch wenn schon uralt) --> http://blog.scherbaum.info/2008/08/24/neues-in-portage-22-preserved-libs/

@musv

Deine "equery d webkit-gtk" Ausgabe irritiert mich, denn viele der aufgelisteten Paketversionen haben ein webkit USE-Flag womit bei diesen der webkit Support dann optional ist - das sollte  in der equery d Ausgabe auch so aufgelistet werden.

Beispiel (von einem anderen System) 

```
equery d webkit-gtk 

 * These packages depend on webkit-gtk:

media-gfx/gimp-2.8.10-r1 (webkit ? >=net-libs/webkit-gtk-1.6.1:2)

net-libs/libproxy-0.4.11-r1 (webkit ? >=net-libs/webkit-gtk-1.6:3)

x11-libs/wxGTK-3.0.0.0 (webkit ? net-libs/webkit-gtk:2)
```

----------

