Re: mxe-build: undefined references

[Michael Goffioul]

On Fri, Mar 14, 2014 at 4:14 PM, John D <address@hidden> wrote:

-----Original Message-----
From: Torsten [mailto:address@hidden]
Sent: Friday, March 14, 2014 3:23 PM
To: John D; address@hidden
Subject: Re: mxe-build: undefined references

On 14.03.2014 18:14, John D wrote:
>
> Message: 5
> Date: Thu, 13 Mar 2014 18:52:18 +0100
> From: Torsten <address@hidden>
> To: octave maintainers mailing list <address@hidden>
> Subject: mxe-build: undefined references
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-1
>
> When I try to make an mxe-cross-build of a recent gui-release version
> of octave I get several undefined reference errors. Here some of them:
>
> graphics/.libs/libgui-graphics.a(graphics_libgui_graphics_la-GLCanvas.
> o): In function `ZN9QtHandles8GLCanvas11drawZoomBoxERK6QPointS3_':
> /home/ttl/mxe/tmp-octave/octave-3.9.0+/libgui/graphics/GLCanvas.cc:90:
> undefined reference to address@hidden'
> /home/ttl/mxe/tmp-octave/octave-3.9.0+/libgui/graphics/GLCanvas.cc:92:
> undefined reference to address@hidden'
> /home/ttl/mxe/tmp-octave/octave-3.9.0+/libgui/graphics/GLCanvas.cc:93:
> undefined reference to address@hidden'
> /home/ttl/mxe/tmp-octave/octave-3.9.0+/libgui/graphics/GLCanvas.cc:97:
> undefined reference to address@hidden'
> /home/ttl/mxe/tmp-octave/octave-3.9.0+/libgui/graphics/GLCanvas.cc:99:
> undefined reference to address@hidden'
> /home/ttl/mxe/tmp-octave/octave-3.9.0+/libgui/graphics/GLCanvas.cc:100:
> undefined reference to address@hidden'
> /home/ttl/mxe/tmp-octave/octave-3.9.0+/libgui/graphics/GLCanvas.cc:102:
> undefined reference to address@hidden'
> /home/ttl/mxe/tmp-octave/octave-3.9.0+/libgui/graphics/GLCanvas.cc:103:
> undefined reference to address@hidden'
>
> Is it in principle possible to compile the integrated QtHandles within
> the mxe environment?
>
> Torsten
>
> --
>
> Did it link with -lopengl32
>

No, it did not link to -lopengl32.
This is the command that produced the errors:

libtool: link: i686-w64-mingw32-g++ -shared -nostdlib
/home/ttl/software/octave/mxe/usr/lib/gcc/i686-w64-mingw32/4.8.2/../../../..
/i686-w64-mingw32/lib/../lib/dllcrt2.o
/home/ttl/software/octave/mxe/usr/lib/gcc/i686-w64-mingw32/4.8.2/crtbegin.o
 -Wl,--whole-archive qterminal/.libs/libqterminal.a src/.libs/libgui-src.a
graphics/.libs/libgui-graphics.a -Wl,--no-whole-archive
-L/home/ttl/software/octave/mxe/tmp-octave/octave-3.9.0+/.build/liboctave/.l
ibs
-L/home/ttl/software/octave/mxe/usr/i686-w64-mingw32/lib
.../libinterp/.libs/liboctinterp.dll.a
-L/home/ttl/software/octave/mxe/usr/lib/gcc/i686-w64-mingw32/4.8.2
-L/home/ttl/software/octave/mxe/usr/mingw/lib
.../liboctave/.libs/liboctave.dll.a -lQtNetwork4 -lQtOpenGL4 -lQtGui4
-lQtCore4 -lqscintilla2 -luser32 -lkernel32 -lgdi32 -lws2_32 -luser32
-lkernel32
-L/home/ttl/software/octave/mxe/usr/lib/gcc/i686-w64-mingw32/4.8.2/../../../
../i686-w64-mingw32/lib/../lib
-L/home/ttl/software/octave/mxe/usr/lib/gcc/i686-w64-mingw32/4.8.2/../../../
../i686-w64-mingw32/lib
/home/ttl/software/octave/mxe/usr/lib/gcc/i686-w64-mingw32/4.8.2/libstdc++.d
ll.a
-lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -lpthread
-ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 -lgcc_s -lgcc -lmoldname
-lmingwex -lmsvcrt
/home/ttl/software/octave/mxe/usr/lib/gcc/i686-w64-mingw32/4.8.2/crtend.o
-mieee-fp -O2 -pthread -Wl,-rpath-link
-Wl,/home/ttl/software/octave/mxe/usr/i686-w64-mingw32/lib
-Wl,--export-all-symbols   -pthread -o .libs/liboctgui-0.dll
-Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker
..libs/liboctgui.dll.a

Torsten

--

I ahvent tried compiling it mysekf yet, but would think that it would need
to link to the opengl32 library to resolve the opengl calls.

Dynamic linking is different in Win32 than in Linux. You only need to link against the libraries your code is really using. You don't need to link against the deps of a DLL if your own code doesn't make any calls from those deps. The calls that the DLL makes into those deps have already been resolved when the DLL was linked. This different behavior has several consequences:

- you cannot have undefined references at link time; something that is allowed under Linux

- you cannot override (at least it's far from trivial) symbols from a DLL, such that it's used by all other DLL that links to your code and to that DLL; typical example in octave is override XERBLA from the BLAS DLL, by using octave's version: this doesn't work in Win32

 

Looking at the package config file for QtOpenGL, it specifies opengl32 as
part of libs.private

Technically it's correct. The opengl32 is a private library that is only needed when you want to link QtOpenGL itself (that's the meaning of libs.private). If your code only uses symbols from QtOpenGL and do not make any OpenGL call, you don't need to link against opengl32. Obviously, your code would be useless, but still link-able in Win32.

Michael.