NU013809@NDSUVM1.BITNET (Greg Wettstein) (08/19/90)
I had some free time yesterday and I decided to upgrade our version of GNU
EMACS from 18.54 to 18.55 and in the process change the compiler from the
Microsoft version to GCC which I have been using for about three months.
Everything went well until the makefile called the loader to compile temacs.
The loader chugged away for awhile and then spit out the following list
of unresolved externals and the modules they occur in.
For the life of me I can't figure out where they are coming from. I have
searched the source code files and haven't found any references to these
variables. I have also compiled the offending source modules with the -S
switch and searched the assemble source to find out if they are something
GCC or GAS happened to sneak in there. I could not find any reference to
to them in the object libraries either. I suspect that they have something
to do with floating point but I haven't a clue on how to make them go
away. Any suggestions would be deeply appreciated.
___fixdfsi (fns.c)
___divsi3 (data.c indent.c cm.c term.c window.c xdisp.c scroll.c dispnew.c)
___floatsidf (fns.c)
___udivsi3 (malloc.)
___muldf3 (fns.c)
___divdf3 (fns.c)
As always,
Dr. G.W. Wettstein
Roger Maris Cancer Center Computing Facility
UUCP: uunet!plains!wind!greg
INTERNET: greg%wind.uucp@plains.nodak.edu
Phone: 701-234-2833
`The truest mark of a man's wisdom is his ability to listen to other
men expound their wisdom.'NU013809@NDSUVM1.BITNET (Greg Wettstein) (08/21/90)
I wanted to send a note to thank everyone who came up with the reason why
the loader was failing with an unresolved externals message when EMACS
was being compiled with gcc.
The problem was as most people predicted it would be and that was the failure
to include the GNU `helper' routines. When I poked around in the gcc
distribution that I FTP'ed from robobar I found the routines in an object
library called gcc-gnulib. Appending a -lgcc-gnulib to the makefile resulted
in a clean compilation and load of EMACS.
EMACS seems to run very well compiled under gcc and the resulting exectuable
was about 13129 bytes smaller than the executable produced by the Microsoft
compiler. In the scope of a half-a-megabyte executable this is probably not
really significant but is offered as a point of interest.
As long as we are discussing GCC and EMACS I was wondering if anyone had
the patches which are needed to make EMACS work properly with select under
XENIX 2.3.2. I seem to remember some patches floating by in this newsgroup
but I haven't been able to locate them. Any pointers to where they might
be found would be appreciated. Thanks once again for the previous answers
and anything that might be forthcoming on select.
As always,
Dr. G.W. Wettstein
Roger Maris Cancer Center Computing Facility
UUCP: uunet!plains!wind!greg
INTERNET: greg%wind.uucp@plains.nodak.edu
Phone: 701-234-2833
`The truest mark of a man's wisdom is his ability to listen to other
men expound their wisdom.'ronald@robobar.co.uk (Ronald S H Khoo) (08/22/90)
In article <4540NU013809@NDSUVM1> NU013809@NDSUVM1.BITNET (Greg Wettstein) writes: > When I poked around in the gcc > distribution that I FTP'ed from robobar Hah. I *wish* you could have FTP'd _anything_ from robobar. We don't have Internet access (sob!) You must have got it from one of our friends... > EMACS seems to run very well compiled under gcc and the resulting exectuable > was about 13129 bytes smaller Hm.. did you remember to remove alloca.o from the link command line in the Makefile ? it would have saved you another 30 whole bytes !! (:-) > I was wondering if anyone had > the patches which are needed to make EMACS work properly with select under > XENIX 2.3.2. I don't think you need much. I recall just enabling one of the HPUX defines which used 0 instead of the except_fd's to get it to work (having defined HAVE_SELECT as well, of course). No guarantees, this was a while back. Then I took it out again because it doesn't work under SXT's and I'd rather have job control than select() right at the moment. It might be nice to be able to select which select() to use at run time, so if (running under an sxt) { use emacs fake select() } else { use real select() } but that was more than a one line hack, so I haven't got round to it. (Anyone at SCO interested in making sxt's work with select() ? :-) That would be the _real_ solution, of course.) Defining HAVE_PTYS was really useful though. The only use I have for EMACS is as a window system for GDB -- I'm from the vi camp -- and M-x gdb is pretty hopeless without HAVE_PTYS. Doesn't work under 2.3.1 though. -- Eunet: Ronald.Khoo@robobar.Co.Uk Phone: +44 81 991 1142 Fax: +44 81 998 8343 Paper: Robobar Ltd. 22 Wadsworth Road, Perivale, Middx., UB6 7JD ENGLAND.
chip@tct.uucp (Chip Salzenberg) (08/24/90)
According to ronald@robobar.co.uk (Ronald S H Khoo): >Defining HAVE_PTYS was really useful though. The only use I have for >EMACS is as a window system for GDB -- I'm from the vi camp -- and M-x >gdb is pretty hopeless without HAVE_PTYS. Doesn't work under 2.3.1 >though. In March 1989, I posted a pty driver for SCO Xenix. It's different from SCO's pty driver because it works -- it knows how to do non-blocking reads from the master side, so it works with Emacs even if you don't use select(). I left SCO's ptys as /dev/ttyp? and told Emacs to use the ones that work, which I named /dev/ttyc?. The drivers I posted should be available from comp.sources.misc archives everwhere. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip>