Date: Sat, 29 Mar 2014 14:21:50 +0100 From: Dimitry Andric <dim@FreeBSD.org> To: Dmitry Marakasov <amdmi3@amdmi3.ru> Cc: freebsd-ports@freebsd.org Subject: Re: HEAD clang failures due to unknown arguments Message-ID: <14D047DD-EE2F-4512-BC18-518B693CCD6B@FreeBSD.org> In-Reply-To: <20140329124652.GH73879@hades.panopticon> References: <20140329044342.GG73879@hades.panopticon> <73F477CA-6AF4-4217-AC81-730A5DED11D5@FreeBSD.org> <20140329124652.GH73879@hades.panopticon>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_7F090F0E-9DDA-4BE2-A17C-EAEC49D058EC
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=us-ascii
On 29 Mar 2014, at 13:46, Dmitry Marakasov <amdmi3@amdmi3.ru> wrote:
> * Dimitry Andric (dim@FreeBSD.org) wrote:
>
>>> Are we to fix new clang failures related to that clang now treats
>>> unknown arguments as fatal errors:
>>>
>>> ---
>>> c++: error: unknown argument: '-R/usr/local/lib'
>>> ---
>>
>> Yes, just replace -R/usr/local/lib with -Wl,-rpath,/usr/local/lib. This
>> is very easy to do with sed.
>
> I've just removed them and it worked. Or is there a reason for rpath to
> system lib directory?
It seems that -rpath is sometimes used gratuitously, indeed. Though it
can sometimes be necessary, if shared libraries are installed into
non-standard places, e.g. /usr/local/lib/myapp/libmyapp.so.
Also, not all systems have had /usr/local/lib in their default dynamic
linker path. And I'm also not sure what happens if you attempt to set
$LOCALBASE to something other than /usr/local/lib. :-)
I tried that once, and I was not really happy with the results...
> What about other keys? I've also encountered -fwhole-program and
> -malign-double
The only correct way, of course, is for the configuration phase (e.g.
CMake, autoconf, etc) to check if the used compiler supports the option.
Just blindly using it is almost always wrong.
That said, for old or mostly unmaintained software, it is probably fine
to just mechanically remove any unsupported options.
> What I plan to do is:
>
> ---
> USES+= compiler:env
>
> .include <bsd.port.pre.mk>
>
> post-patch:
> .if ${COMPILER_TYPE} == "clang"
> @${REINPLACE_CMD} -e 's|-fwhole-program||' ${WRKSRC}/CMakeLists.txt
> .endif
> ---
>
> but what if next version of clang learns of this key?
In this particular case, it will probably never support it. There are
many options which a very specific to gcc (mostly for its optimizer),
which make no sense for clang.
> I'd like to have
> something like
>
> .if ! ${COMPILER_SUPPORTED_ARGUMENTS:M-fwhole-program}
> @${REINPLACE_CMD} -e 's|-fwhole-program||' ${WRKSRC}/CMakeLists.txt
> .endif
>
> .if ${COMPILER_SUPPORTED_ARGUMENTS:M-malign-double}
> CXXFLAGS+= -malign-double
> .endif
Now you are encoding the work of CMake and autoconf into the ports
infrastructure? I am not sure if that is the proper way. However, I
seem to remember there was also an effort to provide "global" autoconf
and CMake preconfiguration, maybe this type of compiler-specific
knowledge thing could be folded into that?
-Dimitry
--Apple-Mail=_7F090F0E-9DDA-4BE2-A17C-EAEC49D058EC
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
iEYEARECAAYFAlM2yPoACgkQsF6jCi4glqNPEgCg5wbKtbxExmCaGQpTwUEugRmr
ZuUAn1TlRHwXWNm976nshVSIwzJ+SOaq
=ANTx
-----END PGP SIGNATURE-----
--Apple-Mail=_7F090F0E-9DDA-4BE2-A17C-EAEC49D058EC--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14D047DD-EE2F-4512-BC18-518B693CCD6B>