Message-ID: <48864AB5.6D177B25@dessent.net>
Date: Tue, 22 Jul 2008 14:01:41 -0700
From: Brian Dessent <brian AT dessent DOT net>
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>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: cygwin AT cygwin DOT com
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

Nathan Thern wrote:

You seem to have two separate issues here.

> The main executable is created with this command:
> > gcc -o scheme.exe cmpauxmd.o <other.o's> <libs>

Wait, are you saying that you need to export symbols from the executable
that will be imported by another module?  If so then the above is not
sufficient.

> cmpauxmd.o is created by:
> > ./makegen/m4.sh  cmpauxmd.m4 > cmpauxmd.s
> > as -o cmpauxmd.o cmpauxmd.s

Has this assembler file been specifically ported to PE or are you just
using the version some other platform?  The assembler directives (e.g.
the sequence for declaring and exporting a symbol) are different and
PE-specific so you can't expect this to work without porting.

> The first module fails to link as follows:
> > gcc -shared -o prbfish.dll prbfish.o <module_libs>
> --> Lots of "prbfish.o:prbfish.c: undefined reference to X" where the
> X's are symbols defined in both cmpauxmd.o and <other.o's>

How does being defined in cmpauxmd.o mean anything here?  Is cmpauxmd.o
included in <module_libs>?  I thought cmpauxmd.o was linked into the
main .exe.  Or are you just saying that the symbol should be satisfied
by some other module in <module_libs>?  I appreciate that you're trying
to make the commands as simple as possible but this abbreviation only
hides and confuses, it's best to post the exact commands and the exact
resulting error messages.

> So I tried to create a helper lib just to provide symbols for prbfish.dll:
> > gcc -shared -o libscheme.dll cmpauxmd.o <other.o's> <libs>
> --> Cannot export asm_sc_apply_generic: symbol not found
> --> several more "Cannot export"s
> All the "Cannot export" symbols are defined in cmpauxmd.o

That probably means the assembler file needs porting.  Look at the
output of a gcc generated assembler file for a simple function
declaration and make sure your hand coded file uses the same sequence of
assember directives and pseudo-ops.  For example:

$ echo "void func() {}" | gcc -S -x c - -o - -fomit-frame-pointer
        .file   ""
        .text
.globl _func
        .def    _func;  .scl    2;      .type   32;     .endef
_func:
        ret

Notice that the assembler sequence for declaring an external in PE
assembler dialect requires this ".def/.scl/.type/.endef" sequence, which
is not present in say i386 ELF where the sequence would be something
like:

$ echo "void func() {}" | gcc -S -x c - -o - -fomit-frame-pointer
        .file   ""
        .text
.globl func
        .type   func, @function
func:
        ret
        .size   func, .-func
        .ident  "GCC: (GNU) 4.4.0 20080718 (experimental)"
        .section        .note.GNU-stack,"",@progbits

(You can also tell here another difference, that i386 PE is a leading
underscore target.) 

Also, this assumes that you are going to use the GNU linker's
auto-export feature, or that you will manually specify a list of
functions to export with a .def file.  If that is not the case then you
will need to emulate the action of __declspec(dllexport), which results
in stuff added to the .drectve section:

$ echo "void __declspec(dllexport) func() {}" | \
      gcc -S -x c - -o - -fomit-frame-pointer
        .file   ""
        .text
.globl _func
        .def    _func;  .scl    2;      .type   32;     .endef
_func:
        ret
        .section .drectve

        .ascii " -export:func"


> Is my approach of building a helper lib the correct one? If so, how do
> I resolve the "Cannot export" errors?
> 
> OR ... Is there another (better) way to inform ld of the symbols in
> scheme.exe in order to succesfully link the module .dll's?

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.  Again:
the linker must be told everything at the time of linking, there is no
lazy binding.  But you may not want to actually do this because then the
resulting .dll has the filename of the .exe hardcoded into it.  I
recently wrote this reply on another list and in the interest of not
typing things twice I'll just provide a link:
<http://thread.gmane.org/gmane.comp.gnu.mingw.user/27032/focus=27033>.

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/