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

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" <james(a)xemacs.org&gt; To: <Robinows(a)aol.com&gt; Cc: <ben(a)666.com>; <xemacs-beta(a)xemacs.org&gt; Sent: Monday, October 28, 2002 5:46 AM Subject: Re: module problems on cygwin > Robinows(a)aol.com 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/