Re: false positive in ld-version-script.m4

[Ralf Wildenhues]

Hi Simon,

* Simon Josefsson wrote on Tue, Apr 14, 2009 at 12:53:14AM CEST:
> Ralf Wildenhues <address@hidden> writes:
> > * Simon Josefsson wrote on Fri, Apr 03, 2009 at 02:24:04PM CEST:
> >> --- a/m4/ld-version-script.m4
> >> +++ b/m4/ld-version-script.m4

> >> +# FIXME: The test below returns a false positive for mingw
> >> +# cross-compiles, 'local:' statements does not reduce number of
> >> +# exported symbols in a DLL.  Use --disable-ld-version-script to work
> >> +# around the problem.
> >> +
> >>  # gl_LD_VERSION_SCRIPT
> >
> > Why not
> >   AC_REQUIRE([AC_CANONICAL_HOST])
> >   ...
> >   case $host_os in mingw*) disable... ;; esac
> >
> > ?
> 
> That would work for now, but isn't such hard coding bad style in case
> mingw ever fixes this problem?

Is this for cross compilation only or for native as well?

Maybe I've misunderstood the problem: if, for a mingw cross compile,
this macro enables a version script, and that works, but only in the
sense that the build completes, but not in the sense that symbols are
hidden, then that may be good enough for the user.  You might still
want to output a warning at configure time to hint that you think that
symbol hiding doesn't really work.

At least a warning is something that is seen by the user.  They will
never look at your m4 macro for potential --disable switches to use for
a silent error they are not even seeing!

> Perhaps mingw cannot ever implement hiding of local symbols through
> version scripts, and in that case we might hard code the check result.

If this happens with native builds, too, then your comment above is
not correct.

> But then, doesn't it seem better for gcc/ld to reject a version script
> if it is impossible to support it?

I don't know what ld does on here.  Does it not even take visibility
into account?  If you care about actual versioning, you could try to
create a library with versioned symbols; otherwise, you could try to
create a library with hidden symbols and ensure that linking against
these symbols fails.  This should work even in a cross-compile setup,
but it will quite surely require most of the libtool machinery in order
to portably create a shared library at configure time.

Hope that helps.

Cheers,
Ralf