HEAD clang failures due to unknown arguments

Dimitry Andric dim at FreeBSD.org
Sat Mar 29 13:22:09 UTC 2014

On 29 Mar 2014, at 13:46, Dmitry Marakasov <amdmi3 at amdmi3.ru> wrote:
> * Dimitry Andric (dim at 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
> 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?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20140329/b3b29641/attachment.sig>

More information about the freebsd-ports mailing list