Re: How do I avoid buying MSVC++?

Re: How do I avoid buying MSVC++?

[Mumit Khan]

On Sat, 2 Jan 1999, Max Hadley wrote:

> when not to. Also on his/her advice:
> 
>     #define _declspec(A) extern

Actually, gcc does support __declspec, but not _declspec. Microsoft
uses _declspec as a synonym for __declspec, but suggests that you
use __declspec in the documentation.

Use the following:
   
   #define _declspec(x) __attribute__((x))

and that should fix the global problem.

fyi, GCC's "specs" define __declspec as the following:

   #define __declspec(x) __attribute__((x))

Regards,
Mumit

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: How do I avoid buying MSVC++?

[Max Hadley]

Dear list,

Thanks to 'bowman' I have now got one more step nearer a solution to
this problem.
Using the -k switch to dlltool gets round the problem of "The procedure
entry point ibclr@4 could not be located in the dynamic link library
ntgpib.dll". Apparently this switch knows when to decorate names and
when not to. Also on his/her advice:

    #define _declspec(A) extern

gets round the 'Microsoft extensions to the C/C++ language' causing gcc
to fail problem.

However, although I am now getting functions and procedures from the DLL
linked correctly, there still seems to be a problem with DLL data. The
library has four globals, representing the status, error state, etc., of
the hardware. These are processed in the same way as function calls by
nm, generating a .def file which has undecorated variable names in the
EXPORTS section. The application finds something to link to, and all
seemed to be going well, BUT...

The values in these globals seem to be rubbish! The application fails
with a segmentation fault when it attempts to write to them, and they
don't seem to change  as they should when DLL functions are called. Gdb
shows that the run-time addresses of these variables are suspiciously
close to addresses of various functions within the application. I
suspect what is happening is that these symbols are being interpreted as
references to the text segment of the program, not the idata segment.
However I can't figure out how to make gdb tell me the address at which
the various segments are loaded, so I can't be sure.

Can anyone offer any further help & advice? Also, is there any
documentation to dlltool? I couldn't find any.

Max Hadley


-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: How do I avoid buying MSVC++?

[Max Hadley]

Many thanks, Mumit, your suggestion appears to have fixed the problem
and I can now compile and run the program without any errors.

Is any of this documented anywhere? It does seem to me that a lot of
traffic on this list comes from people like me just trying to find their
way round Cygwin. A really good FAQ/read me first would help a lot.

Thanks again to all who have helped me,

Max Hadley

-----Original Message-----
From: Mumit Khan <khan@xraylith.wisc.edu>
To: Max Hadley <max@susato.demon.co.uk>
Cc: Cygwin mailing list <gnu-win32@cygnus.com>
Date: Sunday, January 03, 1999 6:17 AM
Subject: Re: How do I avoid buying MSVC++?


>On Sat, 2 Jan 1999, Max Hadley wrote:
>
>> when not to. Also on his/her advice:
>>
>>     #define _declspec(A) extern
>
>Actually, gcc does support __declspec, but not _declspec. Microsoft
>uses _declspec as a synonym for __declspec, but suggests that you
>use __declspec in the documentation.
>
>Use the following:
>
>   #define _declspec(x) __attribute__((x))
>
>and that should fix the global problem.
>
>fyi, GCC's "specs" define __declspec as the following:
>
>   #define __declspec(x) __attribute__((x))
>
>Regards,
>Mumit
>
>-
>For help on using this list (especially unsubscribing), send a message
to
>"gnu-win32-request@cygnus.com" with one line of text: "help".

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: How do I avoid buying MSVC++?

[Mumit Khan]

On Sun, 3 Jan 1999, Max Hadley wrote:

> Many thanks, Mumit, your suggestion appears to have fixed the problem
> and I can now compile and run the program without any errors.

Great.

> 
> Is any of this documented anywhere? It does seem to me that a lot of
> traffic on this list comes from people like me just trying to find their
> way round Cygwin. A really good FAQ/read me first would help a lot.
> 

Ahem, no. The wonders of Windows32 would take a lot of work to document
correclty (eg., if I were to document it, I'd surely not remember to
include the _declspec since that's not even in MS docs, and people still
keep on using it).

However, one of the purposes of the mailing list archives is to provide
*some* rudimentary form of docs until someone contributes some FAQs or
something of the sort. 

Regards,
Mumit


-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: How do I avoid buying MSVC++?

[Max Hadley]

Hello again Cygwin list,

I'm back from my Christmas travels, and ready to tackle compiling this
demo program once more. First off, thanks to all who contributed help &
advice, on & off list. I think I'm begining to see my way now.

