admin@cs.ex.ac.uk (System Administrator) (08/23/88)
I am having some problems with building gnu emacs 18.51 on our sun 3 running SunOS 4.0 and I wonder if someone can help me out. I have used s-sunos4.h which contains ---------------------------------------------------------------------- #include "s-bsd4-2.h" /* Say that the text segment of a.out includes the header; the header actually occupies the first few bytes of the text segment and is counted in hdr.a_text. */ #define O_NDELAY FNDELAY /* Non-blocking I/O (4.2 style) */ #define LD_SWITCH_MACHINE -e __start -Bstatic /* Use dk.h, not dkstat.h, in loadst.c. */ #define DK_HEADER_FILE ---------------------------------------------------------------------- Using this as it is I get an error during the linking phase of temacs _edata: ld: user attempt to redefine loader-defined symbol _end: user attempt to redefine loader-defined symbol _etext: /lib/libc.a(des_crypt.o): multiply defined so I changed the LD=ld to LD=cc and cleared the LDFLAGS macro in xmakefile. This got me almost home, i.e. it produced the xemacs file. But this core dumps on starting up. I tried a running temacs by hand temacs -l loadup.el and this seems ok. So someting must be going wrong when temacs dumps itself. Looking at the comment in s-sunos4.h file which says /* Say that the text segment of a.out includes the header; the header actually occupies the first few bytes of the text segment and is counted in hdr.a_text. */ But it DOES NOT seem to do anything about it!, unexec.c says ---------------------------------------------------------------------- * A_TEXT_OFFSET(HDR) Some machines count the a.out header as part of the size of the text segment (a_text); they may actually load the header into core as the first data in the text segment. Some have additional padding between the header and the real text of the program that is counted in a_text. For these machines, define A_TEXT_OFFSET(HDR) to examine the header structure HDR and return the number of bytes to add to `a_text' before writing it (above and beyond the number of bytes of actual program text). HDR's standard fields are already correct, except that this adjustment to the `a_text' field has not yet been made; thus, the amount of offset can depend on the data in the file. ---------------------------------------------------------------------- Shouldn't this be defined in the s-sunos4.h file? Has anyone else seen similar problems? -- -- Khalid Sattar JANET: admin@uk.ac.exeter.cs Computer Science Dept. UUCP: ukc!expya!admin University of Exeter
root@mfgfoc.UUCP (Admin) (08/26/88)
From article <611@expya.ex.ac.uk>, by admin@cs.ex.ac.uk (System Administrator): > I am having some problems with building gnu emacs 18.51 on our sun 3 > running SunOS 4.0 and I wonder if someone can help me out. > > I have used s-sunos4.h which contains > It works perfectly well here with SunOS 4.0 on a Sun-2.... here's a few tips: 1) When frustrated with any Gnu software, rm -r <gnu-dir>, reload the sources, re-configure.... in other words, start from scratch 2) Make sure you are compiling emacs with -Bstatic... I do not think that dynamically linked executables like being undumped. 3) Check your paths... very important. And give yourself lots of disk space. The major problem I had was SunOS 4.0 cc couldn't compile regex.c, lots of silly compiler loops. So I had to use gcc for that file. gcc has it's own problems with SunOS4.0... a couple of preprocessor pre-defines are not standard, and these cause problems with the new <setjmp.h> file (which preprocesses into NOTHING without those pre-defines). --Greg
willi@tubopal.uucp ( Wilhelm Koehler ) (08/26/88)
In article <611@expya.ex.ac.uk> admin@cs.ex.ac.uk (System Administrator) writes: > I am having some problems with building gnu emacs 18.51 on our sun 3 > running SunOS 4.0 and I wonder if someone can help me out. > > I have used s-sunos4.h which contains [...] > Using this as it is I get an error during the linking phase of temacs > > _edata: ld: user attempt to redefine loader-defined symbol > _end: user attempt to redefine loader-defined symbol > _etext: /lib/libc.a(des_crypt.o): multiply defined > > so I changed the LD=ld to LD=cc and cleared the LDFLAGS macro in > xmakefile. This got me almost home, i.e. it produced the xemacs > file. But this core dumps on starting up. I tried a running temacs by > hand In comp.sys.sun there were two postings concerning the static version of libc.a in SunOS 4.0 on Sun 3. Mark Mendell <mendell@turing.toronto.edu> writes This brings up the first minor problem. When the static library for 4.0 export was made, they messed up the following routines: des_crypt.o des_soft.o _crypt.o auth_des.o svcauth_des.o They are obviously completely linked, as the are about 24K in size, and define _end, _edata, and _etext. This means the -Bstatic won't work until these routines are removed from the library and it is ranlib-ed. A related problem is that the 'newkey' program will fail at runtime with a message that the routine '_cbc_crypt' cannot be found. I assume that the problems are both due to export restrictions. Kevin J. Maciunas <munnari!cs.flinders.oz.au!kevin@uunet.uu.net> stated the same. Clearing the LDFLAGS results in the default -Bdynamic ld-Option so that temacs will not be able to dump itself correctly. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Wilhelm Koehler Tel.: +49 30 314 24785 TU Berlin FB-20 Sekr. FR 5-6 UUCP: ...!unido!tubopal!willi Franklinstr. 28/29 BITNET: willi@db0tui62 || KOEHLER@db0tui11 1000 Berlin (West) 10
schwartz@blitz (Scott E. Schwartz) (08/27/88)
In article <400@mfgfoc.UUCP> root@mfgfoc.UUCP (Admin) writes: >It works perfectly well here with SunOS 4.0 on a Sun-2.... here's a few >tips: I've used 18.51 on a Sun-3 and it works fine too. > 2) Make sure you are compiling emacs with -Bstatic... I do not > think that dynamically linked executables like being > undumped. This is the case. Notice, though, that NMAGIC executables (which is what you get if you do -Bstatic and don't ask for OMAGIC) no longer have their text segments shared. Doesn't this mean that memory usage will increse drastically? I try to encourage people to use gnu-emacs, and a key argument is that most of that 1M executable is (was) shared among lots of users. Let's all work on getting -Bdynamic working!
daveg@coho.UUCP (Dave Gagne) (08/28/88)
In article <611@expya.ex.ac.uk>, admin@cs.ex.ac.uk (System Administrator) writes: > I am having some problems with building gnu emacs 18.51 on our sun 3 > running SunOS 4.0 and I wonder if someone can help me out. > > I have used s-sunos4.h which contains So far so good. > _edata: ld: user attempt to redefine loader-defined symbol > _end: user attempt to redefine loader-defined symbol > _etext: /lib/libc.a(des_crypt.o): multiply defined > > so I changed the LD=ld to LD=cc and cleared the LDFLAGS macro in No need to do this. > Has anyone else seen similar problems? Yes indeed. Anyone who does not live in the jolly US of A. > Khalid Sattar JANET: admin@uk.ac.exeter.cs > Computer Science Dept. UUCP: ukc!expya!admin > University of Exeter What you are encountering is a screw-up in SunOS 4.0_Export. This problem only occurs in the "EXPORT" version of SunOS 4.0: ie the software which Sun ships outside of the USA. The problem has something to do with Sun not wanting to ship their DES chips outside of the good 'ole USA. What we poor foreigners get instead is some buggered up software. What all this means is that "cc -Bstatic ..." WILL NOT WORK ON SUNOS 4.0 EXPORT without a little help from "ar". The static C-library is /lib/libc.a, and this is where the problem occurs. There are a bunch of .o files in there relating to DES stuff (des_crypt.o, des_soft.o, _crypt.o, etc). All of them will case cc -Bstatic to die as you found with the errors: > _edata: ld: user attempt to redefine loader-defined symbol > _end: user attempt to redefine loader-defined symbol > _etext: /lib/libc.a(des_crypt.o): multiply defined In order to make cc -Bstatic useful, you must remove all the brain-damaged .o files from /lib/libc.a. To do this use ar d /lib/libc.a des_crypt.o des_soft.o _crypt.o .... (Make a backup of /lib/libc.a first, you may decide you need the "real" thing someday). Note that there are a bunch of these files, I can't remember all of them. You will find them quick enough by trying to compile ANY C program, even one which does NOTHING. After you have done this, Emacs should compile OK. I was able to get both the "normal" text version and the X-windows (X11R2) version to compile OK. It seems to me that the Suntools version may not have worked, but I may just be halucinating. Dave. -- +---------------------------------------------------------------------------+ | Dave Gagne. UBC VLSI Salmon Net o /\ /\ | | _____ o \ / \ | | daveg@ee.ubc.ca \/ o\_o \ / \ | | daveg%ee.ubc.ca@relay.ubc.ca /\_____/ \ / \ | | daveg@ee.ubc.cdn%ean.ubc.ca@RELAY.CSNET \/ \ | +---------------------------------------------------------------------------+