This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: module problems on cygwin


well then, how do you build import libraries under cygwin?

----- Original Message -----
From: "Larry Hall (RFK Partners, Inc)" <lhall@rfk.com>
To: "Ben Wing" <ben@666.com>; "Jerry James" <james@xemacs.org>;
<Robinows@aol.com>
Cc: <xemacs-beta@xemacs.org>; <cygwin@cygwin.com>
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                              lhall@rfk.com
> 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" <james@xemacs.org>
> >To: <Robinows@aol.com>
> >Cc: <ben@666.com>; <xemacs-beta@xemacs.org>
> >Sent: Monday, October 28, 2002 5:46 AM
> >Subject: Re: module problems on cygwin
> >
> >
> > > Robinows@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/
>
>



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]