In my environment (10.3-RELEASE-p19/amd64), www/webkit2-gtk3-2.14.6 fails to build unless /usr/local/bin is placed before /usr/bin in $PATH. When /usr/bin precedes, the build process stops as below: /usr/bin/ld:../../lib/libWTFGTK.a: file format not recognized; treating as linker script /usr/bin/ld:../../lib/libWTFGTK.a:1: syntax error
It seems webkit used /usr/local/bin/ar to create static libraries but used /usr/bin/ld to link them. Did you build it with DEBUG enabled?
This happens to me as well. DEBUG is off. I do have the binutils port installed. [1] /usr/local/bin/clang++40 is calling whichever ld(1) is in your path (instead of the /usr/local/bin/ld installed from the binutils port). /usr/local/bin/ar crT ../../../lib/libWTFGTK.a CMakeFiles/WTF.dir/Assertions.cpp.o ... /usr/local/bin/ranlib ../../../lib/libWTFGTK.a . . . cd /usr/ports/www/webkit2-gtk3/work/webkitgtk-2.14.6/Source/JavaScriptCore && /usr/local/bin/cmake -E cmake_link_script CMakeFiles/LLIntOffsetsExtractor.dir/link.txt --verbose=1 /usr/local/bin/clang++40 -O2 -pipe -DNDEBUG -fstack-protector -fno-strict-aliasing -std=c++1y -Qunused-arguments -O2 -pipe -DNDEBUG -fstack-protector -fno-strict-aliasing -fno-exceptions -fno-strict-aliasing -fno-rtti -L/usr/local/lib -fstack-protector MakeFiles/LLIntOffsetsExtractor.dir/llint/LLIntOffsetsExtractor.cpp.o -o ../../bin/LLIntOffsetsExtractor -Wl,-rpath,/usr/local/lib ../../lib/libWTFGTK.a ../../lib/libbmalloc.a /usr/local/lib/libicudata.so /usr/local/lib/libicui18n.so /usr/local/lib/libicuuc.so /usr/local/lib/libgio-2.0.so /usr/local/lib/libgobject-2.0.so /usr/local/lib/libglib-2.0.so -lpthread -lz /usr/bin/ld:../../lib/libWTFGTK.a: file format not recognized; treating as linker script /usr/bin/ld:../../lib/libWTFGTK.a:1: syntax error This was observed on 10-stable. The previous version that I have installed (webkit2-gtk3-2.8.5_10) was built on my system with /usr/bin/cc (base clang 3.4). After webkit2-gtk3 was updated to include USES=compiler:c++14-lang, it is now using clang40 from ports. One possible fix: pass -B${LOCALBASE}/bin in LDFLAGS (like when DEBUG is on). But it's not clear to me why the non-DEBUG build is using ports binutils tools yet. Note this was also reported in Aug 2016 with clang38 & webkit2-gtk3-2.8.5_5 (no posted resolution): https://lists.freebsd.org/pipermail/freebsd-ports/2016-August/104246.html [1] CMAKE_ARGS is: % make -V CMAKE_ARGS -DPORT=GTK -DENABLE_WAYLAND_TARGET:BOOL=OFF -DENABLE_MINIBROWSER:BOOL=ON -DENABLE_GLES2:BOOL=OFF -DENABLE_ACCELERATED_2D_CANVAS=ON -DUSE_LD_GOLD:BOOL=OFF -DENABLE_WEBKIT:BOOL=OFF -DCMAKE_BUILD_TYPE:STRING=Release -DENABLE_GEOLOCATION:BOOL=true -DCMAKE_C_COMPILER:STRING="/usr/local/bin/clang40" -DCMAKE_CXX_COMPILER:STRING="/usr/local/bin/clang++40" -DCMAKE_C_FLAGS:STRING="-O2 -pipe -DNDEBUG -fstack-protector -fno-strict-aliasing" -DCMAKE_C_FLAGS_DEBUG:STRING="-O2 -pipe -DNDEBUG -fstack-protector -fno-strict-aliasing" -DCMAKE_C_FLAGS_RELEASE:STRING="-O2 -pipe -DNDEBUG -fstack-protector -fno-strict-aliasing" -DCMAKE_CXX_FLAGS:STRING="-O2 -pipe -DNDEBUG -fstack-protector -fno-strict-aliasing " -DCMAKE_CXX_FLAGS_DEBUG:STRING="-O2 -pipe -DNDEBUG -fstack-protector -fno-strict-aliasing " -DCMAKE_CXX_FLAGS_RELEASE:STRING="-O2 -pipe -DNDEBUG -fstack-protector -fno-strict-aliasing " -DCMAKE_EXE_LINKER_FLAGS:STRING=" -L/usr/local/lib -fstack-protector" -DCMAKE_MODULE_LINKER_FLAGS:STRING=" -L/usr/local/lib -fstack-protector" -DCMAKE_SHARED_LINKER_FLAGS:STRING=" -L/usr/local/lib -fstack-protector" -DCMAKE_INSTALL_PREFIX:PATH="/usr/local" -DCMAKE_BUILD_TYPE:STRING="Release" -DTHREADS_HAVE_PTHREAD_ARG:BOOL=YES -DCMAKE_INSTALL_RPATH_USE_LINK_PATH=YES -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DPython_ADDITIONAL_VERSIONS=2.7
work/webkitgtk-2.14.6/CMakeFiles/3.8.0/CMakeCCompiler.cmake and work/webkitgtk-2.14.6/CMakeFiles/3.8.0/CMakeCXXCompiler.cmake have: set(CMAKE_AR "/usr/local/bin/ar") set(CMAKE_RANLIB "/usr/local/bin/ranlib") set(CMAKE_LINKER "/usr/local/bin/ld") CMakeCache.txt has: % grep usr.local.bin webkitgtk-2.14.6/CMakeCache.txt # It was generated by CMake: /usr/local/bin/cmake BISON_EXECUTABLE:FILEPATH=/usr/local/bin/bison CMAKE_AR:FILEPATH=/usr/local/bin/ar CMAKE_CXX_COMPILER:STRING=/usr/local/bin/clang++40 CMAKE_C_COMPILER:STRING=/usr/local/bin/clang40 CMAKE_LINKER:FILEPATH=/usr/local/bin/ld CMAKE_MAKE_PROGRAM:FILEPATH=/usr/local/bin/gmake CMAKE_NM:FILEPATH=/usr/local/bin/nm CMAKE_OBJCOPY:FILEPATH=/usr/local/bin/objcopy CMAKE_OBJDUMP:FILEPATH=/usr/local/bin/objdump CMAKE_RANLIB:FILEPATH=/usr/local/bin/ranlib CMAKE_STRIP:FILEPATH=/usr/local/bin/strip EXEC_INSTALL_DIR:PATH=/usr/local/bin GETTEXT_MSGFMT_EXECUTABLE:FILEPATH=/usr/local/bin/msgfmt GETTEXT_MSGMERGE_EXECUTABLE:FILEPATH=/usr/local/bin/msgmerge LIBXML2_XMLLINT_EXECUTABLE:FILEPATH=/usr/local/bin/xmllint LIBXSLT_XSLTPROC_EXECUTABLE:FILEPATH=/usr/local/bin/xsltproc PERL_EXECUTABLE:FILEPATH=/usr/local/bin/perl PYTHON_EXECUTABLE:FILEPATH=/usr/local/bin/python2.7 RUBY_EXECUTABLE:FILEPATH=/usr/local/bin/ruby CMAKE_COMMAND:INTERNAL=/usr/local/bin/cmake CMAKE_CPACK_COMMAND:INTERNAL=/usr/local/bin/cpack CMAKE_CTEST_COMMAND:INTERNAL=/usr/local/bin/ctest CMAKE_EDIT_COMMAND:INTERNAL=/usr/local/bin/ccmake FIND_PACKAGE_MESSAGE_DETAILS_BISON:INTERNAL=[/usr/local/bin/bison][v3.0.4(2.1)] FIND_PACKAGE_MESSAGE_DETAILS_Gettext:INTERNAL=[/usr/local/bin/msgmerge][/usr/local/bin/msgfmt][v0.19.8.1()] FIND_PACKAGE_MESSAGE_DETAILS_Perl:INTERNAL=[/usr/local/bin/perl][v5.24.1(5.10.0)] FIND_PACKAGE_MESSAGE_DETAILS_PythonInterp:INTERNAL=[/usr/local/bin/python2.7][v2.7.13(2.7.0)] FIND_PACKAGE_MESSAGE_DETAILS_Ruby:INTERNAL=[/usr/local/bin/ruby][/usr/local/include/ruby-2.3][/usr/local/lib/libruby23.so][/usr/local/include/ruby-2.3/amd64-freebsd10][v2.3.0(1.9)] INTROSPECTION_COMPILER:INTERNAL=/usr/local/bin/g-ir-compiler INTROSPECTION_GENERATE:INTERNAL=/usr/local/bin/g-ir-generate INTROSPECTION_SCANNER:INTERNAL=/usr/local/bin/g-ir-scanner
Created attachment 182446 [details] patch - Fix build with binutils included in base.
Thank you very much for the patch for /usr/ports/www/webkit2-gtk3/Makefile. It worked perfectly for the build with DEBUG = off. PATH used was the one set by default /root/.cshrc as: /sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin
*** Bug 219346 has been marked as a duplicate of this bug. ***
Created attachment 182671 [details] [patch] explicitly point to base binutils tools if not using ports binutils I added an -B/usr/bin to Carlos' patch. If we are explicitly setting the path for certain base tools (/usr/bin/ar, etc.), we should explicitly tell clang++40 to look in /usr/bin at link time instead of relying on /usr/bin being in your path before /usr/local/bin. It turns out that the newer ld from the binutils port will probably work fine with .a files generated by the current /usr/bin/ar & /usr/bin/ranlib. But it's better to explicitly point to /usr/bin/ld to match the use of base ar & ranlib, IMO. By the way, something in the cmake code is causing the detection of ar, ranlib, etc., tools based on the CMAKE_CXX_COMPILER path. If CMAKE_CXX_COMPILER is /usr/local/bin/clang++40, it finds ar, ranlib, etc., in /usr/local/bin (if binutils port is installed). If CMAKE_CXX_COMPILER is /usr/bin/c++, cmake finds ar, ranlib, etc., in /usr/bin. Trying to follow the cmake logic to see where the determination which tool to use is difficult (at least for me). I'm no cmake guru. So there may be another way to "hint" cmake where to look for the tools. But this patch works well enough, I think.
works very well after change the lines in Makefile by 69 DEBUG_CMAKE_OFF= -DCMAKE_BUILD_TYPE:STRING=Release \ 70 -DCMAKE_AR=/usr/bin/ar \ 71 -DCMAKE_RANLIB=/usr/bin/ranlib \ 72 -DCMAKE_LINKER=/usr/bin/ld (debug off) big thx
A commit references this bug: Author: kwm Date: Sat May 27 07:14:31 UTC 2017 New revision: 441828 URL: https://svnweb.freebsd.org/changeset/ports/441828 Log: Update webkit2-gtk3 to 2.16.3. * Fix the build when using port compile and binutils is installed. It seems Cmake picks up ar and ranlib from localbase when using a compiler from ports, but the compiler uses ld from base for linking. Base ld doesn't understand some features newer ar and ranlib from localbase are using. So tell the build to always use ar and ranlib from base. [1] * Fix build failure on armv6 [2] PR: 219161 [1], 219495 [2] Submitted by: mikael.urankar@gmail.com [2] Changes: head/www/webkit2-gtk3/Makefile head/www/webkit2-gtk3/distinfo head/www/webkit2-gtk3/files/patch-Source_bmalloc_bmalloc_BPlatform.h head/www/webkit2-gtk3/pkg-plist