Bug 127059 – [GTK] Fails to link JavaScriptCore in OS X, missing symbols add_history and readline

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Jeremy Huddleston Sequoia]

darwin/gtk2/x11, webkit-gtk-2.3.4 fails to link.  2.3.3 was ok:

libtool: link: /usr/bin/clang -arch x86_64 -ansi -fno-strict-aliasing -pipe -Os -ftemplate-depth=256 -arch x86_64 -pthread -std=c99 -Qunused-arguments -O2 -Wl,-headerpad_max_install_names -arch x86_64 -Wl,--no-demangle -o Programs/.libs/minidom Source/JavaScriptCore/API/tests/Programs_minidom-JSNode.o Source/JavaScriptCore/API/tests/Programs_minidom-JSNodeList.o Source/JavaScriptCore/API/tests/Programs_minidom-Node.o Source/JavaScriptCore/API/tests/Programs_minidom-NodeList.o Source/JavaScriptCore/API/tests/Programs_minidom-minidom.o  -L/opt/local/lib ./.libs/libjavascriptcoregtk-1.0.dylib -lz -lgmodule-2.0 -lgthread-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lintl -licui18n -licuuc -licudata -lm -lpthread -lstdc++ -pthread
libtool: link: /usr/bin/clang++ -fno-strict-aliasing -fno-rtti -I/opt/local/include -pipe -Os -ftemplate-depth=256 -Wno-c++11-extensions -arch x86_64 -stdlib=libc++ -pthread -std=c++11 -Wno-c++11-compat -Qunused-arguments -O2 -Wl,-headerpad_max_install_names -arch x86_64 -Wl,--no-demangle -o Programs/.libs/jsc-1 Source/JavaScriptCore/Programs_jsc_1-jsc.o  -L/opt/local/lib ./.libs/libjavascriptcoregtk-1.0.dylib -lpthread -lz -lgmodule-2.0 -lgthread-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lintl -licui18n -licuuc -licudata -pthread
Undefined symbols for architecture x86_64:
  "_add_history", referenced from:
      __Z7jscmainiPPc in Programs_jsc_1-jsc.o
  "_readline", referenced from:
      __Z7jscmainiPPc in Programs_jsc_1-jsc.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

[Jeremy Huddleston Sequoia]

You're missing a link against libedit.

[Alberto Garcia]

Ok, I see the problem, this was r161853.

It's probably enough with something like this in Source/JavaScriptCore/GNUmakefile.am

if OS_DARWIN
Programs_jsc_LDADD += -ledit
endif

Can you give it a try and upload the patch if it works?

[Philip Chimento]

Created attachment 239185 [details]
Patch

Worked for me, with the addition of @WEBKITGTK_API_MAJOR_VERSION@. Here's the patch.

[Philip Chimento]

Created attachment 239186 [details]
Patch

[Philip Chimento]

I'm guessing the patch doesn't apply to trunk because trunk doesn't use automake anymore :-/

Can it be committed to the 2.4 stable branch though?

[Philip Chimento]

Created attachment 239350 [details]
Patch for 2.4.x stable branch

[Philip Chimento]

Here's an updated patch with changelog.

[Philip Chimento]

Would it be possible to get this reviewed for 2.4.8?

[Alberto Garcia]

I believe the patch is fine, I just added it to the list of changes
to merge for 2.4.8:

http://trac.webkit.org/wiki/WebKitGTK/2.4.x

Carlos will take care of it before the next release.

Isn't webkitgtk 2.6 affected by this problem?

[Philip Chimento]

(In reply to comment #9)
> I believe the patch is fine, I just added it to the list of changes
> to merge for 2.4.8:
> 
> http://trac.webkit.org/wiki/WebKitGTK/2.4.x
> 
> Carlos will take care of it before the next release.
> 
> Isn't webkitgtk 2.6 affected by this problem?

This only affects the Automake build system, I think, which is defunct in 2.6.

[Philip Chimento]

I was wrong; -ledit is also missing in cmake in 2.6. I'll add a patch for that as well.

Thanks for the review for 2.4.8, by the way.

[Philip Chimento]

Created attachment 243919 [details]
Patch

[Philip Chimento]

Anyone know why -ledit would fail the "mac" EWS build? Do I need to check for PORT=GTK as well?

[Carlos Garcia Campos]

Comment on attachment 239350 [details]
Patch for 2.4.x stable branch

Committed to 2.4 branch, thanks. <http://trac.webkit.org/changeset/177899>

[Carlos Garcia Campos]

(In reply to comment #9)
> I believe the patch is fine, I just added it to the list of changes
> to merge for 2.4.8:
> 
> http://trac.webkit.org/wiki/WebKitGTK/2.4.x
> 
> Carlos will take care of it before the next release.
> 
> Isn't webkitgtk 2.6 affected by this problem?

Do we even support building wk2 in MAC OSX?

[Philip Chimento]

I don't know if you support it as such, but I have recently succeeded in building WebKitGTK 2.6.4 on OSX and would like to contribute all the fixes that I made.

[Philippe Normand]

The Mac EWS failure seems unrelated with this patch. Moreover the Mac port doesn't use CMake so I think this is safe for landing.

[Alex Christensen]

(In reply to comment #17)
> The Mac EWS failure seems unrelated with this patch. 
I agree.
> Moreover the Mac port doesn't use CMake so I think this is safe for landing.
I think this is safe for landing, but I would have to change it to (WTF_OS_MAC_OS_X && GTK) or whatever the CMake equivalent is once I get back to getting CMake working on Mac for the non-GTK Mac port, which I assume does not use libedit (I'm not familiar with libedit).  I'm ok with this patch with or without this change.

[Philip Chimento]

libedit is a BSD-licensed replacement for the GNU readline library. I assume JSC uses it in its REPL.

[WebKit Commit Bot]

Comment on attachment 243919 [details]
Patch

Clearing flags on attachment: 243919

Committed r190857: <http://trac.webkit.org/changeset/190857>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.