Point 1: RTFM (or at least RTFWS). I checked on the cygnus web site &
found how to generate a .a import library for my third-party DLL from
the supplied .lib:

    echo EXPORTS > ntgpib.def
    E:/cygwin/cygwin-b20/H-i586-cygwin32/bin/nm ntgpib.lib | grep ' T _'
| sed 's/.* T _//' >> ntgpib.def
    dlltool --def ntgpib.def --dllname ntgpib.dll --output-lib ntgpib.a

This got rid of all the "ignoring duplicate section `.text'" errors. I
should re-iterate I'm using the MKS toolset, not the Cygwin tools, by
default. hence I have to call Cygwin nm by an absolute pathname. MKS
grep & sed work just the way they should, but the output format of nm is
a bit different.

Point 2: I found if I included "-luser32 -lgdi32" on the gcc link
command line, I got no "undefined reference" errors, and a .exe file was
produced.

Point 3: I should have said that the header file as supplied caused gcc
to whinge:

    susato[232] $ make ntcdemo.exe
    gcc -c  -mwindows -g -pedantic -Wall ntcdemo.c
    In file included from ntcdemo.c:31:
    windecl.h:28: warning: return-type defaults to `int'
    windecl.h: In function `_declspec':
    windecl.h:29: parse error before `_declspec'
    windecl.h:28: declaration for parameter `ibsta' but no such
parameter
    ...
    (many more errors)

