[Mesa-dev] [PATCH] shared-glapi: Convert to automake

Jon TURNEY jon.turney at dronecode.org.uk
Tue Mar 20 04:11:00 PDT 2012


On 19/03/2012 15:50, Kristian Høgsberg wrote:
> Ok, I pushed with the BUILT_SOURCES line, but didn't add -no-undefined.

On 19/03/2012 19:54, Matt Turner wrote:
> On Mon, Mar 19, 2012 at 3:52 PM, Jose Fonseca <jfonseca at vmware.com> wrote:
>> I didn't know that --no-undefined .  It seems quite nice, but more for Linux than Windows, as on windows all DLLs are linked work as if --no-undefined  is set -- no undefined symbols are ever allowed.
> 
> Right, I think that's why Jon suggests using it -- so that when we're
> testing on Linux we'll get undefined references we would otherwise not
> notice but that would break Windows builds.

To clarify the situation a bit:

--no-undefined is defined to cause libtool to attempt building a shared
library for platforms which require that all symbols are resolved when the
library is linked.  Otherwise, I just get the error "libtool: link: warning:
undefined symbols not allowed in i686-pc-cygwin shared libraries" and a static
library is built.

As far as I know, libtool --no-undefined is a no-op for Linux and does not
imply the ld options --no-undefined or --no-allow-shlib-undefined, because of
concerns that this would break existing builds and/or because it is possible
to have some unresolved symbols due to not to linking with ld-linux*.so.* (see
this ancient thread [1] for some details)

[1] http://gcc.gnu.org/ml/gcc-patches/2001-02/msg00305.html

Attached is a patch which add the -no-undefined libtool flag to
src/mapi/shared-glapi/Makefile.am.  This is necessary for the shared glapi to
be built as a shared library on Windows, and should have no effect on other
platforms.


More information about the mesa-dev mailing list