Has anyone actually built emacs 21.3 for SOLARIS (sparc)?
David Combs
load, etc -- and am getting complaints about a missing
lib:
../lisp/textmodes/text-mode.elc ../lisp/vc-hooks.elc ../lisp/ediff-hook.elc ../lisp/widget.elc ../lisp/window.elc ../lisp/version.el
LC_ALL=C ./temacs -batch -l loadup dump
ld.so.1: ./temacs: fatal: libXaw3d.so.5: open failed: No such file or directory
Killed
make[1]: *** [emacs] Error 137
make[1]: Leaving directory `/big5/david3/from_netcom-dir2/sources-stuff/emacs-21.3/src'
make: *** [src] Error 2
358.0 sys= 18.0 96% || mem=0 in=0
137 ==/david3/from_netcom-dir2/sources-stuff/emacs-21.3==>
(Note: Im trying to communicate with ONLY those people
who've put emacs-21.3 up on Solris!
Thanks!
David
Dave Uhring
> I'm having difficulties getting emacs 21.3 to compile,
> load, etc -- and am getting complaints about a missing
> lib:
>
> ../lisp/textmodes/text-mode.elc ../lisp/vc-hooks.elc ../lisp/ediff-hook.elc ../lisp/widget.elc ../lisp/window.elc ../lisp/version.el
> LC_ALL=C ./temacs -batch -l loadup dump
> ld.so.1: ./temacs: fatal: libXaw3d.so.5: open failed: No such file or directory
> Killed
> make[1]: *** [emacs] Error 137
> make[1]: Leaving directory `/big5/david3/from_netcom-dir2/sources-stuff/emacs-21.3/src'
> make: *** [src] Error 2
> 358.0 sys= 18.0 96% || mem=0 in=0
> 137 ==/david3/from_netcom-dir2/sources-stuff/emacs-21.3==>
Then why do you not install that library if you wish to use it?
You certainly have the option in the ./configure script to choose motif
instead of Xaw3d.
> (Note: Im trying to communicate with ONLY those people
> who've put emacs-21.3 up on Solris!
I run Solaris 9, not Solris. Does that disqualify my comments?
BTW that release of emacs builds without error on Ultra 1 if a bit slowly.
[emacs-21.3]$ ./configure --prefix=/usr/sfw --with-x-toolkit=motif
--with-xpm --with-jpeg --with-tiff --with-gif --with-png --with-x
[emacs-21.3]$ time gmake
[ ... ]
real 21m49.492s
user 20m55.430s
sys 0m25.130s
Stefan Monnier
> I'm having difficulties getting emacs 21.3 to compile,
> load, etc -- and am getting complaints about a missing
> lib:
> ../lisp/textmodes/text-mode.elc ../lisp/vc-hooks.elc ../lisp/ediff-hook.elc ../lisp/widget.elc ../lisp/window.elc ../lisp/version.el
> LC_ALL=C ./temacs -batch -l loadup dump
> ld.so.1: ./temacs: fatal: libXaw3d.so.5: open failed: No such file or directory
> Killed
> make[1]: *** [emacs] Error 137
> make[1]: Leaving directory `/big5/david3/from_netcom-dir2/sources-stuff/emacs-21.3/src'
> make: *** [src] Error 2
> 358.0 sys= 18.0 96% || mem=0 in=0
> 137 ==/david3/from_netcom-dir2/sources-stuff/emacs-21.3==>
Try
setenv LD_LIBRARY_PATH /opt/sfw/lib/
-- Stefan
Dave Uhring
> Try
> setenv LD_LIBRARY_PATH /opt/sfw/lib/
Bogus, totally bogus!
Bijan Soleymani
I've gotten version 21.2, 21.3 and CVS of emacs to compile on
solaris/slowlaris.
Looks like you've got problems with libXaw3d.
You should look for xaw3d in /etc/PROBLEMS. Here is what I found:
"
* On systems with shared libraries you might encounter run-time errors
from the dynamic linker telling you that it is unable to find some
shared libraries, for instance those for Xaw3d or image support.
These errors mean Emacs has been linked with a library whose shared
library is not in the default search path of the dynamic linker.
Similar problems could prevent Emacs from building, since the build
process invokes Emacs several times.
On many systems, it is possible to set LD_LIBRARY_PATH in your
environment to specify additional directories where shared libraries
can be found.
Other systems allow to set LD_RUN_PATH in a similar way, but before
Emacs is linked. With LD_RUN_PATH set, the linker will include a
specified run-time search path in the executable.
"
Hope that helps,
Bijan
Dave Uhring
> Looks like you've got problems with libXaw3d.
>
> You should look for xaw3d in /etc/PROBLEMS. Here is what I found:
>
> "
> * On systems with shared libraries you might encounter run-time errors
> from the dynamic linker telling you that it is unable to find some
> shared libraries, for instance those for Xaw3d or image support.
> These errors mean Emacs has been linked with a library whose shared
> library is not in the default search path of the dynamic linker.
Solaris is an ELF system. The library search path is supposed to be in
the headers of the binary. It gets put there by using the proper LDFLAGS
during the compile time link.
[emacs-21.3]$ echo $LD_LIBRARY_PATH $LD_RUN_PATH
[emacs-21.3]$ ldd src/emacs-21.3.1
libXm.so.4 => /usr/dt/lib/libXm.so.4
libgen.so.1 => /usr/lib/libgen.so.1
libXp.so.1 => /usr/openwin/lib/libXp.so.1
libXmu.so.4 => /usr/openwin/lib/libXmu.so.4
libXt.so.4 => /usr/openwin/lib/libXt.so.4
libSM.so.6 => /usr/openwin/lib/libSM.so.6
libICE.so.6 => /usr/openwin/lib/libICE.so.6
libXext.so.0 => /usr/openwin/lib/libXext.so.0
libtiff.so.3 => /usr/sfw/lib/libtiff.so.3
libjpeg.so.62 => /usr/sfw/lib/libjpeg.so.62
libpng.so.2 => /usr/sfw/lib/libpng.so.2
libz.so.1 => /usr/lib/libz.so.1
libm.so.1 => /usr/lib/libm.so.1
libXpm.so.4 => /usr/openwin/lib/libXpm.so.4
libX11.so.4 => /usr/openwin/lib/libX11.so.4
libsocket.so.1 => /usr/lib/libsocket.so.1
libnsl.so.1 => /usr/lib/libnsl.so.1
libkstat.so.1 => /usr/lib/libkstat.so.1
libcurses.so.1 => /usr/lib/libcurses.so.1
libc.so.1 => /usr/lib/libc.so.1
libdl.so.1 => /usr/lib/libdl.so.1
libmp.so.2 => /usr/lib/libmp.so.2
/usr/platform/SUNW,Ultra-1/lib/libc_psr.so.1
> Similar problems could prevent Emacs from building, since the build
> process invokes Emacs several times.
>
> On many systems, it is possible to set LD_LIBRARY_PATH in your
> environment to specify additional directories where shared libraries
> can be found.
Go back and re-read my previous post in the other branch of this thread.
> Other systems allow to set LD_RUN_PATH in a similar way, but before
> Emacs is linked. With LD_RUN_PATH set, the linker will include a
> specified run-time search path in the executable.
Completely unnecessary. Learn something about the OS before posting such
nonsense.
> Hope that helps,
It merely confuses and confounds the misimpressions you Linux users have
about UNIX.
David Combs
Thanks!
My "make" got as far as creating "temacs", for
which ldd on gives:
libXaw3d.so.5 => (file not found)
libXmu.so.4 => /usr/openwin/lib/libXmu.so.4
libXt.so.4 => /usr/openwin/lib/libXt.so.4
libSM.so.6 => /usr/openwin/lib/libSM.so.6
libICE.so.6 => /usr/openwin/lib/libICE.so.6
libXext.so.0 => /usr/openwin/lib/libXext.so.0
libXpm.so.4 => /usr/openwin/lib/libXpm.so.4
libX11.so.4 => /usr/openwin/lib/libX11.so.4
libsocket.so.1 => /usr/lib/libsocket.so.1
libnsl.so.1 => /usr/lib/libnsl.so.1
libkstat.so.1 => /usr/lib/libkstat.so.1
libcurses.so.1 => /usr/lib/libcurses.so.1
libm.so.1 => /usr/lib/libm.so.1
libc.so.1 => /usr/lib/libc.so.1
libdl.so.1 => /usr/lib/libdl.so.1
libmp.so.2 => /usr/lib/libmp.so.2
/usr/platform/SUNW,Sun-Blade-100/lib/libc_psr.so.1
Why does mine want the 3d thing, and yours doesn't?
Also, you did that echo of the two LD_..._PATHs, and
showed nothing for what typed out.
Here's what I get:
84 ==/dkcjunk==> echo $LD_RUN_PATH
LD_RUN_PATH: Undefined variable
85 ==/dkcjunk==> echo $LD_LIBRARY_PATH
LD_LIBRARY_PATH: Undefined variable
86 ==/dkcjunk==>
A prior answer said to define the first one as
/usr/openwin/lib.
Is that your opinion too?
And what about the RUN path -- set it to what?
(The last time I dealt with these concepts was
way back on dec-20 twenex; since then I've been
using a language no one's ever heard of (Mainsail)
that works entirely differently, doesn't even
use ld, does such things its own (also nice) way.)
Thanks!
David
PS: your opinion on those configure-args suggested in that
same post? Any changes, or use as-is.
James Carlson
> (The last time I dealt with these concepts was
> way back on dec-20 twenex; since then I've been
> using a language no one's ever heard of (Mainsail)
> that works entirely differently, doesn't even
> use ld, does such things its own (also nice) way.)
You're kidding, right? ;-}
I spent quite a bit of time coding chip simulations at DG in Mainsail
for the VTI tools we used. Sort of a nifty string-based language that
reminded me a bit (at the time) of REXX.
I'll bet there are more than a few others out here ...
--
James Carlson, Solaris Networking <james.d...@east.sun.com>
Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677
Dave Uhring
> libXaw3d.so.5 => (file not found)
> Why does mine want the 3d thing, and yours doesn't?
Probably because I enabled motif instead of Xaw3d when I ran the configure
script. Do you really want the Athena widget set? Is that library
actuallly on your system? Where? If it's in /opt/sfw/lib then your
environment should contain
[duhring]$ echo $LDFLAGS
-L/usr/openwin/lib -R/usr/openwin/lib -L/opt/sfw/lib -R/opt/sfw/lib
before running the configure script.
> Also, you did that echo of the two LD_..._PATHs, and
> showed nothing for what typed out.
A blank line appeared because I do not have either of those values set in
my environment. I do not require them for any of the software which I
have built on this machine. Neither are they required for the OS software
supplied by Sun; they built those binaries with the correct LDFLAGS in the
compiler user's environment.
> Here's what I get:
>
>
> 84 ==/dkcjunk==> echo $LD_RUN_PATH
> LD_RUN_PATH: Undefined variable
> 85 ==/dkcjunk==> echo $LD_LIBRARY_PATH
> LD_LIBRARY_PATH: Undefined variable
> 86 ==/dkcjunk==>
>
> A prior answer said to define the first one as
> /usr/openwin/lib.
>
> Is that your opinion too?
http://www.visi.com/~barr/ldpath.html
No, my opinion is that neither of those values should be set. They are
unnecessary and evil. Set LDFLAGS in your environment correctly -before-
running any GNU configure script.
You probably should also set CC and CFLAGS:
[duhring]$ echo $CC
/usr/sfw/bin/gcc
[duhring]$ echo $CFLAGS
-O2 -pipe -mcpu=ultrasparc
> And what about the RUN path -- set it to what?
""
> PS: your opinion on those configure-args suggested in that
> same post? Any changes, or use as-is.
This is what I used:
David Combs
>
>> Looks like you've got problems with libXaw3d.
>>
>> You should look for xaw3d in /etc/PROBLEMS. Here is what I found:
>>
>> "
>> * On systems with shared libraries you might encounter run-time errors
>> from the dynamic linker telling you that it is unable to find some
>> shared libraries, for instance those for Xaw3d or image support.
>> These errors mean Emacs has been linked with a library whose shared
>> library is not in the default search path of the dynamic linker.
>
>Solaris is an ELF system. The library search path is supposed to be in
>the headers of the binary. It gets put there by using the proper LDFLAGS
>during the compile time link.
>
Thanks to you two for explaining that.
Where do I find actual documentation on what an ELF system is?
First time I've seen the word.
(There's always google, but maybe someone knows the "best"
doc, right off.)
>[emacs-21.3]$ echo $LD_LIBRARY_PATH $LD_RUN_PATH
>
>[emacs-21.3]$ ldd src/emacs-21.3.1
Likewise, thanks for the above new-to-me info --
never before heard of LD_RUN_PATH, nor of ldd. Thanks!
> libXm.so.4 => /usr/dt/lib/libXm.so.4
> libgen.so.1 => /usr/lib/libgen.so.1
...
> libmp.so.2 => /usr/lib/libmp.so.2
> /usr/platform/SUNW,Ultra-1/lib/libc_psr.so.1
>
>
>> Similar problems could prevent Emacs from building, since the build
>> process invokes Emacs several times.
With my having to delve through several levels of makefiles,
maybe you could explain why making an (untested) emacs requires
running emacs itself. If not for testing, are they using
emacs (specially-written) functions to actually build
things that get included in the final emacs itself?
Whatever, if not just testing, it sounds clever.
-------- Please, could one or more explain the below
back-and-forth? Sounds good, but said to be wrong???
>> On many systems, it is possible to set LD_LIBRARY_PATH in your
>> environment to specify additional directories where shared libraries
>> can be found.
>
>Go back and re-read my previous post in the other branch of this thread.
>
>> Other systems allow to set LD_RUN_PATH in a similar way, but before
>> Emacs is linked. With LD_RUN_PATH set, the linker will include a
>> specified run-time search path in the executable.
>
>Completely unnecessary. Learn something about the OS before posting such
>nonsense.
>
>> Hope that helps,
>
>It merely confuses and confounds the misimpressions you Linux users have
>about UNIX.
>
Thanks so much!
David
David Combs
Question: does any 2nd person agree that I should use
the above config-args -- either as-is, or with modifications.
Thanks.
David
PS: maybe stupid question; perhaps Dave was born inside
emacs sources...
David Combs
James Carlson <james.d...@sun.com> wrote:
>dkc...@panix.com (David Combs) writes:
>> (The last time I dealt with these concepts was
>> way back on dec-20 twenex; since then I've been
>> using a language no one's ever heard of (Mainsail)
>> that works entirely differently, doesn't even
>> use ld, does such things its own (also nice) way.)
>
>You're kidding, right? ;-}
Unfortunately not. Although I've *read* lots of books
on c & c++ (ugh!, no gc!), I've written a few maybe
10-line c-functions (nothing at all in c++), and of
course ld (implicitly) for that.
>I spent quite a bit of time coding chip simulations at DG in Mainsail
>for the VTI tools we used. Sort of a nifty string-based language that
>reminded me a bit (at the time) of REXX.
>
>I'll bet there are more than a few others out here ...
OK, but it doesn't use ld -- well, once only, to build
the tiny base that connects to the local os. Everything
else (*everything* else) is written in Mainsail itself
(somewhat-newish idea way back in 77).
Consists of ships-with plus user-built "modules", usually
one per file, compiled into local machine-code, that gets
runtime-loaded a la least-recently-used-swapout, all
of that machinery built in the language -- thus, no ld.
Best thing about mainsail is its "true" gc (collects
cycles), its nifty debugger that understands macros
you create (*FANCY* macros, infinitely better and more
useful than cpp), has coroutines, vastly easier ascii
io than java, generic procedures, classes, inheritance
(but not overriding), and really cool, especially back
in late 70's and early 80's, 100% machine-transferable,
via cross-compiler and then only a different "runtime system"
for new system. Started using it on dec20 (best machine
until sun), then moved
to vax/vms (stallman or someone wrote that
VMS stood for "vomit making system"),
then transported to even vm/cms (horrible beyond
belief system) (and it actually worked!), then to sun3,
then to sun-sparc, my current platform (sunblade 100, $1,500 CHEAP)
(If they'd only known how to sell, back in early 80's,
those mainsail guys would be very rich today... Nothing
even close then, and that's still pretty true today --
as long as you can avoid GUIs, and stick to vi-like
interaction, or better yet, line-mode.)
Just by reading their web-available manuals, the java
developers could have had a *far, far* better language!
Neat thing about mainsail is that they keep adding
neat things to it.
Oh, they also have had, since I insisted on it back
in 82, a "structure blaster", that would write out
(ascii (ie editable) or binary) all-reachable from
a given object, and then, in later run, read it back
in. Not unusual today, but unique, pretty much,
back then.
Nice language. Still is my main language.
David
David Combs
I removed nothing from your post, for this reply,
because it's so informative.
It's now 6:15pm EST that I first see your post,
and going through the thread, just asked some
things that you answered here.
For doc for everyone, and maybe that should be included
in the emacs build-doc, if you have a second way to
answer those, just for different angle on same subject
by even same person, maybe answer those repeated
questions?
SURELY, the info in this thread should not just
disappear into deja-seen-long-ago, but should
be stuffed into the emacs building-doc!
---
To summarize one of your points, you say to set
the LDFLAGS *now*, eg in .cshrc, so it's always
there.
And to IGNORE the idea of a RUN path. (Since one
person evidently believes in it, maybe a few
educational words on why not -- the more you
explain, in some depth, the more that other
people will learn, and have an easier time with
building eg emacs.)
THANKS!!!
I now have lots of things to read-over *in-detail*,
before I go have a try at emacs again.
---
Oh, is there some EASY way, cookbook like, to grab
an emacs from CVS, without having to *learn* the
whole freaking thing?
David
Stefan Monnier
>> --with-xpm --with-jpeg --with-tiff --with-gif --with-png --with-x
> Question: does any 2nd person agree that I should use
> the above config-args -- either as-is, or with modifications.
The --with-xpm, --with-jpeg, --with-tiff, --with-gif, and --with-png,
and --with-x should be unnecessary (they are autodetected).
The --with-x-toolkit=motif is your choice, depending on whether you prefer
the Motif toolkit for scrollbars and menus or the Xaw3d toolkit for
scrollbars and the Lucid toolkit for menus.
You have Xaw3d installed on your system in /usr/sfw/lib as your
listing has shown, so it should work just fine as long as you make sure
to tell the executable where the Xaw3d library can be found.
For that you need to either provide a -R/usr/sfw/lib argument or an
LD_RUN_PATH to the C compiler (the C compiler did find the library while
compiling, but the compiler does not assume that the library will be at the
same spot when you run the program as when you compile) or set
LD_LIBRARY_PATH if you forgot to give the relevant info to the compiler.
The -R option is the best choice.
The same issue you're seeing with Xaw3d might occur with Motif, of course,
depending on where the library is installed and what is the default search
path for dynamically linked libraries.
Stefan
Stefan Monnier
> person evidently believes in it, maybe a few
> educational words on why not -- the more you
> explain, in some depth, the more that other
> people will learn, and have an easier time with
> building eg emacs.)
If you're referring to me, I don't advocate the use of LD_LIBRARY_PATH
either. I only suggested you to *try* it to see if it works around your
problem (which it should have, but it seems that you didn't even bother to
try or to report the result of trying).
Trying it this way is a matter of 10 seconds (no need to reconfigure and/or
recompile).
Stefan
Darren Dunham
> For that you need to either provide a -R/usr/sfw/lib argument or an
> LD_RUN_PATH to the C compiler (the C compiler did find the library while
> compiling, but the compiler does not assume that the library will be at the
> same spot when you run the program as when you compile) or set
> LD_LIBRARY_PATH if you forgot to give the relevant info to the compiler.
> The -R option is the best choice.
Any particular reason the -R stuff isn't added for a Solaris build?
--
Darren Dunham ddu...@taos.com
Unix System Administrator Taos - The SysAdmin Company
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >
Dave Uhring
> To summarize one of your points, you say to set
> the LDFLAGS *now*, eg in .cshrc, so it's always
> there.
Yes, so that it is in your environment -anytime- you run a configure
script. Note that not all those configure scripts will create proper
LDFLAGS in your Makefiles. You need to monitor that; for each -L in the
linking output there needs be a corresponding -R.
Considering c-shell you might also want to read this:
http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/
> And to IGNORE the idea of a RUN path. (Since one
> person evidently believes in it, maybe a few
> educational words on why not -- the more you
> explain, in some depth, the more that other
> people will learn, and have an easier time with
> building eg emacs.)
Solaris run-time linker, ld.so.1, does not even recognize that LD_RUN_PATH
value. man ld.so.1 It does not even appear in the ld.so(8) man page for
Linux.
> Oh, is there some EASY way, cookbook like, to grab
> an emacs from CVS, without having to *learn* the
> whole freaking thing?
EMACS is a GNU utility. I don't know about a publicly readable CVS
repository for it, but you might check at http://www.gnu.org.
Stefan Monnier
>> LD_RUN_PATH to the C compiler (the C compiler did find the library while
>> compiling, but the compiler does not assume that the library will be at the
>> same spot when you run the program as when you compile) or set
>> LD_LIBRARY_PATH if you forgot to give the relevant info to the compiler.
>> The -R option is the best choice.
> Any particular reason the -R stuff isn't added for a Solaris build?
I remember discussions about it a long time ago, but didn't know
enough at that time and can't remember what was the conclusion.
It's odd also that the PROBLEMS file only mention LD_LIBRARY_PATH
and LD_RUN_PATH without mentioning the -R arg in LDFLAGS.
I hope somebody who knows more about how `configure' chooses the -L and -R
args could help us at least write a better entry in PROBLEMS.
Stefan
David Combs
Stefan Monnier <monnier+gnu.emacs.help/news/@flint.cs.yale.edu> wrote:
>>> [emacs-21.3]$ ./configure --prefix=/usr/sfw --with-x-toolkit=motif
>>> --with-xpm --with-jpeg --with-tiff --with-gif --with-png --with-x
>
>> Question: does any 2nd person agree that I should use
>> the above config-args -- either as-is, or with modifications.
>
>The --with-xpm, --with-jpeg, --with-tiff, --with-gif, and --with-png,
>and --with-x should be unnecessary (they are autodetected).
>The --with-x-toolkit=motif is your choice, depending on whether you prefer
>the Motif toolkit for scrollbars and menus or the Xaw3d toolkit for
>scrollbars and the Lucid toolkit for menus.
>
>You have Xaw3d installed on your system in /usr/sfw/lib as your
>listing has shown, so it should work just fine as long as you make sure
>to tell the executable where the Xaw3d library can be found.
>
>For that you need to either provide a -R/usr/sfw/lib argument or an
>LD_RUN_PATH to the C compiler (the C compiler did find the library while
How do I do that? Is there some way that I can add it as
a config arg? Or as an env-variable? Or do I have to
go into the resulting makefile (Makefile?) and add it, by
hand, after cc command?
>compiling, but the compiler does not assume that the library will be at the
>same spot when you run the program as when you compile) or set
>LD_LIBRARY_PATH if you forgot to give the relevant info to the compiler.
>The -R option is the best choice.
>
>The same issue you're seeing with Xaw3d might occur with Motif, of course,
>depending on where the library is installed and what is the default search
>path for dynamically linked libraries.
>
>
> Stefan
Here's some lines from the Makefile:
(an *Occur* buffer):
3 lines matching "(CC)" in buffer Makefile<2>.
69: $(CC) -c $(CPPFLAGS) $(ALL_CFLAGS) $<
79:LD = $(CC)
107: $(CC) $(ALL_CFLAGS) $(LDFLAGS) ${srcdir}/prefix-args.c -o prefix-args
---- Now I show that "*Occur*" again, but broken up,
and showing that piece's matching lines just below (with,
for context, a few lines before and after the matched line(s).
For anyone's edification, I did two M-x Occurs in the Makefile,
and I show them here, along with the matched lines and
each with some surrounding context-lines.
Anyone eager to write in come comments or other
explanatons or background or even modifications,
as tutorial info, please do so.
THANKS!
David
[From the *Occur*]
69: $(CC) -c $(CPPFLAGS) $(ALL_CFLAGS) $<
# ========================== start of cpp stuff =======================
C_SWITCH_SYSTEM=
SHELL=/bin/sh
TOOLKIT_DEFINES = -DUSE_LUCID
ALL_CFLAGS=-Demacs -DHAVE_CONFIG_H $(TOOLKIT_DEFINES) $(MYCPPFLAGS) -I. -I${srcdir} -I/usr/openwin/include -I/usr/dt/include ${CFLAGS}
.c.o:
$(CC) -c $(CPPFLAGS) $(ALL_CFLAGS) $<
XOBJ= xterm.o xfns.o xselect.o xrdb.o fontset.o
OLDXMENU=${lwlibdir}liblw.a
LIBXMENU= $(OLDXMENU)
LIBW= -lXaw3d
LIBXTR6 = -lSM -lICE
LIBXT= $(LIBW) -lXmu -lXt $(LIBXTR6) -lXext
X11_LDFLAGS = -L/usr/openwin/lib
LIBX= $(LIBXMENU) $(X11_LDFLAGS) $(LIBXT) -lXpm -lX11
LIBSOUND=
[Note: the line immediately following the above one *is*
the line-79 "LD =" below, that was matched by M-x Occur.
[From the *Occur*]
79:LD = $(CC)
LD = $(CC)
ALL_LDFLAGS = -L/usr/ccs/lib `./prefix-args -Xlinker -R/usr/openwin/lib ` `{ set x USE_MOTIF; test "$$2" = "USE_MOTIF"; } || echo ' -R/usr/dt/lib -L/usr/dt/lib'` $(LDFLAGS)
INTERVAL_SRC = intervals.h composite.h
GETLOADAVG_LIBS =
obj= dispnew.o frame.o scroll.o xdisp.o xmenu.o window.o charset.o coding.o category.o ccl.o cm.o term.o xfaces.o $(XOBJ) emacs.o keyboard.o macros.o keymap.o sysdep.o buffer.o filelock.o insdel.o marker.o minibuf.o fileio.o dired.o filemode.o cmds.o casetab.o casefiddle.o indent.o search.o regex.o undo.o alloc.o data.o doc.o editfns.o callint.o eval.o floatfns.o fns.o print.o lread.o abbrev.o syntax.o unexelf.o mocklisp.o bytecode.o process.o callproc.o region-cache.o sound.o atimer.o doprnt.o strftime.o intervals.o textprop.o composite.o md5.o $(MSDOS_OBJ)
[From the *Occur*]
107: $(CC) $(ALL_CFLAGS) $(LDFLAGS) ${srcdir}/prefix-args.c -o prefix-args
temacs: $(LOCALCPP) $(STARTFILES) stamp-oldxmenu ${obj} ${otherobj} prefix-args
$(LD) ${STARTFLAGS} ${ALL_LDFLAGS} -o temacs ${STARTFILES} ${obj} ${otherobj} ${LIBES}
prefix-args: prefix-args.c $(config_h)
$(CC) $(ALL_CFLAGS) $(LDFLAGS) ${srcdir}/prefix-args.c -o prefix-args
stamp-oldxmenu: ${OLDXMENU} ../src/$(OLDXMENU)
touch stamp-oldxmenu
../src/$(OLDXMENU): ${OLDXMENU}
$(OLDXMENU): really-lwlib
====================== Now, the Occur is on "cflags":
6 lines matching "cflags" in buffer Makefile<2>.
37:CFLAGS= -g -O2
67:ALL_CFLAGS=-Demacs -DHAVE_CONFIG_H $(TOOLKIT_DEFINES) $(MYCPPFLAGS) -I. -I${srcdir} -I/usr/openwin/include -I/usr/dt/include ${CFLAGS}
69: $(CC) -c $(CPPFLAGS) $(ALL_CFLAGS) $<
107: $(CC) $(ALL_CFLAGS) $(LDFLAGS) ${srcdir}/prefix-args.c -o prefix-args
119: cd ${lwlibdir}; ${MAKE} ${MFLAGS} CC='${CC}' CFLAGS='${CFLAGS}' MAKE='${MAKE}' "C_SWITCH_X_SITE=$(C_SWITCH_X_SITE_1)" "C_SWITCH_X_MACHINE=$(C_SWITCH_X_MACHINE_1)" "C_SWITCH_X_SYSTEM=$(C_SWITCH_X_SYSTEM_1)" "C_SWITCH_SITE=$(C_SWITCH_SITE_1)" "C_SWITCH_MACHINE=$(C_SWITCH_MACHINE_1)" "C_SWITCH_SYSTEM=$(C_SWITCH_SYSTEM_1)"
249: LC_ALL=C $(MAKE) $(MFLAGS) temacs ALL_CFLAGS="$(ALL_CFLAGS) -DPURESIZE=5000000 -I../src"
---- Now I show THIS "*Occur*" again, but broken up,
and showing that piece's matching lines just below (with,
for context, a few lines before and after the matched line(s).
[From the *Occur*]
6 lines matching "cflags" in buffer Makefile<2>.
37:CFLAGS= -g -O2
CC=gcc
CPP=gcc -E
CFLAGS= -g -O2
CPPFLAGS=
LDFLAGS= -L/usr/openwin/lib -L/extra-non-sun--c-libraries--bin # dkc-added-3may03
LN_S=ln -s
[From the *Occur*]
67:ALL_CFLAGS=-Demacs -DHAVE_CONFIG_H $(TOOLKIT_DEFINES) $(MYCPPFLAGS) -I. -I${srcdir} -I/usr/openwin/include -I/usr/dt/include ${CFLAGS}
69: $(CC) -c $(CPPFLAGS) $(ALL_CFLAGS) $<
# ========================== start of cpp stuff =======================
C_SWITCH_SYSTEM=
SHELL=/bin/sh
TOOLKIT_DEFINES = -DUSE_LUCID
ALL_CFLAGS=-Demacs -DHAVE_CONFIG_H $(TOOLKIT_DEFINES) $(MYCPPFLAGS) -I. -I${srcdir} -I/usr/openwin/include -I/usr/dt/include ${CFLAGS}
.c.o:
$(CC) -c $(CPPFLAGS) $(ALL_CFLAGS) $<
[From the *Occur*]
107: $(CC) $(ALL_CFLAGS) $(LDFLAGS) ${srcdir}/prefix-args.c -o prefix-args
119: cd ${lwlibdir}; ${MAKE} ${MFLAGS} CC='${CC}' CFLAGS='${CFLAGS}' MAKE='${MAKE}' "C_SWITCH_X_SITE=$(C_SWITCH_X_SITE_1)" "C_SWITCH_X_MACHINE=$(C_SWITCH_X_MACHINE_1)" "C_SWITCH_X_SYSTEM=$(C_SWITCH_X_SYSTEM_1)" "C_SWITCH_SITE=$(C_SWITCH_SITE_1)" "C_SWITCH_MACHINE=$(C_SWITCH_MACHINE_1)" "C_SWITCH_SYSTEM=$(C_SWITCH_SYSTEM_1)"
temacs: $(LOCALCPP) $(STARTFILES) stamp-oldxmenu ${obj} ${otherobj} prefix-args
$(LD) ${STARTFLAGS} ${ALL_LDFLAGS} -o temacs ${STARTFILES} ${obj} ${otherobj} ${LIBES}
prefix-args: prefix-args.c $(config_h)
$(CC) $(ALL_CFLAGS) $(LDFLAGS) ${srcdir}/prefix-args.c -o prefix-args
stamp-oldxmenu: ${OLDXMENU} ../src/$(OLDXMENU)
touch stamp-oldxmenu
../src/$(OLDXMENU): ${OLDXMENU}
$(OLDXMENU): really-lwlib
C_SWITCH_MACHINE_1 =
C_SWITCH_SYSTEM_1 =
C_SWITCH_SITE_1 =
C_SWITCH_X_SITE_1 = -I/usr/openwin/include
C_SWITCH_X_MACHINE_1 =
C_SWITCH_X_SYSTEM_1 = -I/usr/dt/include
really-lwlib:
cd ${lwlibdir}; ${MAKE} ${MFLAGS} CC='${CC}' CFLAGS='${CFLAGS}' MAKE='${MAKE}' "C_SWITCH_X_SITE=$(C_SWITCH_X_SITE_1)" "C_SWITCH_X_MACHINE=$(C_SWITCH_X_MACHINE_1)" "C_SWITCH_X_SYSTEM=$(C_SWITCH_X_SYSTEM_1)" "C_SWITCH_SITE=$(C_SWITCH_SITE_1)" "C_SWITCH_MACHINE=$(C_SWITCH_MACHINE_1)" "C_SWITCH_SYSTEM=$(C_SWITCH_SYSTEM_1)"
@true
.PHONY: really-lwlib
[From the *Occur*]
249: LC_ALL=C $(MAKE) $(MFLAGS) temacs ALL_CFLAGS="$(ALL_CFLAGS) -DPURESIZE=5000000 -I../src"
.PHONY: tags
bootstrap: bootstrap-emacs
bootstrap-temacs:
LC_ALL=C $(MAKE) $(MFLAGS) temacs ALL_CFLAGS="$(ALL_CFLAGS) -DPURESIZE=5000000 -I../src"
bootstrap-doc: ${libsrc}make-docfile
-rm -f ${etc}DOC
els=`echo ${shortlisp} ${SOME_MACHINE_LISP} | sed -e "s/\\.elc/.el/g"`; ${libsrc}make-docfile -d ${srcdir} $$els ${obj} > ${etc}DOC
bootstrap-emacs: bootstrap-temacs bootstrap-doc
./temacs --batch --load loadup bootstrap
mv -f emacs bootstrap-emacs
rm -f temacs
David Combs
Well, earlier in this thread, someone said he had
successfully built this, that, and the cvs version.
Thanks all for all the info.
I go crash, and give a try tomorrow.
David
Casper H.S. Dik
>Solaris run-time linker, ld.so.1, does not even recognize that LD_RUN_PATH
>value. man ld.so.1 It does not even appear in the ld.so(8) man page for
>Linux.
LD_RUN_PATH is used only by the compile time linker as a default
for the -R option.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Stefan Monnier
> a config arg? Or as an env-variable? Or do I have to
> go into the resulting makefile (Makefile?) and add it, by
> hand, after cc command?
That's the part I never bothered to learn.
What I do is `make' then look for the command that did the link
(in make's output) and copy&paste it into the shell, edit to
my liking and rerun.
It seems that Dave understands autoconf a bit better so he uses
a more principled way to do it.
Stefan
Dave Uhring
> "Dave Uhring" <daveu...@yahoo.com> writes:
>
>>Solaris run-time linker, ld.so.1, does not even recognize that LD_RUN_PATH
>>value. man ld.so.1 It does not even appear in the ld.so(8) man page for
>>Linux.
>
> LD_RUN_PATH is used only by the compile time linker as a default
> for the -R option.
There it is...
User Commands ld(1)
[ ... ]
LD_RUN_PATH
An alternative mechanism for specifying a runpath to
the link-editor (see -R option). If both LD_RUN_PATH
and the -R option are specified, -R supersedes.
David Combs
Stefan Monnier <monnier+gnu.emacs.help/news/@flint.cs.yale.edu> wrote:
>It seems that Dave understands autoconf a bit better so he uses
>a more principled way to do it.
FWIW, there does exist a book about Autoconf,
although the customer-blurbs on Amazon say
that it's already out of date, and leaves
out lots of stuff.
I assume it's a lot better than having no book at all.
David
PS: thanks for your method of getting the make
to work.
bbense+gnu.emacs.help.co...@telemark.slac.stanford.edu
In article <5lu1bne...@rum.cs.yale.edu>,
_ AFAIK, autoconf doesn't know how to set these things. You
either have to write your own hacks to configure.in or use the
generic libtool solution. Libtool was written to solve exactly
this problem.
_ Booker C. Bense
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBPsznYWTWTAjn5N/lAQGKjAP/QSdE4Myq4StJvHYT8wF4LsAP06ZwXNQd
EgABJe2oNaXk9CViJ+RGG94CvZvhzAoDQ4kliQLhK3tpudvtuFC4jFcjyiuWqWgC
di17GXbMnMrAWaY8oFqgBxbwl7EzuM/Nj61JonInXz2C/zIVUUoDclkmt175mEzB
FGwvt1RCAYA=
=r2aK
-----END PGP SIGNATURE-----
Dave Uhring
bbense+gnu.emacs.help.comp.unix.solaris.May.22.0 wrote:
> _ AFAIK, autoconf doesn't know how to set these things. You
> either have to write your own hacks to configure.in or use the
> generic libtool solution. Libtool was written to solve exactly
> this problem.
/tmp/emacs-21.3/src/Makefile generated with $LDFLAGS=""
LDFLAGS= -L/usr/openwin/lib
X11_LDFLAGS = -L/usr/openwin/lib
LIBX= $(LIBXMENU) $(X11_LDFLAGS) $(LIBXT) -ltiff -ljpeg -lpng -lz -lm -lXpm -lX11
Note that the -R/usr/openwin/lib linking argument does not exist. Neither
does -L/usr/sfw/lib and hence /usr/ccs/bin/ld is NOT going to find
libtiff.so, libjpeg.so or libpng.so, let alone provide the required
run-time link paths.
Now export LDFLAGS properly and run configure again. The src/Makefile now
has:
LDFLAGS=-L/usr/openwin/lib -R/usr/openwin/lib -L/usr/sfw/lib -R/usr/sfw/lib -L/usr/openwin/lib
X11_LDFLAGS = -L/usr/openwin/lib
LIBX= $(LIBXMENU) $(X11_LDFLAGS) $(LIBXT) -ltiff -ljpeg -lpng -lz -lm -lXpm -lX11
The build time linker will now not only find the required libraries but
will place the library search path within the resultant binary executables.
Libtool had nothing to do with it.
[emacs-21.3]$ grep libtool *
[emacs-21.3]$
David Combs
>...
>_ AFAIK, autoconf doesn't know how to set these things. You
> either have to write your own hacks to configure.in or use the
> generic libtool solution. Libtool was written to solve exactly
> this problem.
>
>_ Booker C. Bense
Thanks much! Since libtool -- first time I've heard
of it.
Oh, there it is -- in sfw, info-pages and everything.
I'll have a read.
Thanks,
David
David Combs
Dave Uhring <daveu...@yahoo.com> wrote:
>On Thu, 22 May 2003 15:06:10 +0000,
>bbense+gnu.emacs.help.comp.unix.solaris.May.22.0 wrote:
>
>> _ AFAIK, autoconf doesn't know how to set these things. You
>> either have to write your own hacks to configure.in or use the
>> generic libtool solution. Libtool was written to solve exactly
>> this problem.
>
>/tmp/emacs-21.3/src/Makefile generated with $LDFLAGS=""
>
>LDFLAGS= -L/usr/openwin/lib
>X11_LDFLAGS = -L/usr/openwin/lib
>LIBX= $(LIBXMENU) $(X11_LDFLAGS) $(LIBXT) -ltiff -ljpeg -lpng -lz -lm -lXpm -lX11
>
Since I uses csh, I made a file env.source:
setenv LDFLAGS '-L/usr/openwin/lib'
setenv X11_LDFLAGS '-L/usr/openwin/lib'
setenv LIBX '$(LIBXMENU) $(X11_LDFLAGS) $(LIBXT) -ltiff -ljpeg -lpng -lz -lm -lXpm -lX11'
, and then said "source env.source", and then "env", and got:
LDFLAGS=-L/usr/openwin/lib
X11_LDFLAGS=-L/usr/openwin/lib
LIBX=$(LIBXMENU) $(X11_LDFLAGS) $(LIBXT) -ltiff -ljpeg -lpng -lz -lm -lXpm -lX11
110 ==/david3/from_netcom-dir2/sources-stuff/emacs-21.3==>
as the final three lines.
Look ok to you?
>Note that the -R/usr/openwin/lib linking argument does not exist. Neither
>does -L/usr/sfw/lib and hence /usr/ccs/bin/ld is NOT going to find
>libtiff.so, libjpeg.so or libpng.so, let alone provide the required
>run-time link paths.
>
>Now export LDFLAGS properly and run configure again.
I think (maybe wrongly, for sure!) that csh has no export cmd,
nor(?) needs one?
Oh, better do a "make clean", I suppose, first.
>The src/Makefile now has:
>
>LDFLAGS=-L/usr/openwin/lib -R/usr/openwin/lib -L/usr/sfw/lib -R/usr/sfw/lib -L/usr/openwin/lib
>X11_LDFLAGS = -L/usr/openwin/lib
>LIBX= $(LIBXMENU) $(X11_LDFLAGS) $(LIBXT) -ltiff -ljpeg -lpng -lz -lm -lXpm -lX11
>
>The build time linker will now not only find the required libraries but
>will place the library search path within the resultant binary executables.
>
>Libtool had nothing to do with it.
>
>[emacs-21.3]$ grep libtool *
>[emacs-21.3]$
>
>
>
Here's what I ended up with in that src/Makefile:
LDFLAGS=-L/usr/openwin/lib -L/usr/openwin/lib
...
X11_LDFLAGS = -L/usr/openwin/lib
LIBX= $(LIBXMENU) $(X11_LDFLAGS) $(LIBXT) -lXpm -lX11
Note that my libx is a lot shorter than yours; I guess I'll ltry
making it this way first, then worry later about those other
things.
David
David Combs
and I still get the same error.
I did a make clean, then the ./configure, and
looked at the resulting src/Makefile.
Here's what I ended up with in that src/Makefile:
LDFLAGS=-L/usr/openwin/lib -L/usr/openwin/lib
...
X11_LDFLAGS = -L/usr/openwin/lib
LIBX= $(LIBXMENU) $(X11_LDFLAGS) $(LIBXT) -lXpm -lX11
I then did "make", which started out like this:
113 ==/david3/from_netcom-dir2/sources-stuff/emacs-21.3==> make
if [ ! -f /big5/david3/from_netcom-dir2/sources-stuff/emacs-21.3/lisp/abbrev.elc ]; then \
make bootstrap; \
fi
cd lib-src; make all \
CC='gcc' CFLAGS='-g -O2 ' CPPFLAGS='' \
LDFLAGS='-L/usr/openwin/lib -L/usr/openwin/lib' MAKE='make'
make[1]: Entering directory `/big5/david3/from_netcom-dir2/sources-stuff/emacs-21.3/lib-src'
...
------------------------ tail-end of 22may03's "make" --------------------------
...
LC_ALL=C ./temacs -batch -l loadup dump
ld.so.1: ./temacs: fatal: libXaw3d.so.5: open failed: No such file or directory
Killed
make[1]: *** [emacs] Error 137
make[1]: Leaving directory `/big5/david3/from_netcom-dir2/sources-stuff/emacs-21.3/src'
make: *** [src] Error 2
362.0 sys= 18.0 94% || mem=0 in=0
/usr/openwin/lib:
used 43074 available files
drwxr-xr-x 12 root bin 2560 Mar 12 16:54 .
drwxr-xr-x 9 root bin 512 Feb 27 23:31 ..
-rw-r--r-- 1 root bin 444 Oct 12 2001 .ttyswrc
drwxr-xr-x 9 root bin 1024 Mar 4 17:51 X11
lrwxrwxrwx 1 root root 12 Aug 9 2002 XErrorDB -> X11/XErrorDB
lrwxrwxrwx 1 root root 13 Aug 9 2002 XKeysymDB -> X11/XKeysymDB
lrwxrwxrwx 1 root root 12 Aug 9 2002 Xcms.txt -> X11/Xcms.txt
-rw-r--r-- 1 root bin 1232 Apr 6 2002 Xdefaults
-rw-r--r-- 1 root bin 945 Apr 6 2002 Xinitrc
...
...
-rwxr-xr-x 1 root bin 12900 Apr 6 2002 libXau.a
-rwxr-xr-x 1 root bin 456064 Apr 6 2002 libXaw.a
lrwxrwxrwx 1 root root 13 Aug 9 2002 libXaw.so -> ./libXaw.so.5
-rwxr-xr-x 1 root bin 239728 Apr 6 2002 libXaw.so.4
-rwxr-xr-x 1 root bin 304316 Apr 6 2002 libXaw.so.5
-rwxr-xr-x 1 root bin 35224 Apr 6 2002 libXdmcp.a
-rwxr-xr-x 1 root bin 180304 Dec 2 23:07 libXext.a
lrwxrwxrwx 1 root root 14 Aug 9 2002 libXext.so -> ./libXext.so.0
-rwxr-xr-x 1 root bin 119036 Dec 2 23:07 libXext.so.0
-rwxr-xr-x 1 root bin 66856 Apr 6 2002 libXi.a
...
...
Any obvious stupid thing that I did here?
(Do I have to be root to do the make? I thought
the doc said only for the make install.)
Thanks!
David
Dave Uhring
> In article <pan.2003.05.22....@yahoo.com>,
> Dave Uhring <daveu...@yahoo.com> wrote:
>>On Thu, 22 May 2003 15:06:10 +0000,
>>bbense+gnu.emacs.help.comp.unix.solaris.May.22.0 wrote:
>
>>
>>> _ AFAIK, autoconf doesn't know how to set these things. You
>>> either have to write your own hacks to configure.in or use the
>>> generic libtool solution. Libtool was written to solve exactly
>>> this problem.
>>
>>/tmp/emacs-21.3/src/Makefile generated with $LDFLAGS=""
>>
>>LDFLAGS= -L/usr/openwin/lib
>>X11_LDFLAGS = -L/usr/openwin/lib
>>LIBX= $(LIBXMENU) $(X11_LDFLAGS) $(LIBXT) -ltiff -ljpeg -lpng -lz -lm -lXpm -lX11
>>
As I pointed out in the next few lines this is completely in error.
> Since I uses csh, I made a file env.source:
>
> setenv LDFLAGS '-L/usr/openwin/lib'
> setenv X11_LDFLAGS '-L/usr/openwin/lib'
> setenv LIBX '$(LIBXMENU) $(X11_LDFLAGS) $(LIBXT) -ltiff -ljpeg -lpng -lz -lm -lXpm -lX11'
>
> , and then said "source env.source", and then "env", and got:
>
> LDFLAGS=-L/usr/openwin/lib
> X11_LDFLAGS=-L/usr/openwin/lib
> LIBX=$(LIBXMENU) $(X11_LDFLAGS) $(LIBXT) -ltiff -ljpeg -lpng -lz -lm -lXpm -lX11
> 110 ==/david3/from_netcom-dir2/sources-stuff/emacs-21.3==>
>
> as the final three lines.
>
> Look ok to you?
No. You set up your env.source incorrectly. I keep telling you that
LDFLAGS must contain -L and -R entries for each library directory and you
did not even bother with -R/usr/openwin/lib in your env.source file.
>>Note that the -R/usr/openwin/lib linking argument does not exist. Neither
>>does -L/usr/sfw/lib and hence /usr/ccs/bin/ld is NOT going to find
>>libtiff.so, libjpeg.so or libpng.so, let alone provide the required
>>run-time link paths.
>>
>>Now export LDFLAGS properly and run configure again.
>
> I think (maybe wrongly, for sure!) that csh has no export cmd,
> nor(?) needs one?
Right, but you need to use setenv, which is the csh equivalent to
ksh,bash,zsh export.
> Oh, better do a "make clean", I suppose, first.
Just remove config.cache and config.status if you have a clean source
tree.
> Note that my libx is a lot shorter than yours; I guess I'll ltry
> making it this way first, then worry later about those other
> things.
That is because libtiff, libjpeg, etc were not found.
It will not build correctly.
Dave Uhring
> OK, I did, I think, what I was told to do,
> and I still get the same error.
Of course you got the same error. You keep refusing to include
-R/usr/openwin/lib in your $LDFLAGS. tmacs cannot find it because you did
not do that.
> Any obvious stupid thing that I did here?
Fix your env.source file, make clean, remove config.cache & config.status
and run configure again with the proper $LDFLAGS.
> (Do I have to be root to do the make?
No.
James Carlson
> In article <xoavd6icr...@sun.com>,
> James Carlson <james.d...@sun.com> wrote:
> >dkc...@panix.com (David Combs) writes:
> >> (The last time I dealt with these concepts was
> >> way back on dec-20 twenex; since then I've been
> >> using a language no one's ever heard of (Mainsail)
> >> that works entirely differently, doesn't even
> >> use ld, does such things its own (also nice) way.)
> >
> >You're kidding, right? ;-}
>
> Unfortunately not. Although I've *read* lots of books
Uh ... I was referring to your assertion that Mainsail is "a language
no one's ever heard of," not its non-use of ld.
David Combs
Here's what i did:
134 source env.source
135 make clean
136 rm config.cache
137 ./configure
138 make
And here's env.source, following your instructons (only
that one line:
--------------------------------- env.source
# setenv LDFLAGS '-L/usr/openwin/lib'
# setenv X11_LDFLAGS '-L/usr/openwin/lib'
setenv X11_LDFLAGS ''
# setenv LIBX '$(LIBXMENU) $(X11_LDFLAGS) $(LIBXT) -ltiff -ljpeg -lpng -lz -lm -lXpm -lX11'
setenv LIBX ''
setenv LDFLAGS '-L/usr/openwin/lib -R/usr/openwin/lib -L/usr/sfw/lib -R/usr/sfw/lib'
------- Here's a part of the post-configure src/Makefile:
# Here are the things that we expect ../configure to edit.
# We use $(srcdir) explicitly in dependencies so as not to depend on VPATH.
srcdir=/big5/david3/from_netcom-dir2/sources-stuff/emacs-21.3/src
VPATH=/big5/david3/from_netcom-dir2/sources-stuff/emacs-21.3/src
CC=gcc
CPP=gcc -E
CFLAGS= -g -O2
CPPFLAGS=
LDFLAGS=-L/usr/openwin/lib -R/usr/openwin/lib -L/usr/sfw/lib -R/usr/sfw/lib -L/usr/openwin/lib
LN_S=ln -s
# Substitute an assignment for the MAKE variable, because
# BSD doesn't have it as a default.
# Don't use LIBS. configure puts stuff in it that either shouldn't be
# linked with Emacs or is duplicated by the cpp stuff below.
# LIBS = -lintl -lmail -lm -lXext -lXmu -lXt -lSM -lICE -lX11 -lsocket -lnsl -lkstat
LIBOBJS =
# On Xenix and the IBM RS6000, double-dot gets screwed up.
dot = .
dotdot = ${dot}${dot}
lispsource = ${srcdir}/$(dot)$(dot)/lisp/
libsrc = $(dot)$(dot)/lib-src/
etc = $(dot)$(dot)/etc/
oldXMenudir = $(dot)$(dot)/oldXMenu/
lwlibdir = $(dot)$(dot)/lwlib/
# Configuration files for .o files to depend on.
M_FILE = ${srcdir}/m/sparc.h
S_FILE = ${srcdir}/s/sol2-5.h
config_h = config.h $(M_FILE) $(S_FILE)
# ========================== start of cpp stuff =======================
C_SWITCH_SYSTEM=
SHELL=/bin/sh
TOOLKIT_DEFINES = -DUSE_LUCID
ALL_CFLAGS=-Demacs -DHAVE_CONFIG_H $(TOOLKIT_DEFINES) $(MYCPPFLAGS) -I. -I${srcdir} -I/usr/openwin/include -I/usr/dt/include ${CFLAGS}
.c.o:
$(CC) -c $(CPPFLAGS) $(ALL_CFLAGS) $<
XOBJ= xterm.o xfns.o xselect.o xrdb.o fontset.o
OLDXMENU=${lwlibdir}liblw.a
LIBXMENU= $(OLDXMENU)
LIBW= -lXaw3d
LIBXTR6 = -lSM -lICE
LIBXT= $(LIBW) -lXmu -lXt $(LIBXTR6) -lXext
X11_LDFLAGS = -L/usr/openwin/lib
LIBX= $(LIBXMENU) $(X11_LDFLAGS) $(LIBXT) -lXpm -lX11
LIBSOUND=
LD = $(CC)
ALL_LDFLAGS = -L/usr/ccs/lib `./prefix-args -Xlinker -R/usr/openwin/lib ` `{ set x USE_MOTIF; test "$$2" = "USE_MOTIF"; } || echo ' -R/usr/dt/lib -L/usr/dt/lib'` $(LDFLAGS)
INTERVAL_SRC = intervals.h composite.h
GETLOADAVG_LIBS =
And this, unfortunately, is the tail-end of what we
get for the make:
...
LC_ALL=C ./temacs -batch -l loadup dump
ld.so.1: ./temacs: fatal: libXaw3d.so.5: open failed: No such file or directory
Killed
make[1]: *** [emacs] Error 137
make[1]: Leaving directory `/big5/david3/from_netcom-dir2/sources-stuff/emacs-21.3/src'
make: *** [src] Error 2
360.0 sys= 17.0 95% || mem=0 in=0
139 ==/david3/from_netcom-dir2/sources-stuff/emacs-21.3==>
Does anyone have a clue? I sure don't!
Thanks,
David
Dave Uhring
> ================================(in response to email from Dave U:)
> Here's what i did:
>
> 134 source env.source
> 135 make clean
> 136 rm config.cache
> 137 ./configure
> 138 make
You did not remove config.status.
>
> And here's env.source, following your instructons (only
> that one line:
> --------------------------------- env.source
>
> # setenv LDFLAGS '-L/usr/openwin/lib'
> # setenv X11_LDFLAGS '-L/usr/openwin/lib'
> setenv X11_LDFLAGS ''
> # setenv LIBX '$(LIBXMENU) $(X11_LDFLAGS) $(LIBXT) -ltiff -ljpeg -lpng -lz -lm -lXpm -lX11'
> setenv LIBX ''
> setenv LDFLAGS '-L/usr/openwin/lib -R/usr/openwin/lib -L/usr/sfw/lib -R/usr/sfw/lib'
Only the last line should be there. You have -three- lines, not one.
> Does anyone have a clue? I sure don't!
Perhaps you should consider changing your shell for the purpose of
building emacs. Re-read this:
http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/
Create a ~/.bashrc like this:
-----------------------------------------------------------------------
PATH=/sbin:/usr/bin:/usr/sbin:/usr/dt/bin:/usr/openwin/bin:/usr/sfw/bin:
/usr/sfw/sbin:/usr/ccs/bin
export PATH
PS1="[\W]$ "
export LDFLAGS='-L/usr/openwin/lib -R/usr/openwin/lib -L/usr/sfw/lib
-R/usr/sfw/lib'
export CC=/usr/sfw/bin/gcc
export CXX=/usr/sfw/bin/g++
export CFLAGS='-O2 -pipe -mcpu=ultrasparc'
-------------------------------------------------------------------------
Now from your csh prompt, just execute "bash"
Go back to the directory where your emacs tarball resides and
$ rm -r emacs-21.3
$ gzip -cd emacs-21.3.tar.gz | tar xf -
$ cd emacs-21.3
$ ./configure --prefix=/usr/sfw # or whereever you want it to go
$ make
Philip Brown
mirror sites of www.blastwave.org
[For both sparc and x86. And technically, it will take a few hours for all
the mirrors to sync up]
--
http://www.blastwave.org/ for solaris pre-packaged binaries with pkg-get
Organized by the author of pkg-get
[Trim the no-bots from my address to reply to me by email!]
S.1618 http://thomas.loc.gov/cgi-bin/bdquery/z?d105:SN01618:@@@D
http://www.spamlaws.com/state/ca1.html
David Combs
Dave Uhring <daveu...@yahoo.com> wrote:
>On Fri, 23 May 2003 09:18:35 +0000, David Combs wrote:
>
>> OK, I did, I think, what I was told to do,
>> and I still get the same error.
>
>Of course you got the same error. You keep refusing to include
>-R/usr/openwin/lib in your $LDFLAGS.
No I don't -- although I might not have it right::
177 ==/david3/from_netcom-dir2/sources-stuff/emacs-21.3==> echo $LDFLAGS
-L/usr/openwin/lib -R/usr/openwin/lib -L/usr/sfw/lib -R/usr/sfw/lib
178 ==/david3/from_netcom-dir2/sources-stuff/emacs-21.3==>
David
Dave Uhring
Your file env.source as posted in
Message-ID: bakbhh$q7b$1...@reader1.panix.com>
"Since I uses csh, I made a file env.source:
setenv LDFLAGS '-L/usr/openwin/lib'
[ ... ]"
is a contradiction of the above statement.
I publicly posted a usable ~/.bashrc file you could use to build the emacs
binaries and in a private communication sent you a usable ~/.cshrc file
which would accomplish that objective. Why have you not made the effort?
Phil Brown also announced the availability of binary packages for
emacs-21.3 for Solaris 8 & 9 in this thread. If you cannot build the
binaries then use Phil's package.
David Combs
Philip Brown <phi...@bolthole.no-bots.com> wrote:
>FYI: there are now binaries of emacs 21.3, for solaris 8 and later, on
>mirror sites of www.blastwave.org
Since I've already got the sources downloaded,
and I'll probably soon have it "made" ok,
I probably won't get the blastwave "binary"
(actually, solaris "package"?).
But a question:
Suppose in a case like this, you like the current
version ok, but want to try the new one.
However, in case it's not so great after all,
I'd want to keep using the OLD one.
Looking at the blastwave page, it implies (says
right out!) that the new one gets installed
OVER the old one -- the old one would be GONE,
no?
So, first question: how to be able to restore
the "old" one?
Second question (similar): Suppose you want
to *compare* how they run'; you want to
be able to run either one, or, for emacs,
have both running at the same time, switching
between via switching from one (cde) window
to another.
How to do that?
Thanks!
David
David Combs
Dave Uhring <daveu...@yahoo.com> wrote:
....
....
>
>Perhaps you should consider changing your shell for the purpose of
>building emacs. Re-read this:
>
> http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/
>
>Create a ~/.bashrc like this:
>
>-----------------------------------------------------------------------
>PATH=/sbin:/usr/bin:/usr/sbin:/usr/dt/bin:/usr/openwin/bin:/usr/sfw/bin:
>/usr/sfw/sbin:/usr/ccs/bin
>export PATH
>
>PS1="[\W]$ "
>
>export LDFLAGS='-L/usr/openwin/lib -R/usr/openwin/lib -L/usr/sfw/lib
>-R/usr/sfw/lib'
>export CC=/usr/sfw/bin/gcc
>export CXX=/usr/sfw/bin/g++
>export CFLAGS='-O2 -pipe -mcpu=ultrasparc'
>-------------------------------------------------------------------------
>
>Now from your csh prompt, just execute "bash"
>
>Go back to the directory where your emacs tarball resides and
>
>$ rm -r emacs-21.3
>$ gzip -cd emacs-21.3.tar.gz | tar xf -
>$ cd emacs-21.3
>$ ./configure --prefix=/usr/sfw # or whereever you want it to go
>$ make
>
OK, tried both the bash and the .cshrc you sent;
HOURS spent until I finally noticed that you
had /usr/sfw/, but solaris-NINE wants it in
/opt/sfw (I believe that's who wanted it
there, not me).
Once I fixed that, at least it could run gcc;
however, no matter which of your suggested ways
I tried (starting with the huge rm almost each
time), I always got the same error:
...
...
checking whether gettimeofday can accept two arguments... yes
checking for struct timezone... yes
checking for socket... yes
checking for netinet/in.h... yes
checking for arpa/inet.h... yes
checking whether system supports dynamic ptys... yes
checking for pid_t... yes
checking for vfork.h... no
checking for working vfork... no
checking for size_t... yes
Configured for `sparc-sun-solaris2.9'.
Where should the build process find the source code? /big5/david3/from_netcom-dir2/sources-stuff/emacs-21.3
What operating system and machine description files should Emacs use?
`s/sol2-5.h' and `m/sparc.h'
What compiler should emacs be built with? /opt/sfw/bin/gcc -O2 -pipe -mcpu=ultrasparc
Should Emacs use the GNU version of malloc? yes
Should Emacs use a relocating allocator for buffers? yes
Should Emacs use mmap(2) for buffer allocation? no
What window system should Emacs use? x11
What toolkit should Emacs use? LUCID
Where do we find X Windows header files? /usr/openwin/include
Where do we find X Windows libraries? /usr/openwin/lib
Does Emacs use -lXaw3d? yes
Does Emacs use -lXpm? yes
Does Emacs use -ljpeg? no
Does Emacs use -ltiff? no
Does Emacs use -lungif? no
Does Emacs use -lpng? no
Does Emacs use X toolkit scroll bars? yes
updating cache ./config.cache
creating ./config.status
creating Makefile
sed: command garbled: s%@LDFLAGS@%-L/usr/openwin/lib -R/usr/openwin/lib -L/opt/sfw/lib
creating lib-src/Makefile.c
sed: command garbled: s%@LDFLAGS@%-L/usr/openwin/lib -R/usr/openwin/lib -L/opt/sfw/lib
creating oldXMenu/Makefile
sed: command garbled: s%@LDFLAGS@%-L/usr/openwin/lib -R/usr/openwin/lib -L/opt/sfw/lib
creating man/Makefile
sed: command garbled: s%@LDFLAGS@%-L/usr/openwin/lib -R/usr/openwin/lib -L/opt/sfw/lib
creating lwlib/Makefile
sed: command garbled: s%@LDFLAGS@%-L/usr/openwin/lib -R/usr/openwin/lib -L/opt/sfw/lib
creating src/Makefile.c
sed: command garbled: s%@LDFLAGS@%-L/usr/openwin/lib -R/usr/openwin/lib -L/opt/sfw/lib
creating lisp/Makefile
sed: command garbled: s%@LDFLAGS@%-L/usr/openwin/lib -R/usr/openwin/lib -L/opt/sfw/lib
creating leim/Makefile
sed: command garbled: s%@LDFLAGS@%-L/usr/openwin/lib -R/usr/openwin/lib -L/opt/sfw/lib
creating src/config.h
creating src/epaths.h
make: Fatal error: Don't know how to make target `epaths-force'
creating lib-src/Makefile
creating src/Makefile
[emacs-21.3]$
Here's the part of configure that's involved:
# Build src/Makefile from ${srcdir}/src/Makefile.c
# and lib-src/Makefile from ${srcdir}/lib-src/Makefile.c
# This must be done after src/config.h is built, since we rely on that file.
# Now get this: Some word that is part of the ${srcdir} directory name
# or the ${configuration} value might, just might, happen to be an
# identifier like `sun4' or `i386' or something, and be predefined by
# the C preprocessor to some helpful value like 1, or maybe the empty
# string. Needless to say consequent macro substitutions are less
# than conducive to the makefile finding the correct directory.
undefs="`echo $top_srcdir $configuration $canonical |
sed -e 's/[^a-zA-Z0-9_]/ /g' -e 's/^/ /' -e 's/ *$//' \
-e 's/ */ -U/g' -e 's/-U[0-9][^ ]*//g' \
`"
echo creating src/epaths.h
${MAKE-make} epaths-force
# As of 2000-11-19, newest development versions of GNU cpp preprocess
# `..' to `. .' unless invoked with -traditional
if test "x$GCC" = xyes && test "x$CPP_NEED_TRADITIONAL" = xyes; then
CPPFLAGS="$CPPFLAGS -traditional"
fi
echo creating lib-src/Makefile
( cd lib-src
Here's your .cshrc, with a few new aliases,
a -s removed from the hostname-cmd (requires
being root), and a few backslashes for continuations.
#------------------------------------------------------Begin .cshrc
echo "STARTING dave uhring's .cshrc"
umask 022
alias mail Mail
set history=1000
set path=(/sbin /usr/sbin /usr/bin /usr/dt/bin /opt/sfw/bin \
/usr/openwin/bin /usr/ccs/bin)
set filec
# directory stuff: cdpath/cd/back
set cdpath=(/sys /sys/arch \
/usr/src/{bin,sbin,usr.{bin,sbin},pgrm,lib,libexec,share,contrib,local,devel,games,old,gnu,gnu/{lib,usr.bin,usr.sbin,libexec}})
setenv BLOCKSIZE 1k
setenv LDFLAGS '-L/usr/openwin/lib -R/usr/openwin/lib -L/opt/sfw/lib \
-R/opt/sfw/lib'
setenv CC gcc
setenv CFLAGS '-O2 -pipe -mcpu=ultrasparc'
alias cd 'set old="$cwd"; chdir \!*'
alias h history
alias j jobs -l
alias ll ls -l
alias l ls -alF
alias back 'set back="$old"; set old="$cwd"; cd "$back"; unset \
back; dirs'
alias z suspend
alias x exit
alias pd pushd
alias pd2 pushd +2
alias pd3 pushd +3
alias pd4 pushd +4
if ($?prompt) then
# set prompt="`hostname -s`$ "
set prompt="`hostname `$ " # REMOVED THE "-s" ("must be superuser")
endif
# ---- add some of my own aliases:
# I don't want these two:
unalias z
unalias x
alias rm 'rm -i'
alias cp 'cp -i'
alias mv 'mv -i'
alias j 'jobs -l'
alias l 'ls -AFs'
alias c 'clear'
alias ls 'ls -A'
alias h 'history 10'
alias h5 'history 5'
alias h10 'history 10'
alias h20 'history 20'
alias h30 'history 30'
alias h50 'history 50'
alias h99 'history'
# to make solaris look like sunos:
alias df 'df -bk'
alias du 'du -k'
echo "ENDING dave uhring's .cshrc"
#---------------------------------------------------------End .cshrc
And here's a slightly-modified .bashrc:
# got this from From: "Dave Uhring" <daveu...@yahoo.com>
#
# Comp.unix.solaris #442322 (2 + 3185 more)
# From: "Dave Uhring" <daveu...@yahoo.com>
# Newsgroups: gnu.emacs.help,comp.unix.solaris
# [1] Re: Has anyone actually built emacs 21.3 for SOLARIS (sparc)?
# Date: Sat May 24 10:55:24 EDT 2003
#
#
PATH=/sbin:/usr/bin:/usr/sbin:/usr/dt/bin:/usr/openwin/bin:/opt/sfw/bin:/opt/sfw/sbin:/usr/ccs/bin
# I (dkc) added the "me-FIRST...": has some gnu-stuff:
###PATH=/me-FIRST-in-PATH-bin:/sbin:/usr/bin:/usr/sbin:/usr/dt/bin:/usr/openwin/bin:/opt/sfw/bin:/opt/sfw/sbin:/usr/ccs/bin
#
export PATH
PS1="[\W]$ "
export LDFLAGS='-L/usr/openwin/lib -R/usr/openwin/lib -L/opt/sfw/lib
-R/opt/sfw/lib'
export CC=/opt/sfw/bin/gcc
export CXX=/usr/sfw/bin/g++
export CFLAGS='-O2 -pipe -mcpu=ultrasparc'
Been up all night; must crash.
Any ideas?
Thanks!
David
Dave Uhring
> Any ideas?
None, really. I use gcc-3.2.2 built from source using gcc from the
Solaris 9 Software Companion CD; then I pkgrm'd SFWgcc and all of its
dependencies and I no longer have /opt/sfw.
Since Sun chose to add its supported free software in /usr/sfw that is
where I placed the rest of the free software built from source on this
system.
Solaris 9 -does not- "but solaris-NINE wants it in /opt/sfw (I believe
that's who wanted it there, not me)". If you did a complete install of
Solaris 9 you will indeed find much free software in /usr/sfw.
I built emacs-21.3 again and saved all of the output of the configure
script and make and will send it to you via email. Perhaps you can see
from that where your problems lie.
Philip Brown
>Suppose in a case like this, you like the current
>version ok, but want to try the new one.
>
>However, in case it's not so great after all,
>I'd want to keep using the OLD one.
>
>Looking at the blastwave page, it implies (says
>right out!) that the new one gets installed
>OVER the old one -- the old one would be GONE,
>no?
blastwave installs all its packages in /opt/csw
I dont think you installed yours in /opt/csw :-)
"old one" refers to "older blastwave packages"
If you really meant, "how do I try out an older version of a blastwave
package, and a newer version";
ideally, newer blastwave packages are always an improvement over old ones,
otherwise the maintainer would not update the package.
If you find a case where the newer one is worse than the old one, you
should file a bug against the package, on http://www.blastwave.org/bugtrack/
The maintainer should then release a newer "new" version, with your issue
resolved.
Note: Followups set to comp.unix.solaris only ;-)
David Combs
Dave Uhring <daveu...@yahoo.com> wrote:
>On Mon, 26 May 2003 13:13:59 +0000, David Combs wrote:
>
>> Any ideas?
>
>None, really. I use gcc-3.2.2 built from source using gcc from the
>Solaris 9 Software Companion CD; then I pkgrm'd SFWgcc and all of its
>dependencies and I no longer have /opt/sfw.
>
>Since Sun chose to add its supported free software in /usr/sfw that is
>where I placed the rest of the free software built from source on this
>system.
>
>Solaris 9 -does not- "but solaris-NINE wants it in /opt/sfw (I believe
Aaarrgh! You're right (as usual). There's TWO sfw's!
Above, you said you built, from source, gcc, and got rid
of SFWgcc and all it's dependencies.
That I understand.
The "and I no longer have /opt/sfw." -- how did that dissappear?
Presumably not via "and all it's dependencies", but by
deliberate pkgrm of everything there, and then rm -r of /opt/sfw.
But why? There's a HUGE amount of software in /opt/sfw?
I ask because I've gotten to know you well enough to know
that you always (it seems) have really good reasons for whatever
you do.
-----
Suppose you hadn't deleted all of /opt/sfw/, except for the
gcc package there.
What sfw-stuff would you then have on your PATH and LDFLAGS?
Both of them -- every /usr/sfw/... would perhaps be paired with
a /opt/sfw/...?
Dave Uhring
> The "and I no longer have /opt/sfw." -- how did that dissappear?
> Presumably not via "and all it's dependencies", but by
> deliberate pkgrm of everything there, and then rm -r of /opt/sfw.
pkgrm; rm -r
> But why? There's a HUGE amount of software in /opt/sfw?
Only if you put it there. I did not. I installed SFWgcc in order to be
able to build gcc-3.2.2. Once I had gcc-3.2.2 installed I had no more use
for /opt/sfw.
Libraries compiled with gcc-2.95.3 are incompatible with binaries built
with gcc-3.2.2, and I cannot afford the license for Sun's compilers.
> What sfw-stuff would you then have on your PATH and LDFLAGS?
> Both of them -- every /usr/sfw/... would perhaps be paired with
> a /opt/sfw/...?
/opt/sfw does not exist. You have my PATH in the .bashrc file which I
sent you. For others it is:
[duhring]$ echo $PATH
/sbin:/usr/bin:/usr/sbin:/usr/dt/bin:/usr/openwin/bin:/usr/sfw/bin:
/usr/sfw/sbin:/opt/kde/bin:/usr/ccs/bin:
/usr/sfw/share/texmf/bin:/usr/sfw/netpbm/bin:/usr/ucb
[duhring]$ ls /opt
Acrobat5 OpenOffice RealPlayer8 SUNWits SUNWmlib SUNWrtvc build
kde lost+found mozilla qt3 source temp tmp
>>I built emacs-21.3 again and saved all of the output of the configure
>>script and make and will send it to you via email. Perhaps you can see
>>from that where your problems lie.
>>
You will see from the 3 files which I sent you that emacs can indeed be
built on Solaris 9 SPARC. No way in hell I could be bothered to fake all
that ;-)
Dave Uhring
> Libraries compiled with gcc-2.95.3 are incompatible with binaries built
> with gcc-3.2.2, and I cannot afford the license for Sun's compilers.
Oops! Only the libraries built with g++-2.95.3 are incompatible with
binaries built with g++-3.x.x.
Kevin Rodgers
> On Mon, 26 May 2003 13:13:59 +0000, David Combs wrote:
>
>
>>Any ideas?
>>
>
> None, really. I use gcc-3.2.2 built from source using gcc from the
> Solaris 9 Software Companion CD; then I pkgrm'd SFWgcc and all of its
> dependencies and I no longer have /opt/sfw.
>
> Since Sun chose to add its supported free software in /usr/sfw that is
> where I placed the rest of the free software built from source on this
> system.
>
> Solaris 9 -does not- "but solaris-NINE wants it in /opt/sfw (I believe
> that's who wanted it there, not me)". If you did a complete install of
> Solaris 9 you will indeed find much free software in /usr/sfw.
The /opt/sfw (and now /usr/sfw) directory is a bad idea by Sun. Save
yourself some grief and make /usr/local a symbolic link to whichever
directory your version of Solaris came with.
--
<a href="mailto:<kevin.rodgers@ihs.com>">Kevin Rodgers</a>
ger...@gtconnect.net
dkc...@panix.com (David Combs) writes:
> In article <slrnbd1sfl....@bolthole.com>,
> Philip Brown <phi...@bolthole.no-bots.com> wrote:
>>FYI: there are now binaries of emacs 21.3, for solaris 8 and later, on
>>mirror sites of www.blastwave.org
>
> Since I've already got the sources downloaded,
> and I'll probably soon have it "made" ok,
> I probably won't get the blastwave "binary"
> (actually, solaris "package"?).
Its your time to waste : >
> But a question:
>
> Suppose in a case like this, you like the current
> version ok, but want to try the new one.
Then you'll need a different install prefix to support 2 different
instances
> However, in case it's not so great after all,
> I'd want to keep using the OLD one.
>
> Looking at the blastwave page, it implies (says
> right out!) that the new one gets installed
> OVER the old one -- the old one would be GONE,
> no?
The best way is to pkgrm the older before installing the newer
and Im betting blastwave would do just that.
> So, first question: how to be able to restore
> the "old" one?
pkgrm the new pkgadd the old
> Second question (similar): Suppose you want
> to *compare* how they run'; you want to
> be able to run either one, or, for emacs,
> have both running at the same time, switching
> between via switching from one (cde) window
> to another.
> How to do that?
Compile the source with a different --prefix=
then you have 2 different binaries to compare
If you like the new one create your own package and install it.
Anyway yes it can be compiled with all the libs but for whatever
reason ./configure refused to build a proper src/config.h and
src/Makefile for me. No errors in config.log so I edited them
by hand to get all the libs and headers included : <
David Combs
David Combs
>
>> The "and I no longer have /opt/sfw." -- how did that dissappear?
>> Presumably not via "and all it's dependencies", but by
>> deliberate pkgrm of everything there, and then rm -r of /opt/sfw.
>
>pkgrm; rm -r
>
>
>> But why? There's a HUGE amount of software in /opt/sfw?
>
>Only if you put it there. I did not. I installed SFWgcc in order to be
>able to build gcc-3.2.2. Once I had gcc-3.2.2 installed I had no more use
>for /opt/sfw.
>
>Libraries compiled with gcc-2.95.3 are incompatible with binaries built
>with gcc-3.2.2, and I cannot afford the license for Sun's compilers.
What came compiled with gcc-3.2.2?
Anything supplied by Sun -- including in that companion-cd?
I finally managed, yesterday, to get emacs built, and
I had to add opt/sfw/bin to path, and likewise for
the ldflags for the -L and -R pair.
Here -- I'll include what I just got through saying
to someone else in this thread:
----------------------- start:
Finally, just yesterday, using Uhring's ideas and
sample .cshrc, I got it built, Whew!
I used this for LDPATH [sic: LDFLAGS}:
setenv LDFLAGS '-L/usr/openwin/lib -R/usr/openwin/lib -L/usr/sfw/lib -R/usr/sfw/lib -L/opt/sfw/lib -R/opt/sfw/lib'
(One long line; didn't like the \-continuation --
the stuff on the continuation-line never got
into the Makefile, and also got a sed-error
somewhere. My setup must be different from his;
he didn't need the /opt/-stuff either, but for
me, gcc was there.)
------------------------ end.
Also this:
set path=(/sbin /usr/sbin /usr/bin /usr/dt/bin /usr/sfw/bin \
/usr/openwin/bin /usr/ccs/bin /opt/sfw/bin)
ie, yours plus the opt, for gcc.
>
>> What sfw-stuff would you then have on your PATH and LDFLAGS?
>> Both of them -- every /usr/sfw/... would perhaps be paired with
>> a /opt/sfw/...?
>
>/opt/sfw does not exist.
Oh yes it does. During 9's installation,
I must have answered some question differently from you.
>You have my PATH in the .bashrc file which I
>sent you. For others it is:
>
>[duhring]$ echo $PATH
>/sbin:/usr/bin:/usr/sbin:/usr/dt/bin:/usr/openwin/bin:/usr/sfw/bin:
>/usr/sfw/sbin:/opt/kde/bin:/usr/ccs/bin:
>/usr/sfw/share/texmf/bin:/usr/sfw/netpbm/bin:/usr/ucb
>
>
>[duhring]$ ls /opt
>Acrobat5 OpenOffice RealPlayer8 SUNWits SUNWmlib SUNWrtvc build
>kde lost+found mozilla qt3 source temp tmp
Geez -- for me, it's:
cpml$ ls /opt
SUNWits SUNWrtvc SUNWsdocs SUNWspci2
lost+found sfw sun_docs
cpml$
cpml$ cd /opt/sfw
cpml$ ls
GNUstep cups include libexec sbin src
LessTif doc info man share var
READMEs docs kde mysql sparc-sun-solaris2.9 vnc
bin etc lib netpbm squid
cpml$ ls bin
.xmcd_start esdmon ggraph gslj mogrify slrn
ASSound esdplay ggrn gslp montage slrnpull
Animate esdrec ggroups gsnd mpack snort
Audio esdsample ghead gsoelim mpage sortm
Banner etags ghostid gsort mpg123 sox
CDE2Xfcepal ethereal ghostname gspline msgchk soxmix
Cascade eview ghostview gsplit msgcmp sparc-sun-solaris2.9-gcc
<BIG SNIP>
esdctl gfold gshred mlock show
esdfilt ggasp gsize mmroff sliceprint
esdloop ggprof gsleep moc slptool
cpml$ ls sbin
bgpd in.proftpd ipop3d pftpcount pftpwho ripd tcpdump zebra
imapd ipop2d ospfd pftpshut proftpd slpd visudo
cpml$ cd /usr/sfw
cpml$ ls
bin doc include info lib libexec man sbin share src swat
cpml$ ls bin
ant gfgrep jpegtran ncftpget rgb2ycbcr smbtar tiff2bw tiffmedian
antRun ggrep make_printerdef ncftpls rpcclient tclsh8.3 tiff2ps tiffsplit
cjpeg gif2tiff make_smbcodepage ncftpput smbcacls testparm tiff2rgba wget
convert_smbpasswd glib-config make_unicodemap nmblookup smbclient testprns tiffcmp wish8.3
djpeg gtar makeinfo pal2rgb smbcontrol texi2dvi tiffcp wrjpgcom
fax2ps gtk-config ncftp ppm2tiff smbpasswd texi2html tiffdither
fax2tiff info ncftpbatch ras2tiff smbspool texindex tiffdump
gegrep install-info ncftpbookmarks rdjpgcom smbstatus thumbnail tiffinfo
cpml$ ls sbin
nmbd safe_finger smbd swat tcpd tcpdchk tcpdmatch try-from
cpml$
>
>
>>>I built emacs-21.3 again and saved all of the output of the configure
>>>script and make and will send it to you via email. Perhaps you can see
>>>from that where your problems lie.
>>>
>
>You will see from the 3 files which I sent you that emacs can indeed be
>built on Solaris 9 SPARC. No way in hell I could be bothered to fake all
>that ;-)
>
Looks like I really screwed up where I got things placed
during initial install. Even though I had sun-service on
the phone while I did it!
Turns out that I'm getting some of the same problems
I got with 21.2.1 -- I'll have to play with it
with both of them with -q and --no-site-file.
Well, THANK YOU FOR ALL THE HELP!
David
David Combs
Ah, only for C++ compiling.
Well, which ones that you use have been compiled with
the 3.x.x, and which with 2.95.3?
The ones that sun supplies, either straight or
on companion cd, how are *they* compiled?
Thanks
David
David Combs
Thanks.
You mean make /usr/local a symlink to either /opt/sfw or /usr/sfw,
whichever one I have?
Well, probably due to answering some question wrong (or maybe right?),
I have *both*.
Perhaps best to make /usr/local a symlink to something on
a different partition, and keep them all separate,
so that the companion-disk stuff stays in an sfw-dir,
and the stuff I build can go in the /usr/local,
where so much stuff still seems to want to live.
David
Dave Uhring
> What came compiled with gcc-3.2.2?
>
> Anything supplied by Sun -- including in that companion-cd?
AFAIK, every binary supplied by Sun was built using their own compilers.
And those libraries do seem to be compatible with binaries built using
gcc-3.2.2. I have KDE-3.1.1a compiled and installed on this system. KDE
requires libjpeg and I use jpeg supplied with the OE.
[lib]$ pkgchk -l -p /usr/sfw/lib/libjpeg.so.62.0.0
Pathname: /usr/sfw/lib/libjpeg.so.62.0.0
Type: regular file
Expected mode: 0755
Expected owner: root
Expected group: bin
Expected file size (bytes): 140144
Expected sum(1) of contents: 57880
Expected last modification: Mar 02 02:04:51 2002
Referenced by the following packages:
SUNWjpg
Current status: installed
> I finally managed, yesterday, to get emacs built, and
> I had to add opt/sfw/bin to path, and likewise for
> the ldflags for the -L and -R pair.
Had I known that you had installed packages from the Software Companion CD
I would have included those arguments to $LDFLAGS.
>>/opt/sfw does not exist.
>
> Oh yes it does. During 9's installation,
> I must have answered some question differently from you.
/opt/sfw gets created when you install packages from the Software
Companion CD. It is not there otherwise.
> Looks like I really screwed up where I got things placed
> during initial install. Even though I had sun-service on
> the phone while I did it!
Not a screw up as to where things got placed. You simply have to know
where they are and adjust your environment accordingly.