Re: Linking in WSAGetLastError

Re: Linking in WSAGetLastError

[Ed Bradford/Raleigh/IBM]

Ooops, I copy/pasted the line from the URL you sent. That line has a "-s"
in it.

Below is the marked up text from the URL.  Chages are in RED if the color
gets through
all the email servers and clients. I changed the "mydll" to mandel_dll for
my example and the "-s" in the first, third and fifth gcc lines to "
-shared". The "-shared" works.

The first dlltool line produces a "no .def file" error. Creating a .def
file that looks like
     EXPORTS
     mandel
     mandel_init
quiets dlltool.

The third line (the second call to gcc) line produces (if the "-s" is
changed to "-shared"):

   Warning: resolving _mandel_init by linking to _mandel_init@12
   Use --enable-stdcall-fixup to disable these warnings
   Use --disable-stdcall-fixup to disable these fixups

This is just a warning.

The forth line (the second call of dlltool) succeeds quietly.
The fifth line (the third call to gcc) fails with the following message:

   ~/src/cyg $ gcc -Wl,mandel_dll.exp -o mandel_dll.dll mandel_dll.o -Wl,
   -e,_mandel_init@12
   Warning: resolving _mandel_init by linking to _mandel_init@12
   Use --enable-stdcall-fixup to disable these warnings
   Use --disable-stdcall-fixup to disable these fixups
   /usr/lib/libcygwin.a(libcmain.o)(.text+0x6a):libcmain.c: undefined
   reference to
   `WinMain@16'
   collect2: ld returned 1 exit status

If "-shared" is added, the fifth line succeeds with a the same warning as
in the second gcc call.

The sixth line (the third and final call to dlltool) succeeds quietly.

If the following program is used as a test:

============mandel.c==========================
#include <windows.h>
#include <stdio.h>

int main(int ac, char *av[])
{
    double a,b,c,d;
    double x,y,x1,y1;
    unsigned long iterations;
    DWORD starttime, endtime;
    int i;

    iterations = 100000000;
    if(ac != 5) {
        a = .1;
        b = .1;
        c = .1;
        d = .1;
    }
    else {
        a = atof(av[1]);
        b = atof(av[2]);
        c = atof(av[3]);
        d = atof(av[4]);
        if(ac > 5)
            iterations = atoi(av[5]);
    }


    starttime = GetTickCount();
    i = mandel(a,b,c,d,iterations);
    endtime = GetTickCount();

    printf("mandel(%13.9f %13.9f %13.9f %13.9f) iter=%u    time %f
seconds\n",
            a,b,c,d,i,(double)((endtime - starttime)/1000.));

    return 0;
}
============mandel.c==========================
the following produces a real program:

     gcc -c mandel.c
     gcc mandel.o mandel_dll.a
On my system, running it with the default floating point values of .1, .1,
.1, .1 takes
about 38 seconds. (233MHZ Thinkpad). Note, the gcc lines have no
optimization specified.

Ed

==========================================================================
OK, let's go through a simple example of how to build a dll. For this
example, we'll use a single file mandel.c for the program (myprog.exe)
and a single file mydll.c for the contents of the dll (mydll.dll).

Now compile everything to objects:

 gcc -c mandel.c
 gcc -c mandel_dll.c

Create a .def file that looks like

     EXPORTS
     mandel
     mandel_init

Unfortunately, the process for building a dll is, well, convoluted. You
have to run five commands, like this:

 gcc -shared -Wl,--base-file,mandel_dll.base -o mandel_dll.dll mandel_dll.o
-Wl,-e,_mandel_init@12

 dlltool --base-file mandel_dll.base --def mandel_dll.def --output-exp
mandel_dll.exp --dllname mandel_dll.dll

 gcc -shared -Wl,--base-file,mandel_dll.base,mandel_dll.exp -o mandel_dll
.dll mandel_dll.o -Wl,-e,_mandel_dll_init@12

 dlltool --base-file mandel_dll.base --def mandel_dll.def --output-exp
mandel_dll.exp --dllname mandel_dll.dll

 gcc -shared -Wl,mandel_dll.exp -o mandel_dll.dll mandel_dll.o -Wl,-e,_
mandel_init@12



The extra steps give dlltool the opportunity to generate the extra sections
(exports and relocation) that a dll needs. After this, you build the
import library:

 dlltool --def mandel_dll.def --dllname mandel_dll.dll --output-lib
mandel_dll.a



Now, when you build your program, you link against the import library:

 gcc -o mandel mandel.o mandel_dll.a

This should succeed.
==========================================================================


Note that we linked with -e _mydll_init@12. This tells the OS what the
DLL's "entry point" is, and this is a special function that coordinates
bringing the dll to life withing the OS. The minimum function looks like
this:

Your Windows 2000 Arborist
T/L 589-4410; Outside: 1-919-993-4410
egb@us.ibm.com


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Linking in WSAGetLastError

[DJ Delorie]

>    Warning: resolving _mandel_init by linking to _mandel_init@12

You want -e _mandel_init@12, not -e _mandel_init

> The forth line (the second call of dlltool) succeeds quietly.

Why are you using dlltool?  Gcc can produce dlls in one step with
--shared.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: Linking in WSAGetLastError

[Michael Olson]

If your looking to build new import libraries from a beta version of Windows
I would think you'd need to get your hands on the debug version of the DLL's
so you can extract the export symbols from them. If you have a MS sanctioned
beta they usually come with a regular and debug version, perhaps you could
build your interface libraries from the DLL's on the debug disk. Question
though, do you have documentation and header files for the new system calls
you want to use?

-- Mike

----------------
Michael Olson
olson@cs.odu.edu
----------------

-----Original Message-----
From: Ed Bradford/Raleigh/IBM [ mailto:egb@us.ibm.com ]
Sent: Wednesday, September 27, 2000 11:54 AM
To: Michael Olson
Cc: cygwin@sourceware.cygnus.com
Subject: RE: Linking in WSAGetLastError


Not quite. I am running a "newer" version of Windows -- one you will be
able to get in October or so. I want
to build interface libraries for some of the DLL's for which Microsoft has
not yet delivered
the .lib files. Working through the document you mentioned below, there
seems to be some missing information.


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Linking in WSAGetLastError

[DJ Delorie]

>      gcc -s -Wl,--base-file,mandel_dll.base -o mandel_dll.dll mandel_dll.o
> -Wl,-e,_mandel_init@12

You're using the tools wrong.  Here, "-s" means "strip debug symbols".
If you want a shared library, use "--shared" instead.  You can use
both if you want a stripped DLL.  Use the --out-implib linker (-Wl,)
option to produce an import library at the same time.  You don't need
the --base-file option.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: Linking in WSAGetLastError

[Ed Bradford/Raleigh/IBM]

Not quite. I am running a "newer" version of Windows -- one you will be
able to get in October or so. I want
to build interface libraries for some of the DLL's for which Microsoft has
not yet delivered
the .lib files. Working through the document you mentioned below, there
seems to be some missing information.

========mandel_dll.c===========================================
#include <windows.h>

int mandel(double a, double b, double c, double d, int e)
{
     int i;
     double x,y,x1,y1;

     x = a;
     y = b;
     for(i = 0; i < e; i++) {
          x1 = x*x + y*y;
          y1 = -2 * x * y;
          if( (x1*x1 + y1*y1) > 1.0)
               break;
          x = x1 + c;
          y = y1 + d;
     }
     return i;
}
int WINAPI
mandel_init(HANDLE h, DWORD reason, void *foo) {
     return 1;
}
===============================================================

This is a simple one function dll.

     gcc -c mandel_dll.c
     gcc -s -Wl,--base-file,mandel_dll.base -o mandel_dll.dll mandel_dll.o
-Wl,-e,_mandel_init@12

produces the following on my Win2K SP1 system:

/usr/lib/libcygwin.a(libcmain.o)(.text+0x6a):libcmain.c: undefined
reference to
`WinMain@16'
collect2: ld returned 1 exit status
~/src/cyg $

