paul@uunet.uu.net (Paul Nordstrom) (05/26/90)
In article <7892@brazos.Rice.edu> you write: > >I am using Sun's "X/Open compatiblity package", OpenWindows 1.0.1, for X >support. X seems to work OK, except when i try to compile CLX (common lisp >interface to X) under Austin Kyoto Common Lisp, I get the following error: > > >(xlib:compile-clx) > ;;; Default paths: #"" #"" > ;;; cc -c socket.c -o socket.o -DUNIXCONN > Compiling sockcl.lsp. > End of Pass 1. > End of Pass 2. > OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3 > Finished compiling sockcl.o.ld: sockcl.o: bad secondary magic number > > Error: The linkage editor failed. > Error signalled by SYSTEM:FASLINK. I had the same problem with my Oregon C++ compiler. In my case, the compiler was writing out object files in 512 byte blocks (for efficiency). At the end of the object code, the compiler just zero filled to the end of the 512 byte block. New to the SunOS 4.1 object file format there is some additional junk after the symbol table (possibly to support a browser or something, maybe?). Anyway, this additional info is protected by a magic number, hence the error message "bad secondary magic number". In my case, the solution was very simple: all I had to do was to write a short program to truncate the object file at the end of the symbol table. If you would like, I could send the code. Note that I also had to tear apart the libraries, truncate the object files therein, and rebuild them. If you look at your object files (I used bpatch) and see a lot of binary zeros at the end, I would think that that is your problem as well. Hope this helps. Paul Nordstrom Gill & Co., L.P. uunet!gill!paul
jdp@uunet.uu.net (John Polstra) (05/31/90)
In article <8187@brazos.Rice.edu> gill!paul@uunet.uu.net (Paul Nordstrom) writes: > New to the SunOS 4.1 object file format there is some additional junk > after the symbol table (possibly to support a browser or something, > maybe?). Anyway, this additional info is protected by a magic number, > hence the error message "bad secondary magic number". Bad news! That probably means that ICON programs won't run under 4.1. ICON (as I understand it) builds an OMAGIC executable and sticks the code to be processed by the interpreter at the end of the executable file. Has anybody tried running ICON programs under 4.1? John Polstra jdp@polstra.uucp Polstra & Co., Inc. practic!polstra!jdp@uunet.uu.net Seattle, Washington USA ...{uunet,sun,pyramid}!practic!polstra!jdp (206) 932-6482