This is the mail archive of the
mailing list for the Cygwin project.
Re: Using VC-compiled Mesa binaries under Cygwin
* * wrote:
> On 1/17/06, Eric Lilja wrote:
>> * * wrote:
>>> Are the import libraries using the cygwin filename conventions?
>> Well, no. Building Mesa with glut creates the following files (which
>> I have copied to the directory of the simple test program I trying
>> to build with compiler supplied with Cygwin using the Makefile in
>> first post): $ ls *.DLL *.lib
>> GLU32.DLL* GLU32.lib* GLUT32.DLL* GLUT32.lib* OPENGL32.DLL*
>>> -lm links against
>>> -lpcre links against
>>> GCC just isn't going to find a file named glut32.lib using the
>>> -lglut32 switch like microsoft link.exe does. It might work if you
>>> list it like all the object files.
>> I tried renaming GLUT32.DLL to libglut32.dll.a, but the linker still
> But libglut32.dll.a should be the import library which Visual C++
> named GLUT32.LIB
Ok, so I should rename the import library? But the linker seems to be able
to find the libraries somewhere because if I pass -lsomeinvalidname to the
linker it would say so, right?
>> find the definitions of any glut functions. I tried adding
>> GLUT32.lib with the objects in the linking stage, but still no go.
> This I would have hoped would work. The GLUT32.DLL is certainly
> usable from cygwin, as all system DLLs are (although non-C DLLs might
> not be in some cases).
>> However, doing a nm GLUT32.lib | grep glutPostRedisplay (the first
>> undefined reference), shows:
>> $ nm GLUT32.lib | grep _glutPostRedisplay
>> 00000000 I __imp__glutPostRedisplay@0
>> 00000000 T _glutPostRedisplay@0
> This is definitely the MSVC name mangling convention.... but I think
> that gcc doesn't append the number of bytes on the end. What calling
> convention did you compile with? I think MSVC adds the argument size
> to stdcall but not cdecl, or else the other way around.
I checked the glut project and it's built with __cdecl by default. I changed
to stdcall, and then it wouldn't compile due to one error that I was able to
fix by adding a simple cast (not sure if it's the correct solution, though).
However, my test program still doesn't link and it's the calls to the glut
functions that gives me trouble (the linker seems to find the definitions
for the calls I make to gl or glu functions. Here are the exact linker
errors (using stdcall version of glut):
gcc -Wall -W -ansi -pedantic -g -O0 -I/home/mikael/mesacvs/Mesa/include -c -o
simple1_9.c:144: warning: unused parameter 'x'
simple1_9.c:144: warning: unused parameter 'y'
gcc simple1_9.o -L. -lopengl32 -lglu32 -lglut32 -o 1-9.exe
simple1_9.o: In function `idle':
reference to `_glutPostRedisplay'
simple1_9.o: In function `display':
reference to `_glutSwapBuffers'
simple1_9.o: In function `main':
reference to `_glutInit'
reference to `_glutInitDisplayMode'
reference to `_glutInitWindowPosition'
reference to `_glutInitWindowSize'
reference to `_glutCreateWindow'
reference to `_glutDisplayFunc'
reference to `_glutReshapeFunc'
reference to `_glutKeyboardFunc'
reference to `_glutIdleFunc'
reference to `_glutMainLoop'
collect2: ld returned 1 exit status
make: *** [all] Error 1
And nm yields for the stdcall version:
$ nm GLUT32.lib | grep _glutPostRedisplay
00000000 I __imp__glutPostRedisplay@0
00000000 T _glutPostRedisplay@0
> Actually, what was the error in the previous step? Undefined symbols
> I presume? Please give a couple examples so I can see the mangled
> names. You may want to try recompiling the DLL with a different
> calling convention specified in your MSVC project. Functions in
> system DLLs are stdcall. I note that the /usr/include/w32api/*.h have
> all declarations include __declspec(dllimport) __stdcall just like
> MSVC... so your header files may need this too.
>> Any ideas? And one more thing: Please don't quote raw email
>> addresses when replying to this list. Thanks.
> Oops. Very sorry.
> Other idea is to extract a gcc-format import library using dlltool...
> this looks helpful:
I tried that:
pexports GLUT32.DLL | sed 's/^_//' > glut32.def
Then I removed the @somenumber after each function. And it linked! Woot!
But! When I run the resulting executable, a message box pops up saying:
The procedure entry point glutCreateWindow could not be located in the
dynamic link librar GLUT32.DLL. =( Any ideas? That function is the first
glut-function I call btw.
>>> On 1/16/06, Eric Lilja wrote:
>>>> I just compiled the latest version of Mesa (6.4.1) using Microsoft
>>>> Visual Studio, because I couldn't compile it with MinGW or Cygwin.
>>>> After editing a macro, I was successful in compiling Mesa + glut in
>>>> Visual Studio. Now, can I use the binaries (libs and DLLs) with
>>>> Cygwin? I can't seem to get my test program to link...I put the
>>>> mesa-binaries in the application path and I am using the following
>>>> CC = gcc
>>>> CFLAGS = -Wall -W -ansi -pedantic -g -O0 -c -o
>>>> LDFLAGS = -L. -lglut32 -lglu32 -lopengl32 -o $(EXEC)
>>>> EXEC = proj.exe
>>>> OBJECTS = simple1_9.o
>>>> all: $(OBJECTS)
>>>> $(CC) $^ $(LDFLAGS)
>>>> %.o: %.c
>>>> $(CC) $(CFLAGS) $@ $<
>>>> rm -f $(OBJECTS) $(EXEC) *~ *.stackdump
>>>> But I'm getting link errors for any glut-functions....any ideas?
>>>> Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
>>>> Problem reports: http://cygwin.com/problems.html
>>>> Documentation: http://cygwin.com/docs.html
>>>> FAQ: http://cygwin.com/faq/
>> Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
>> Problem reports: http://cygwin.com/problems.html
>> Documentation: http://cygwin.com/docs.html
>> FAQ: http://cygwin.com/faq/
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html