I'm not sure what is going on here. I try this to understand how dll's are
made with gcc/dlltool.

Sorry to be so obtuse. (See you in Zihuatanejo.)

Ed

Your Windows 2000 Arborist
T/L 589-4410; Outside: 1-919-993-4410
egb@us.ibm.com


"Michael Olson" <olson@cs.odu.edu> on 09/27/2000 10:12:47 AM

To:   Ed Bradford/Raleigh/IBM@IBMUS
cc:   <cygwin@sourceware.cygnus.com>
Subject:  RE: Linking in WSAGetLastError



To link with a DLL (Like user32.dll) you need an import library which is
what -luser32
is linking your program to. Doc's on how to build dll's and import
libraries
are here
http://sources.redhat.com/cygwin/cygwin-ug-net/dll.html

Is that what you were looking for?

-- Mike

----------------
Michael Olson
olson@cs.odu.edu
----------------

-----Original Message-----
From: cygwin-owner@sources.redhat.com
[ mailto:cygwin-owner@sources.redhat.com]On Behalf Of Ed
Bradford/Raleigh/IBM
Sent: Wednesday, September 27, 2000 9:43 AM
To: DJ Delorie
Cc: cygwin@sourceware.cygnus.com
Subject: Re: Linking in WSAGetLastError


I'm missing something here. If the CYGWIN libraries don't export functions
(aren't current with MS API's) then
you simply can't use the function. At least that's what I thought. After a
few simple experiments, I find that I might be wrong. Is there something
written somewhere that describes the relationship between
     gcc msg.c
