well then, how do you build import libraries under cygwin? ----- Original Message ----- From: "Larry Hall (RFK Partners, Inc)" <[EMAIL PROTECTED]> To: "Ben Wing" <[EMAIL PROTECTED]>; "Jerry James" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, October 29, 2002 7:04 AM Subject: Re: module problems on cygwin
> Sounds to me like you're expecting too much, at least for Windows. On > Windows, the closest thing to shared libraries are DLLs and these require > all references to be resolved at build-time. That's generally done by > providing "import libraries" with stubs to all the calls that will be > resolved to other DLLs (at run-time). So you can't have unresolved external > references using gcc during builds on Windows, even under Cygwin. Cygwin > can't replace the Windows linker/loader so we're all stuck with it's behavior > as is. > > Larry Hall [EMAIL PROTECTED] > RFK Partners, Inc. http://www.rfk.com > 838 Washington Street (508) 893-9779 - RFK Office > Holliston, MA 01746 (508) 893-9889 - FAX > > > > At 03:12 AM 10/29/2002, Ben Wing wrote: > >cygwin is not terribly windows-specific. it's basically unix, and runs all the > >standard gcc suite of tools, so if you understand shared libraries under Unix, > >you understand them under gcc. > > > >the failures are unresolvable references to the various functions in the XEmacs > >executable. clearly the XEmacs executable is not around, and so these are > >indeed unresolvable. the man pages claim that this is ok, and they will be > >resolved by the run-time linker, but for some reason it's still complaining. > >any help here? > > > >to the cygwin guys: we're trying to create separate modules that can be loaded > >once the program has started. they are build as shared libraries, and of course > >contain references to the main executable. Under Cygwin, both gcc-2 and gcc-3, > >when the .o files are linked into the library (called something like > >postgres.ell), done using essentiall just `gcc -shared', we get tons of > >unresolved externals warnings for all the references to the main executable. > >this obviously shouldn't happen -- the unresolved references should be allowed, > >and the run-time linker should fix them up. what's going wrong here? > > > > > >----- Original Message ----- > >From: "Jerry James" <[EMAIL PROTECTED]> > >To: <[EMAIL PROTECTED]> > >Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > >Sent: Monday, October 28, 2002 5:46 AM > >Subject: Re: module problems on cygwin > > > > > > > [EMAIL PROTECTED] wrote: > > > > ./configure --with-x=no --pdump --with-postgresql=no > > > > works fine for me with gcc or gcc-2. > > > > Removing the "with-postgresql=no" fails with either gcc or gcc-2. > > > > > > I am away at a conference this week. I can get access to my email from > > > here, but I am working in console mode over a bandwidth-limited pipe > > > (and using an AZERTY keyboard, which is driving me bananas). I won't be > > > able to do much coding until I return, but I should be able to answer > > > questions. > > > > > > I freely confess that I do not understand either native Windows or > > > cygwin, so I will need some help figuring out what to do. I already > > > pointed out that the new module setup is broken on native Windows, so > > > this means that it is broken on both Windows platforms. Ben posted his > > > ellcc.h, which has newlines in strange places. Do other cygwin users > > > have similar ellcc.h files? For comparison purposes, here is mine from > > > a RedHat Linux 7.3 machine. > > > > > > /* DO NOT EDIT THIS FILE!!!! */ > > > > > > /* Most of this is required due to a bug in the GCC compiler driver > > > which prevents us from passing this on the command line. It also > > > reduces the compiler command line length, which can be a problem > > > on some systems. */ > > > > > > #ifndef ELLCC_HDR > > > #define ELLCC_HDR > > > > > > #define ELLCC_CC "gcc" > > > #define ELLCC_CFLAGS "-march=i686 -O2 -g" > > > #define ELLCC_CPPFLAGS "" > > > #define ELLCC_LDFLAGS " " > > > #define ELLCC_CF_GENERAL "-DHAVE_CONFIG_H" > > > #define ELLCC_CF_ALL "-DHAVE_CONFIG_H -I/usr/X11R6/include" > > > #define ELLCC_LF_GENERAL "" > > > #define ELLCC_LF_ALL "-L/usr/X11R6/lib" > > > #define ELLCC_LIBS_GENERAL > > "-ldb -lgpm -lncurses -L/usr/lib -lesd -laudiofile -lm -lm -lutil" > > > #define ELLCC_DLL_CFLAGS "-fPIC" > > > #define ELLCC_DLL_LDFLAGS "-shared" > > > #define ELLCC_DLL_POST "" > > > #define ELLCC_DLL_LD "gcc" > > > #define ELLCC_DLL_LDO "-o" > > > #define ELLCC_CONFIG "i686-pc-linux" > > > #define ELLCC_EMACS_VER "21.5-b9" > > > #define ELLCC_PROGNAME "xemacs" > > > #define ELLCC_ARCHDIR "/usr/local/test/lib/xemacs-21.5-b9/i686-pc-linux" > > > #define ELLCC_MODDIR > >"/usr/local/test/lib/xemacs-21.5-b9/i686-pc-linux/modules" > > > #define ELLCC_SITEMODS "/usr/local/test/lib/xemacs/site-modules" > > > > > > #endif /* ELLCC_HDR */ > > > > > > -- > > > Jerry James > > > http://www.ittc.ku.edu/~james/ > > > > > > > > > > >-- > >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/ > > -- 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/
