svn commit: r216295 - in head/usr.sbin/bsnmpd: . tools tools/bsnmptools tools/libbsnmptools

[Dimitry Andric]

On 2010-12-12 21:06, Kostik Belousov wrote:
>> -LDFLAGS= -export-dynamic
>> +LDFLAGS= -Wl,-export-dynamic
>>
>>   .if ${MK_OPENSSL} != "no"
>>   CFLAGS+= -DHAVE_LIBCRYPTO
>
> I believe this was already discussed ? Traditional cc driver behaviour
> is to pass all unparsed flags and potential file names to the linker
> as is.

That may be the case, but at least for unknown flags, that behaviour
itself is rather braindead, in my opinion.  How would you ever be able
to add support for a new flag using this model?  You would never know
whether the flag is 'silently' ignored and passed to the linker, or used
by the driver itself.

Another problem is flag shadowing.  For example, the ld flag in
question, '--export-dynamic', has a much easier short equivalent, '-E'.
However, you cannot use that equivalent directly on gcc's command line,
since it conflicts with gcc's own interpretation of that flag.  (I guess
this is the original reason for using the long option name instead of
the short one.)

The -Wl flag is specified to pass ld-specific flags to ld, so what is
the harm in using it for its intended purpose?  It is used in GNU's own
autoconf scripts, and throughout the FreeBSD tree, even before clang's
introduction.  In fact, I think you could argue to replace all such
ambiguous flags with unambiguous ones.