and the Microsoft libraries? For instance, using gcc -v I see no references
to the mssdk libraries. Is that
because there isn't any? Here is my simple "msg.c" program:

     #include <windows.h>

     int main(int ac, char *av[])
     {
          MessageBox(NULL, "Messsage", "Title", MB_OK);
          return 0;
     }

It compiles with either
     cl msg.c user32.lib -o msg-cl.exe
or
     gcc msg.c -o msg-gcc
Both compile, link and execute properly. More precisely,

   gcc -c msg.c
   ld -Bdynamic /lib/crt0.o msg.o -L/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2
   -luser32 -lcygwin -lkernel32

produces a correctly working executable. Here, all the "-l" things refer to
/lib/libXXX.a modules. Substituting
//e/mssdk/lib/user32.lib for the "-luser" in the ld line, results in an
undefined reference to MessageBoxA
which is what I would expect.

As you can see, I am a bit confused. Any pointers to writeups on how all
the gcc libraries and
Windows libraries fit together would be greately appreciated. Also, I
wouldn't mind writing some of this
up once I understand it.

Thank you
Ed Bradford



Your Windows 2000 Arborist
T/L 589-4410; Outside: 1-919-993-4410
egb@us.ibm.com


DJ Delorie <dj@delorie.com>@sources.redhat.com on 09/26/2000 09:33:12 PM

Sent by:  cygwin-owner@sources.redhat.com


To:   olson@cs.odu.edu
cc:   cygwin@sourceware.cygnus.com
Subject:  Re: Linking in WSAGetLastError




> conf.o(.text+0x2c74):conf.c: undefined reference to `WSAGetLastError'

They don't export WGAGetLastError.  They export WSAGetLastError@0.
This means that you aren't including the proper headers (winsock.h),
and it's defaulting to cdecl instead of stdcall (WINAPI) calling
conventions.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com




--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com




--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: Linking in WSAGetLastError

[Michael Olson]

To link with a DLL (Like user32.dll) you need an import library which is
what -luser32
is linking your program to. Doc's on how to build dll's and import libraries
are here
http://sources.redhat.com/cygwin/cygwin-ug-net/dll.html

Is that what you were looking for?

-- Mike

----------------
Michael Olson
olson@cs.odu.edu
----------------

-----Original Message-----
From: cygwin-owner@sources.redhat.com
[ mailto:cygwin-owner@sources.redhat.com]On Behalf Of Ed
Bradford/Raleigh/IBM
Sent: Wednesday, September 27, 2000 9:43 AM
To: DJ Delorie
Cc: cygwin@sourceware.cygnus.com
Subject: Re: Linking in WSAGetLastError


I'm missing something here. If the CYGWIN libraries don't export functions
(aren't current with MS API's) then
you simply can't use the function. At least that's what I thought. After a
few simple experiments, I find that I might be wrong. Is there something
written somewhere that describes the relationship between
     gcc msg.c
and the Microsoft libraries? For instance, using gcc -v I see no references
to the mssdk libraries. Is that
because there isn't any? Here is my simple "msg.c" program:

     #include <windows.h>

     int main(int ac, char *av[])
     {
          MessageBox(NULL, "Messsage", "Title", MB_OK);
          return 0;
     }

It compiles with either
     cl msg.c user32.lib -o msg-cl.exe
or
     gcc msg.c -o msg-gcc
Both compile, link and execute properly. More precisely,

   gcc -c msg.c
   ld -Bdynamic /lib/crt0.o msg.o -L/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2
   -luser32 -lcygwin -lkernel32

produces a correctly working executable. Here, all the "-l" things refer to
/lib/libXXX.a modules. Substituting
//e/mssdk/lib/user32.lib for the "-luser" in the ld line, results in an
undefined reference to MessageBoxA
which is what I would expect.

As you can see, I am a bit confused. Any pointers to writeups on how all
the gcc libraries and
Windows libraries fit together would be greately appreciated. Also, I
wouldn't mind writing some of this
up once I understand it.

Thank you
Ed Bradford



Your Windows 2000 Arborist
T/L 589-4410; Outside: 1-919-993-4410
egb@us.ibm.com


DJ Delorie <dj@delorie.com>@sources.redhat.com on 09/26/2000 09:33:12 PM

Sent by:  cygwin-owner@sources.redhat.com


To:   olson@cs.odu.edu
cc:   cygwin@sourceware.cygnus.com
Subject:  Re: Linking in WSAGetLastError




> conf.o(.text+0x2c74):conf.c: undefined reference to `WSAGetLastError'

