X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Message-ID: <488678FD.1F211496@dessent.net>
Date: Tue, 22 Jul 2008 17:19:09 -0700
From: Brian Dessent <brian AT dessent DOT net>
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
MIME-Version: 1.0
To: Nathan Thern <nthern AT gmail DOT com>
CC: cygwin AT cygwin DOT com
Subject: Re: .s file causing problems when linking
References: <a07c15f00807221329k544d2079ia14421e724fe6fd AT mail DOT gmail DOT com> 	 <48864AB5 DOT 6D177B25 AT dessent DOT net> <a07c15f00807221617o20061c0dy135f955181472469 AT mail DOT gmail DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Reply-To: cygwin AT cygwin DOT com
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Nathan Thern wrote:

> I'm following the build instructions for generic x86 *nix, going under
> the assumption that cygwin fits in that category. I believe the

Cygwin can't change the fact that fundamentally these are different
operating systems, so for example linking works differently as does the
way symbols are declared at the assembler level.  Assembly is pretty
much the antithesis of portability so you can't expect this to work
without some porting.

> > It is possible to export symbols from the .exe and then import them from
> > a .dll, but it takes more than what you're doing here, namely creating
> > an import library for the .exe and linking the dll against that.

> That is precisely what I tried to do: create a dll from the same .o's
> that created the .exe.

But that's not really going to work.  You can't fake it like that.  What
you're doing is creating another library.

> I am still not sure my way forward is the best one. Let me re-state it:
> I have an executable, scheme.exe, created from object files. A module
> library, prbfish.dll fails to link because it needs symbols that are
> in scheme.exe. I create a fake library, libfoo.dll, from the
> scheme.exe object files like so:
> > gcc -shared -o libfoo.dll *.o -Wl,--out-implib,libfoo.dll.a

That might get the library to link, but at runtime it does *not* mean
that prbfish.dll will call the routines in scheme.exe.  Rather,
prbfish.dll will be created with a hardcoded reference to libfoo.dll and
will fail to run if libfoo.dll is not present -- this fake library is
not fake, it is a real library, and it duplicates code in scheme.exe so
it's probably useless and broken.

Please read that link which has examples of how to actually export
symbols from an .exe and link the dll that imports them.  If you have
the luxury of linking the .exe first then you can skip all the .def file
junk because you can simply create an import library for the .exe as a
side effect of linking it (-Wl,--out-implib) and then use that when
linking prbfish.dll.  The only reason you'd ever need a .def file in
this case is if you have a circular dependency where you can't link one
without the other.

Brian

--
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/