The hexchat configure scripts seems to prefer 'gcc' over ${CC} for compiler. As result, the build is broken: libtool: link: gcc -fstack-protector -pie -Wl,-z -Wl,relro -Wl,-z -Wl,now -o hex chat hexchat-ascii.o hexchat-banlist.o hexchat-chanlist.o hexchat-chanview.o hex chat-custom-list.o hexchat-dccgui.o hexchat-editlist.o hexchat-fe-gtk.o hexchat- fkeys.o hexchat-gtkutil.o hexchat-ignoregui.o hexchat-joind.o hexchat-menu.o hex chat-maingui.o hexchat-notifygui.o notifications/hexchat-notification-dummy.o he xchat-palette.o hexchat-pixmaps.o hexchat-plugin-tray.o hexchat-plugingui.o hexc hat-plugin-notification.o hexchat-rawlog.o hexchat-servlistgui.o hexchat-setup.o hexchat-sexy-iso-codes.o hexchat-sexy-spell-entry.o hexchat-textgui.o hexchat-u rlgrab.o hexchat-userlistgui.o hexchat-xtext.o hexchat-resources.o -Wl,--export-dynamic -pthread -pthread ../../src/common/libhexchatcommon.a -L/usr/local/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo -lpthread -lgdk_pixbuf-2.0 -lpangoft2-1.0 -lpango-1.0 -lfontconfig -lfreetype -lgmodule-2.0 -lgio-2.0 -lcrypto -lssl -lproxy -ldbus-glib-1 -ldbus-1 -lgobject-2.0 -lgthread-2.0 -lglib-2.0 -lX11 -lintl -pthread /usr/local/bin/ld: /usr/lib/crt1.o: relocation R_X86_64_32 against `_DYNAMIC' can not be used when making a shared object; recompile with -fPIC /usr/lib/crt1.o: error adding symbols: Bad value collect2: error: ld returned 1 exit status gmake[4]: *** [Makefile:584: hexchat] Error 1 I am not sure where to properly put the blame. The cause of the failure is the use of crt1.o with -pie, Scrt1.o must be used instead for PIE binaries. I.e. it might be lang/gcc bug of not fixing spec, or it might be libtool use with non-system compiler. Temporary removing gcc from the path allowed the port to build.
I had the same problem (10.3-RELEASE). Put MAKE_ARGS= LDFLAGS="${LDFLAGS}" in the port Makefile solved it for me.
Created attachment 172986 [details] hexchat.diff (In reply to w.schwarzenfeld from comment #1) I can confirm this works, but libtool --mode=link is still using gcc. This can be solved by overriding the OBJC make variable. See patch. I've left --disable-silent-rules in so you can see what's happening. The only Objective C file in the source tree that I could find is plugins/sysinfo/osx/backend.m, so it's probably OS X related that it looks for an Objective C compiler. A build log with the patch applied is here: http://paste2.org/6jbvgzM4
(In reply to Tobias Kortkamp from comment #2) The culprit seems to be AC_PROG_OBJC in configure.ac, but patching this out also needs patching of src/fe-gtk/Makefile.am and plugins/sysinfo/Makefile.am.
Ports must respect CC: https://www.au.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/book.html#dads-cc
(In reply to Tobias Kortkamp from comment #3) After this discussion, I am certain that the bug is in lang/gcc. Its spec must use Scrt1.o for PIE.
Seems ok to me, builds fine. No bumping PORTREVISION because the port is broken with installed lang/gcc anyway.
(In reply to Konstantin Belousov from comment #5) How can the bug can be in lang/gcc when hexchat builds when it isn't installed? gcc may well also have a bug, but that hexchat ends up using it and not ${CC} is an issue.
Also, are we sure this isn't a partial or complete symptom of the widely scoped CPPFLAGS/LDFLAGS?
(In reply to Kubilay Kocak from comment #7) Exactly because it builds without gcc and does not build with gcc installed, it pretty nicely illustrates the bug in gcc port. The fact that the port build uses gcc as the linker driver is a separate issue, which is less damaging and less important than the toolchain port bug.
(In reply to w.schwarzenfeld from comment #1) Thanks for the tip! Just one quick correction. It should be: MAKE_ARGS+= LDFLAGS="${LDFLAGS}" in case anyone is planning to use this. Note the "+"; otherwise files will end up in /usr/local while making and other unpleasantness. Hope this gets resolved fast, thanks.
(In reply to Anindya Mukherjee from comment #10) Sorry, the missing "+" was a typo.
(In reply to w.schwarzenfeld from comment #11) No worries, I figured :) Thanks again for the tip.
We have two (temporary) solutions, one of which was approved by the maintainer already in comment #6 three weeks ago. Can someone make a decision and commit one of them? Or are we just waiting on lang/gcc getting fixed?
testbuild with gcc in $PATH on 12a: it's fine.
A commit references this bug: Author: pi Date: Fri Aug 26 06:17:08 UTC 2016 New revision: 420892 URL: https://svnweb.freebsd.org/changeset/ports/420892 Log: irc/hexchat: fix build when lang/gcc is installed PR: 211327 MFH: 2016Q3 Reported by: kib Submitted by: Tobias Kortkamp <t@tobik.me> Approved by: Piotr Kubaj <pkubaj@anongoth.pl> (maintainer) Changes: head/irc/hexchat/Makefile
I checked the quarterly version, which is not the same version, so no MFH for now.