[ping] [PATCH] Use EXEEXT and -no-undefined flag even on Unix.

Michael Haubenwallner michael.haubenwallner at ssi-schaefer.com
Fri Nov 18 11:01:44 CET 2016


On 11/18/2016 12:20 AM, NIIBE Yutaka wrote:
> On 11/17/2016 06:08 PM, Michael Haubenwallner wrote:
>>> Your change effects not only Cygwin but also other POSIX systems,
>>> because you remove the Make variable of no_undefined to force
>>> -no-undefined flag.   It's good for Cygwin, but it's too radical
>>> for other systems.
>>
>> While I'm fine with the no_undefined=-no-undefined workaround, would
>> you mind to elaborate why it's too radical for other systems?
> 
> Your change has an impact to other systems.  When you don't know how
> large the impact is, please be conservative and be more careful.

Agreed - except for that I believe to know about the impact. :)

> Please note that libgpg-error uses libtool for its build.  And libtool
> has the option "-no-undefined" because there are some systems where
> undefined symbols are valid or even needed.
> 
> For example, (at least) I know the user space implementation of shared
> library for a.out format where it's inevitable to have undefined
> symbols.
> 
> Please note that shared library feature is not standardized for POSIX
> systems.  I think that we have libtool for this exact reason.

Exactly. But doesn't this also mean that the libtool user should not
need to take care about the underlying library architecture any more?

> For detail, please see:
> 
>     https://www.gnu.org/software/libtool/manual/html_node/index.html

So the "-no-undefined" flag "allows libtool to assume that undefined
symbols will not happen", rather than "must not happen".

> For modern systems of ELF, System V Application Binary Interface
> defines the shared object format and its semantics.  (17 years ago, I
> made one for SuperH architecture together with my friend,
> independently to its vendor.  Around that time, some people insisted
> that static linking is only good for embedded systems.)
> 
> Well, I agree with you that your claim (no undefined symbols) are
> valid for most of modern systems.  On the other hand, I would like to
> support other systems as well.

So if the "-no-undefined" flag breaks somewhere, and there really is no
undefined symbol within the library itself and the linked libraries,
then I would take this as libtool bug.

Another upside: Having linkers (that are able to) report undefined
symbols may unhide obscure bugs in the library.

Anyway, thanks for sharing your thoughts!
/haubi/



More information about the Gnupg-devel mailing list