Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
From: "Gregory Lampshire" <gregory_lampshire AT hotmail DOT com>
To: <cygwin AT cygwin DOT com>
Subject: gcc -shared under 2.95.3-5, unable to convert .o to .dll via -shared flag
Date: Sun, 30 Dec 2001 08:32:22 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-ID: <OE46C2Dhd9FdIbHvh2d000072d9@hotmail.com>


 I am working on getting shared library support to work with the latest ecls
 release (embedded common lisp).  The standard ecls distribution uses
 dlopen() calls to dynamically load object code.  Using the latest
 dllhelpers, it seems that the -shared flag works quite nicely for building
 shared libraries.  I also modified one of the dllhelper examples to produce
 a dll that is loaded via dlopen and accessed via dlsym(), everything works
 great.


 The ecls build procedure, however, requires the ability to generate the
 shared object code via gcc from the object code file itself.  It converts,
 for example, a file called export.o to export.so (on Linux) via
 "gcc -shared -o export.so -L./ export.o"  The command then creates a .so
 file and appends, of course, the proper init code to work correctly.

 On Cygwin, however, while the dllhelper's examples work fine, when I try to
 generate a ".so" file (really the .dll), via the same command, I get
 unresolved linker errors.  Interestingly, the same process works for in my
 modified dllhelpers example (converting a plain old .o file to a .dll via
 the -shared switch, object file to object file)   The command under the
ecls
 build fails because there are external symbols in the object file that it
 cannot resolve--my dllhelpers example is completely self-contained.  The
 ecls gcc -shared command works on a Linux box but not on the Cygwin box.

 I am looking for some insight into the issues about what is going on and a
 work around.


 The same command works okay under Linux.  Here's the verbose output with
 export.dll stuck in instead of export.so as the output file.

 $ gcc -shared -o export.dll -L./ export.o
 Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/specs
 gcc version 2.95.3-5 (cygwin special)

 /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/collect2.exe --shared -Bdynamic -e
 __cygwin_dll_entry AT 12 --dll-search-prefix=cyg -o

export.dll -L../ -L./ -L/usr/local/lib -L/usr/lib -L/usr/lib/w32api -L/usr/l
 ib/gcc-lib/i686-pc-cygwin/2.95.3-5 -v
 export.o -lgcc -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc
 collect2 version 2.95.3-5 (cygwin special) (80386, BSD syntax)

/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/../../../../i686-pc-cygwin/bin/ld -
 -shared -Bdynamic -e __cygwin_dll_entry AT 12 --dll-search-prefix=cyg -o

export.dll -L../ -L./ -L/usr/local/lib -L/usr/lib -L/usr/lib/w32api -L/usr/l
 ib/gcc-lib/i686-pc-cygwin/2.95.3-5 -v
 export.o -lgcc -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc
 export.o: In function `init_LSP_EXPORT':
 /e/tmp/sandbox/ecls/build/lsp/export.h:66: undefined reference to
 `siLselect_package'
 /e/tmp/sandbox/ecls/build/lsp/export.h:67: undefined reference to `Ct_body'
 /e/tmp/sandbox/ecls/build/lsp/export.h:67: undefined reference to
 `clVprint_circle'
 /e/tmp/sandbox/ecls/build/lsp/export.h:67: undefined reference to `set'
 /e/tmp/sandbox/ecls/build/lsp/export.h:68: undefined reference to
 `clLexport'
 [snip]


 Under Linux, the linker gets the -shared option but no -Bdynamic and it
 completes okay.


 cheers,
gregory


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