Bug 15118 - WebKit Gdk fails to build due to icu, under some conditions
Summary: WebKit Gdk fails to build due to icu, under some conditions
Status: RESOLVED WORKSFORME
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Misc. (show other bugs)
Version: 523.x (Safari 3)
Hardware: All Linux
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-08-30 13:13 PDT by Mike Hommey
Modified: 2007-09-17 05:21 PDT (History)
0 users

See Also:


Attachments
Proposed patch (1.99 KB, patch)
2007-09-12 23:28 PDT, Mike Hommey
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Hommey 2007-08-30 13:13:33 PDT
(it would be a good thing to have a WebKit Gdk component)

Latest icu release (3.8) now includes a --enable-weak-threads flag to configure, which makes icu not link against the pthread library. Let's not discuss why it's good or bad. What is important is that it means icu-config doesn't report -lpthread in the ldflags, which it shouldn't have been in the first place, since you don't need to link against the pthread library to *use* icu.

Anyways, the WebKit Gdk build shouldn't rely on icu-config providing the -lpthread necessary to it, it should define it itself.

A trivial fix is to add -lpthread to LIBS for gdk-port in JavaScriptCore/kjs/testkjs.pro and WebKit.pri. But I don't know if that would be okay for something else than Linux...
Comment 1 Mike Hommey 2007-09-12 23:28:54 PDT
Created attachment 16275 [details]
Proposed patch
Comment 2 Adam Roben (:aroben) 2007-09-12 23:31:21 PDT
Comment on attachment 16275 [details]
Proposed patch

The changes and ChangeLogs look sane to me, but I'll leave it to some of the Qt/Gtk guys to review this.
Comment 3 Holger Freyther 2007-09-16 14:19:25 PDT
AFAIK FreeBSD has at least two different threading implementations. Hardcoding -lpthread is something we should not do.

So if ICU is not using POSIX thread symbols, who is using them? The one who has the dependency on pthread should introduce that with --ldflags. So an actual link error would be nice to see what we are talking about.
Comment 4 Mike Hommey 2007-09-16 14:57:10 PDT
(In reply to comment #3)
> AFAIK FreeBSD has at least two different threading implementations. Hardcoding
> -lpthread is something we should not do.
> 
> So if ICU is not using POSIX thread symbols, who is using them? The one who has
> the dependency on pthread should introduce that with --ldflags. So an actual
> link error would be nice to see what we are talking about.

Erm, WebKit does require it in several places, just grep pthread in the code.
Comment 5 Mike Hommey 2007-09-16 15:30:44 PDT
Mmmmmm there might have been something else than the missing -lpthread... The original error message was as below, but it actually doesn't occur anymore here. I suspect a combination of missing -lpthread from icu and some glibc fuckage.
Let's mark this bug worksforme... I'll reopen if I can reproduce again.

> g++ -Wl,--as-needed -o ../testkjs testkjs.o pcre_get.o pcre_refcount.o pcre_ucp_findchar.o pcre_compile.o pcre_globals.o pcre_config.o pcre_version.o pcre_info.o pcre_study.o pcre_exec.o pcre_xclass.o pcre_tables.o pcre_maketables.o pcre_try_flipped.o pcre_ord2utf8.o pcre_fullinfo.o TCSystemAlloc.o Assertions.o HashTable.o FastMalloc.o NP_jsobject.o npruntime.o runtime_array.o runtime.o runtime_method.o runtime_object.o runtime_root.o c_class.o c_instance.o c_runtime.o c_utility.o DateMath.o JSWrapperObject.o PropertyNameArray.o array_object.o bool_object.o collector.o CommonIdentifiers.o Context.o date_object.o debugger.o dtoa.o error_object.o ExecState.o fpconst.o function.o function_object.o identifier.o internal.o interpreter.o JSImmediate.o JSLock.o lexer.o list.o lookup.o math_object.o nodes.o nodes2string.o number_object.o object.o object_object.o operations.o Parser.o property_map.o property_slot.o regexp.o regexp_object.o scope_chain.o string_object.o ustring.o value.o grammar.o     -lm -L/usr/lib -licui18n -licuuc -licudata -lm
> collector.o: In function `currentThreadStackBase':
> /tmp/webkit-0~svn25144/build-gdk/JavaScriptCore/kjs/../../../JavaScriptCore/kjs/collector.cpp:290: undefined reference to `pthread_getattr_np'
> /tmp/webkit-0~svn25144/build-gdk/JavaScriptCore/kjs/../../../JavaScriptCore/kjs/collector.cpp:292: undefined reference to `pthread_attr_getstack'
> /tmp/webkit-0~svn25144/build-gdk/JavaScriptCore/kjs/../../../JavaScriptCore/kjs/collector.cpp:290: undefined reference to `pthread_getattr_np'
> /tmp/webkit-0~svn25144/build-gdk/JavaScriptCore/kjs/../../../JavaScriptCore/kjs/collector.cpp:292: undefined reference to `pthread_attr_getstack'
> collect2: ld returned 1 exit status
> make[2]: *** [../testkjs] Error 1
> make[2]: Leaving directory `/tmp/webkit-0~svn25144/build-gdk/JavaScriptCore/kjs'
> make[1]: *** [sub-JavaScriptCore-kjs-testkjs-pro-make_default-ordered] Error 2
> make[1]: Leaving directory `/tmp/webkit-0~svn25144/build-gdk'
> make: *** [build-gdk-stamp] Error 2
Comment 6 Holger Freyther 2007-09-17 05:21:55 PDT
Okay, if it reoccurs I would probably propose to add gthread-2.0 to the PKG_CONFIG list.