Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Message-ID: <20011003082612.26332.qmail@web14501.mail.yahoo.com>
Date: Wed, 3 Oct 2001 18:26:12 +1000 (EST)
From: =?iso-8859-1?q?Danny=20Smith?= <danny_r_smith_2001 AT yahoo DOT co DOT nz>
Subject: Re: DLL Win 2000
To: lyndell DOT l DOT asbenson AT intel DOT com
Cc: Cygwin <cygwin AT cygwin DOT com>
In-Reply-To: <3BBA9D57.5050109@ece.gatech.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

 --- Charles Wilson <cwilson AT ece DOT gatech DOT edu> wrote: > Danny Smith
wrote:
> >  --- Charles Wilson <cwilson AT ece DOT gatech DOT edu> wrote: > > 
> > 
> > 
> >>The problem is, MS .obj format files are NOT compatible with
> gcc/ld. 
> >>I'm really surprised you were able to link at all.
> >>
> >>
> > 
> > This is news to me. As long as the obj file has no dependency on
> static
> > MS runtime (or other MS static lib), on MS debug heap  or on C++
> > references they work, with mingw or with -mno-cygwin option.  The
> other
> > gotcha is struct layout, which can be fixed with -fnative-struct
> > option.
> 
> Ding!
> 
> 
> > 
> > The usual problem however is dependency on MS libc[mt].lib
> > 
> 
> And another ding!
> 
> What you're saying is, that *theoretically* you can use a .obj file
> with 
> gcc .o's -- but in practice it's rarely possible.  (1) you have to be
> 
> careful to use -fnative-struct with your gcc compiliation, 

In my experience this is usually not necessary.  Turn on -pedantic
warnings and the compiler will point you to potential bit-field
problems

(2) only
> .obj 
> files that make NO references to ANY runtime functions (open, fopen, 
> printf, etc) are usable.

Not quite true. Import of global variables from static libs or memory
allocation functions from static libs cause problems.  _alloca is the
main culprit.

My experience, in practice, is that some very useful *.obj's and *.libs
work with -mno-cygwin. One, in particular, is Intel's blas and cblas
kernel.  Also Intels's optimised jpeg lib.  I have used other
open-source math libs built by msvc++ or compaq fortran in preference
to gcc-built ones for floating point performance reasons.     

> 
> That's a lot of restrictions.  Wouldn't it be nice if the gpib IO
> card 
> manufacturer released their @#$@!& source, instead of distributing
> .obj 
> files?
> 
Well they do distribute Visual Basic source, so one could translate
into C.

Have you tried gpib-32.obj(which is the static obj file provided as
part of the MSVC++ 32 bit interface  for NI-488.2 API).  It 
should be useable, as is, by  -mno-cygwin and by mingw. The only
dependencies are on functions within msvcrt.dll or the w32api.
Objdump groks the symbols in the obj, so does ld.  I quickly built two
of the test apps (ScopeSimple and FindInstruments) They both copiled
and linked without problem.   When I ran the programmes, they told me
they couldn't find any instruments, which is true, and reported the
values of global variables.    Looking at the header, there is no need
for -fnative-struct.   



Danny



http://travel.yahoo.com.au - Yahoo! Travel
- Got Itchy feet? Get inspired!

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/