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)
You're missing a link against libedit.
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?
Created attachment 239185 [details] Patch Worked for me, with the addition of @WEBKITGTK_API_MAJOR_VERSION@. Here's the patch.
Created attachment 239186 [details] Patch
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?
Created attachment 239350 [details] Patch for 2.4.x stable branch
Here's an updated patch with changelog.
Would it be possible to get this reviewed for 2.4.8?
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?
(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.
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.
Created attachment 243919 [details] Patch
Anyone know why -ledit would fail the "mac" EWS build? Do I need to check for PORT=GTK as well?
Comment on attachment 239350 [details] Patch for 2.4.x stable branch Committed to 2.4 branch, thanks. <http://trac.webkit.org/changeset/177899>
(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?
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.
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.
(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.
libedit is a BSD-licensed replacement for the GNU readline library. I assume JSC uses it in its REPL.
Comment on attachment 243919 [details] Patch Clearing flags on attachment: 243919 Committed r190857: <http://trac.webkit.org/changeset/190857>
All reviewed patches have been landed. Closing bug.