The include file windecl.h has some very strange Windows stuff I don't
understand (I haven't programmed Windows in C since its 16-bit days):

    #ifdef _WINDOWS                 /* This is for QuickWin */
        #ifndef _WIN32              /* if (WINVER < 0x0400) */
            #define GPIBAPI _far _pascal
        #else
            #define GPIBAPI __stdcall
        #endif
    #else
        #define GPIBAPI __stdcall
    #endif

    /* Global status variables */
    #ifdef _WIN32
        _declspec( dllimport ) int  ibsta;
        _declspec( dllimport ) int  iberr;
        _declspec( dllimport ) int  ibcnt;
        _declspec( dllimport ) long ibcntl;
    #else
        extern int  ibsta;
        extern int  iberr;
        extern int  ibcnt;
        extern long ibcntl;
    #endif

What is a _declspec? I got around this by commenting out the #ifdef
part, so the simple extern declarations are picked up, & this compiled
without errors:

    susato[246] $ make ntcdemo.exe
    gcc -c  -mwindows -g -pedantic -Wall ntcdemo.c
    gcc -o ntcdemo.exe ntcdemo.o ntgpib.a -luser32 -lgdi32

I was left with a brand-new ntcdemo.exe. Typing ntcdemo at the shell
prompt produced a short burst of disk activity, and an error exit:

    susato[247] $ ntcdemo
    susato[248] $ echo $?
    128

Running under gdb gave me a little extra help:

    susato[249] $ gdb ntcdemo.exe
    GNU gdb 4.17.1
    Copyright 1998 Free Software Foundation, Inc.
    GDB is free software, covered by the GNU General Public License, and
you are
    welcome to change it and/or distribute copies of it under certain
conditions.
    Type "show copying" to see the conditions.
    There is absolutely no warranty for GDB.  Type "show warranty" for
details.
    This GDB was configured as "i586-cygwin32"...
    (gdb) run
    Starting program: //E/Users/max/progs/WAVstuff/temp/ntcdemo.exe
    61000000://E/Users/max/progs/WAVstuff/temp/cygwin1.dll

    [failed reading symbols from DLL]
    "//E/WINNT/system32/advapi32.dll": error reading line numbers


    [failed reading symbols from DLL]
    "//E/WINNT/system32/KERNEL32.dll": error reading line numbers

    77e70000://E/WINNT/system32/USER32.dll
    77ed0000://E/WINNT/system32/GDI32.dll
    77e10000://E/WINNT/system32/RPCRT4.dll
    10000000://E/Users/max/progs/WAVstuff/temp/ntgpib.dll
    gdb: unknown target exception 0xc0000139 at 0x77f88e01

    Program received signal SIGSEGV, Segmentation fault.
    0x77f8f898 in ?? ()
    (gdb)

Double-clicking the file ntcdemo.exe in Explorer produced an error
message box:

    ntcdemo.exe - Entry Point Not Found
    The procedure entry point ibclr@4 could not be located in the
dynamic link library ntgpib.dll

Aha! something to do with the function name massaging trickery? The
exports list for the DLL, as produced by quickview, doesn't have the @4
tail. Another helpful poster suggested adding the -mwindows switch to
the linker command line, as well as (?) the compile line. This produced
the following:

    susato[252] $ make ntcdemo.exe
    gcc -c  -mwindows -g -pedantic -Wall ntcdemo.c
    gcc -o ntcdemo.exe ntcdemo.o ntgpib.a -mwindows
    //E/cygwin/cygwin-b20/H-i586-cygwin32/i586-cygwin32/bin/ld: warning:
cannot find entry symbol _WinMainCRTStartup; defaulting to 00401000
    susato[253] $

But a .exe file is generated, which appears to behave in exactly the
same way as the previous version. So I think I'm nearly there, apart
from a couple of things.

1. How can I get the function name thing straightened out?
2. Is the _declspec Ju-Ju important, or can I use extern int?

I should admit that at the end of the day I want to write a console app
to use this DLL, not a GUI app, but I need to sort out these problems. I
wouldn't choose C as an implementation language for a windows GUI app! A
very simple test (just calls the 'is the DLL loaded properly' function)
has the same problems with the function naming.

Any suggestions would be very welcome, and thanks again (apologies for
the length of this posting)

Max Hadley
Bramshaw
Hampshire
UK


-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: How do I avoid buying MSVC++?

[Fergus Henderson]

On 23-Dec-1998, Max Hadley <max@susato.demon.co.uk> wrote:
> gcc  -o ntcdemo.exe ntcdemo.o ntgpib.lib

AFAIK, gcc does not support `.lib' files.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "Binaries may die
WWW: < http://www.cs.mu.oz.au/~fjh >  |   but source code lives forever"
PGP: finger fjh@128.250.37.3        |     -- leaked Microsoft memo.
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

RE: How do I avoid buying MSVC++?

[Dan Haynes]

If you are just looking for Win32 programming (not porting Unix apps), have
you looked at LCC for Win32? The mailing list is lcc@cs.princeton.edu. LCC
is just a compiler, not a complete Unix-like environment like Cygwin - but
there is a very good quality Win32 version of LCC  that is actively being
developed and may suit your purposes.

Regards,

  Dan Haynes

> -----Original Message-----
> From: owner-gnu-win32@cygnus.com [ mailto:owner-gnu-win32@cygnus.com]On
> Behalf Of Max Hadley
> Sent: Wednesday, December 23, 1998 1:50 PM
> To: Cygwin mailing list
> Subject: How do I avoid buying MSVC++?
>
>
> Dear Cygwin list,
>
> After much messing around, involving a complete new second installation
> of Windows NT, I *think* I have got b20.1 installed. Cygnus, it's only
> *your* Installshield installer that fails every time on my original NT.
> It would be nice if there was a text file or SOMETHING that spells out
> exactly what the installer does in the registry & environment, as I had
> to spelunk it out of one registry & edit it into the other. Not
> pleasant.
>
> I can build a 'hello world' console application happily.
>
> Now I need to build win32 API code, supplied by a third party, to drive
> a PCI card in the PC. Here is my makefile (I'm using MKS make, not GNU):
>
> HEADERS := windecl.h
> SOURCES :=  ntcdemo.c
> OBJECTS := $(SOURCES:db:+"$(O)")
> LIBRARIES := ntgpib.lib
>
> CFLAGS += -g -pedantic -Wall -mwindows
>
> ntcdemo.exe : $(OBJECTS) $(LIBRARIES)
>
> .PRECIOUS $(OBJECTS) : $(HEADERS)
>
> BTW my default value of CFLAGS is null. This generates a bunch of lines
> like this (ellipses mark deletions):
>
> susato[230] $ make
> gcc  -o ntcdemo.exe ntcdemo.o ntgpib.lib
> //E/cygwin/cygwin-b20/H-i586-cygwin32/i586-cygwin32/bin/ld:
> ntgpib.lib(NTGPIB.dll): warning: ignoring duplicate section `.text'
> //E/cygwin/cygwin-b20/H-i586-cygwin32/i586-cygwin32/bin/ld:
> ntgpib.lib(NTGPIB.dll): warning: ignoring duplicate section `.idata$5'
> ...
> ...
> ntcdemo.o: In function `WinMain':
> //E/Users/max/progs/WAVstuff/temp/ntcdemo.c:89: undefined reference to
> `LoadCursorA@8'
> //E/Users/max/progs/WAVstuff/temp/ntcdemo.c:90: undefined reference to
> `GetStockObject@4'
> //E/Users/max/progs/WAVstuff/temp/ntcdemo.c:93: undefined reference to
> `RegisterClassA@4'
> //E/Users/max/progs/WAVstuff/temp/ntcdemo.c:97: undefined reference to
> `GetSystemMetrics@4'
> ...
> ...
> ntcdemo.o: In function `MainMessageHandler':
> //E/Users/max/progs/WAVstuff/temp/ntcdemo.c:166: undefined reference to
> `GetDC@4'
> //E/Users/max/progs/WAVstuff/temp/ntcdemo.c:167: undefined reference to
> `GetStockObject@4'
> //E/Users/max/progs/WAVstuff/temp/ntcdemo.c:168: undefined reference to
> `SelectObject@8'
> //E/Users/max/progs/WAVstuff/temp/ntcdemo.c:169: undefined reference to
> `GetTextMetricsA@8'
> ...
> ...
> //E/Users/max/progs/WAVstuff/temp/ntcdemo.c:246: undefined reference to
> `DefWindowProcA@16'
> collect2: ld returned 1 exit status
> make: Error code 1
> susato[231] $
>
> So what is going wrong? I assume some windows libraries are not getting
> linked, but how do I find out which? Why all the duplicate sections
> warnings from the board vendor's library?
>
> Assuming this code works with MSVC++ (& I have no reason to assume it
> doesn't) is it possible to make it work with CYGWIN? Or do I have to get
> MSVC++ to use this card I have just bought.
>
> Thanks in advance, and Merry Christmas
>
> Max Hadley
>
>
> -
> For help on using this list (especially unsubscribing), send a message to
> "gnu-win32-request@cygnus.com" with one line of text: "help".
>

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

How do I avoid buying MSVC++?

[Max Hadley]

Dear Cygwin list,

After much messing around, involving a complete new second installation
of Windows NT, I *think* I have got b20.1 installed. Cygnus, it's only
*your* Installshield installer that fails every time on my original NT.
It would be nice if there was a text file or SOMETHING that spells out
exactly what the installer does in the registry & environment, as I had
to spelunk it out of one registry & edit it into the other. Not
pleasant.

I can build a 'hello world' console application happily.

Now I need to build win32 API code, supplied by a third party, to drive
a PCI card in the PC. Here is my makefile (I'm using MKS make, not GNU):

HEADERS := windecl.h
SOURCES :=  ntcdemo.c
OBJECTS := $(SOURCES:db:+"$(O)")
LIBRARIES := ntgpib.lib

CFLAGS += -g -pedantic -Wall -mwindows

ntcdemo.exe : $(OBJECTS) $(LIBRARIES)

.PRECIOUS $(OBJECTS) : $(HEADERS)

BTW my default value of CFLAGS is null. This generates a bunch of lines
like this (ellipses mark deletions):

susato[230] $ make
gcc  -o ntcdemo.exe ntcdemo.o ntgpib.lib
//E/cygwin/cygwin-b20/H-i586-cygwin32/i586-cygwin32/bin/ld:
ntgpib.lib(NTGPIB.dll): warning: ignoring duplicate section `.text'
//E/cygwin/cygwin-b20/H-i586-cygwin32/i586-cygwin32/bin/ld:
ntgpib.lib(NTGPIB.dll): warning: ignoring duplicate section `.idata$5'
...
...
ntcdemo.o: In function `WinMain':
//E/Users/max/progs/WAVstuff/temp/ntcdemo.c:89: undefined reference to
`LoadCursorA@8'
//E/Users/max/progs/WAVstuff/temp/ntcdemo.c:90: undefined reference to
`GetStockObject@4'
//E/Users/max/progs/WAVstuff/temp/ntcdemo.c:93: undefined reference to
`RegisterClassA@4'
//E/Users/max/progs/WAVstuff/temp/ntcdemo.c:97: undefined reference to
`GetSystemMetrics@4'
...
...
ntcdemo.o: In function `MainMessageHandler':
//E/Users/max/progs/WAVstuff/temp/ntcdemo.c:166: undefined reference to
`GetDC@4'
//E/Users/max/progs/WAVstuff/temp/ntcdemo.c:167: undefined reference to
`GetStockObject@4'
//E/Users/max/progs/WAVstuff/temp/ntcdemo.c:168: undefined reference to
`SelectObject@8'
//E/Users/max/progs/WAVstuff/temp/ntcdemo.c:169: undefined reference to
`GetTextMetricsA@8'
...
...
//E/Users/max/progs/WAVstuff/temp/ntcdemo.c:246: undefined reference to
`DefWindowProcA@16'
collect2: ld returned 1 exit status
make: Error code 1
susato[231] $

So what is going wrong? I assume some windows libraries are not getting
linked, but how do I find out which? Why all the duplicate sections
warnings from the board vendor's library?

Assuming this code works with MSVC++ (& I have no reason to assume it
doesn't) is it possible to make it work with CYGWIN? Or do I have to get
MSVC++ to use this card I have just bought.

Thanks in advance, and Merry Christmas

Max Hadley


-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".