They don't export WGAGetLastError.  They export WSAGetLastError@0.
This means that you aren't including the proper headers (winsock.h),
and it's defaulting to cdecl instead of stdcall (WINAPI) calling
conventions.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com




--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Linking in WSAGetLastError

[DJ Delorie]

> I'm missing something here. If the CYGWIN libraries don't export
> functions (aren't current with MS API's) then you simply can't use
> the function.

I don't see the connection with proper prototyping, but anyway...

gcc under cygwin links in a handful of libraries *every time*,
including the standard user32, gdi32, and kernel32 libraries (where
MessageBox@16 is exported, for example).  Just because cygwin itself
doesn't export the win32 functions doesn't mean you can't get them
from windows itself.  Cygwin includes import libraries for 65 system
DLLs total.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Linking in WSAGetLastError

[Ed Bradford/Raleigh/IBM]

I'm missing something here. If the CYGWIN libraries don't export functions
(aren't current with MS API's) then
you simply can't use the function. At least that's what I thought. After a
few simple experiments, I find that I might be wrong. Is there something
written somewhere that describes the relationship between
     gcc msg.c
and the Microsoft libraries? For instance, using gcc -v I see no references
to the mssdk libraries. Is that
because there isn't any? Here is my simple "msg.c" program:

     #include <windows.h>

     int main(int ac, char *av[])
     {
          MessageBox(NULL, "Messsage", "Title", MB_OK);
          return 0;
     }

It compiles with either
     cl msg.c user32.lib -o msg-cl.exe
or
     gcc msg.c -o msg-gcc
Both compile, link and execute properly. More precisely,

   gcc -c msg.c
   ld -Bdynamic /lib/crt0.o msg.o -L/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2
   -luser32 -lcygwin -lkernel32

produces a correctly working executable. Here, all the "-l" things refer to
/lib/libXXX.a modules. Substituting
//e/mssdk/lib/user32.lib for the "-luser" in the ld line, results in an
undefined reference to MessageBoxA
which is what I would expect.

As you can see, I am a bit confused. Any pointers to writeups on how all
the gcc libraries and
Windows libraries fit together would be greately appreciated. Also, I
wouldn't mind writing some of this
up once I understand it.

Thank you
Ed Bradford



Your Windows 2000 Arborist
T/L 589-4410; Outside: 1-919-993-4410
egb@us.ibm.com


DJ Delorie <dj@delorie.com>@sources.redhat.com on 09/26/2000 09:33:12 PM

Sent by:  cygwin-owner@sources.redhat.com


To:   olson@cs.odu.edu
cc:   cygwin@sourceware.cygnus.com
Subject:  Re: Linking in WSAGetLastError




> conf.o(.text+0x2c74):conf.c: undefined reference to `WSAGetLastError'

They don't export WGAGetLastError.  They export WSAGetLastError@0.
This means that you aren't including the proper headers (winsock.h),
and it's defaulting to cdecl instead of stdcall (WINAPI) calling
conventions.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com




--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Linking in WSAGetLastError

[DJ Delorie]

> conf.o(.text+0x2c74):conf.c: undefined reference to `WSAGetLastError'

They don't export WGAGetLastError.  They export WSAGetLastError@0.
This means that you aren't including the proper headers (winsock.h),
and it's defaulting to cdecl instead of stdcall (WINAPI) calling
conventions.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Linking in WSAGetLastError

[Michael Olson]

If there is a better place to ask questions like these someone please let me
know.

I'm using Cygwin 1.1.4 under Win2K SP1 and I can't get WSAGetLastError to
link in,
not sure why. I've tried both -lwsock32 -lws2_32 and I get an undefined
reference error.
I checked the def files for both of them in the sources and they both export
the function.

e.g.

gcc -o sendmail alias.o arpadate.o clock.o collect.o conf.o convtime.o
daemon.o deliver.o domain.o envelope.o err.o headers.o macro.o main.o map.o
mci.o mime.o parseaddr.o queue.o readcf.o recipient.o safefile.o savemail.o
snprintf.o srvrsmtp.o stab.o stats.o sysexits.o trace.o udb.o usersmtp.o
util.o version.o -lbind -ladvapi32 -lws2_32
conf.o(.text+0x2c74):conf.c: undefined reference to `WSAGetLastError'
<Lots more missing WSAGetLastError messages here.>

Thanks,
     Michael Olson
     <olson@cs.odu.edu>


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com