4:01 a.m.
>>>> "Vikas" == Vikas Mishra
<vmishra(a)dal.asp.ti.com> writes:
Vikas> I could not find an e-mail address to which to send a mail
Vikas> to in case of a compile problem. So I am sending this to
Vikas> you.
No problem. FYI, you can use M-x report-emacs-bug (available from the
Help menu, too) or send directly to xemacs-beta(a)xemacs.org. I am
cc'ing this message there, so you needn't resend.
It looks to me like you may have a problem in your GCC installation,
where certain compiler helper functions or macros (__builtin_va_alist)
are not getting defined. Beyond that I can't say; I hope the Solaris
users on xemacs-beta will be able to give further help.
Vikas> I was trying to build Xemacs on Solaris 2.7 and am getting
Vikas> the following error while trying to compile the source.
--BEGIN_SNIPPET__
gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow
-Wsign-compare -Wpointer-arith -Demacs -I. -DHAVE_CONFIG_H
-I/usr/include -I/usr/local/include -I/usr/dt/include -I/usr/dt/include
-I/usr/openwin/include/ bytecode.c
bytecode.c: In function `funcall_compiled_function':
bytecode.c:486: warning: comparison between signed and unsigned
bytecode.c: In function `invalid_byte_code_error':
bytecode.c:1492: `__builtin_va_alist' undeclared (first use in this
function)
bytecode.c:1492: (Each undeclared identifier is reported only once
bytecode.c:1492: for each function it appears in.)
bytecode.c:1488: warning: `args' might be used uninitialized in this
function
bytecode.c: In function `Fbyte_code':
bytecode.c:2402: warning: comparison between signed and unsigned
gmake[1]: *** [bytecode.o] Error 1
gmake[1]: Leaving directory `/home/vmishra/xemacs-21.4.2/src'
gmake: *** [src] Error 2
__END_SNIPPET__
I tried to look at the file bytecode.c but was unable to determine the
cause of the error.
Could you tell me what needs to be done to fix this ?
Regards,
Vikas
My installation is described below :
-------------------------------------
uname -a: SunOS lift 5.7 Generic_106541-14 sun4u sparc SUNW,Ultra-5_10
./configure '--prefix=/home/vmishra/xemacs'
'--x-includes=/usr/openwin/include/' '--x-libraries=/usr/openwin/lib/'
'--site-includes=/usr/include /usr/local/include /usr/dt/include'
'--site-libraries=/usr/lib /usr/local/lib /usr/dt/lib'
'--with-menubars=lucid' '--with-xpm' '--with-xface'
'--with-socks'
'--with-cde' '--with-sound=native' '--with-xim'
XEmacs 21.4.2 "Developer-Friendly Unix APIs" configured for
`sparc-sun-solaris2.7'.
Compilation / Installation:
Source code location: /home/vmishra/xemacs-21.4.2
Installation prefix: /home/vmishra/xemacs
Additional header files: /usr/include /usr/local/include
/usr/dt/include
Additional libraries: /usr/lib /usr/local/lib /usr/dt/lib
Runtime library search path:
/usr/ccs/lib:/usr/local/lib:/usr/dt/lib:/usr/openwin/lib/:/usr/local/gcc/2.95.2/lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.2
Operating system description file: `s/sol2.h'
Machine description file: `m/sparc.h'
Compiler: gcc -g -O3 -Wall -Wno-switch
-Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Wpointer-arith
Relocating allocator for buffers: yes
GNU version of malloc: yes
Window System:
Compiling in support for the X window system:
- X Windows headers location: /usr/dt/include
/usr/openwin/include/
- X Windows libraries location: /usr/dt/lib
/usr/openwin/lib/
- Handling WM_COMMAND properly.
Using Lucid menubars.
Using Lucid scrollbars.
Using Motif dialog boxes.
Using Motif native widgets.
TTY:
Compiling in support for ncurses.
Images:
Compiling in support for GIF images (builtin).
Compiling in support for XPM images.
Compiling in support for PNG images.
Compiling in support for JPEG images.
Compiling in support for TIFF images.
Compiling in support for X-Face message headers.
Sound:
Compiling in support for sound (native).
Databases:
Compiling in support for GNU DBM.
Compiling in support for LDAP.
Internationalization:
Mail:
Compiling in support for "dot-locking" mail spool file locking method.
Other Features:
Compiling in support for ToolTalk.
Compiling in support for SOCKS.
Compiling in support for dynamic shared object modules.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
8:03 a.m.
Stephen J. Turnbull writes:
It looks to me like you may have a problem in your GCC installation,
where certain compiler helper functions or macros (__builtin_va_alist)
are not getting defined. Beyond that I can't say; I hope the Solaris
users on xemacs-beta will be able to give further help.
The following two lines indicate the problem:
uname -a: SunOS lift 5.7 Generic_106541-14 sun4u sparc
SUNW,Ultra-5_10
/usr/ccs/lib:/usr/local/lib:/usr/dt/lib:/usr/openwin/lib/:/usr/local/gcc/2.95.2/lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.2
You're using a 2.5.1 version of gcc running on 2.7, which has been
known to cause hosts of problems. You need to reinstall gcc
(<ftp://ftp.sunfreeware.com/pub/freeware/sparc/7/gcc-2.95.3-sol7-sparc-loca...
if you don't feel like recompiling it) or use the Sun compiler.
Robert
--
3:20 p.m.
On Thu, 07 Jun 2001 12:01:06 +0900, "Stephen J. Turnbull" said:
uname -a: SunOS lift 5.7 Generic_106541-14 sun4u sparc
SUNW,Ultra-5_10
/usr/ccs/lib:/usr/local/lib:/usr/dt/lib:/usr/openwin/lib/:/usr/local/gcc/2.95.2/lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.2
Ah yes. GCC, the portable compiler that has to be kept in fascist lockstep
with your operating system. Looks like you built it under 2.5.1, and run
it under 2.7. Compile-time errors are probably caused by the GCC penchant
for running fuxincludes and stashing copies in a private directory where
they will cause problems if you ever install patches to your system.
It's not GCC's job to provide a working /usr/include - that's the
vendor's
job. The "excuse" that gcc needs to do this to work is a crock.
/Valdis (who boycotts gcc on platforms that have a vendor compiler, for exactly
this reason).
7:32 p.m.
On Thu, 07 Jun 2001, Valdis Kletnieks said:
On Thu, 07 Jun 2001 12:01:06 +0900, "Stephen J. Turnbull"
said:
> uname -a: SunOS lift 5.7 Generic_106541-14 sun4u sparc SUNW,Ultra-5_10
>
/usr/ccs/lib:/usr/local/lib:/usr/dt/lib:/usr/openwin/lib/:/usr/local/gcc/2.95.2/lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.2
Ah yes. GCC, the portable compiler that has to be kept in fascist lockstep
with your operating system. Looks like you built it under 2.5.1, and run
That's not what `portable' means.
it under 2.7. Compile-time errors are probably caused by the GCC
penchant
for running fuxincludes and stashing copies in a private directory where
they will cause problems if you ever install patches to your system.
Not in this case, no. Modern GCCs do not run fixincludes on Solaris,
because Solaris's includes are OK these days. However, there are lots of
other platform-specificities that changed between 2.5.1 and 2.7 that
must be compensated for.
It's not GCC's job to provide a working /usr/include -
that's the vendor's
job. The "excuse" that gcc needs to do this to work is a crock.
And how would you suggest coping with grossly nonstandard headers? We
can't order the vendors to fix them, and even if they do there will be
people who never upgrade from the versions with the broken
headers. IMHO, it is better to find a kludge to work on those platforms
than to leave those people without a working GCC.
/Valdis (who boycotts gcc on platforms that have a vendor compiler,
for exactly
this reason).
It's a strange reason. Avoid GCC on platforms where the vendor compiler
is better and you're not cross-compiling, sure, but `boycotting' it
because of broken vendor headers (i.e. no fault of GCC's!) is just
silly.
(It is true that there should be a way to rerun fixincludes after GCC is
installed; GCC 3, due out in a week, will already warn if your
fixincluded headers are outdated, and discussions on a rerunnable
fixincludes are underway on the GCC list even now. Well, even last week,
the last time I had time to read it.)
--
`"This code is gross!" meaning "This code has over 144 compilation
errors."'
--- Correct use of English, from jer
5:45 a.m.
On Sat, 09 Jun 2001 19:32:26 BST, Nix said:
On Thu, 07 Jun 2001, Valdis Kletnieks said:
> /Valdis (who boycotts gcc on platforms that have a vendor compiler, for exactly
> this reason).
It's a strange reason. Avoid GCC on platforms where the vendor compiler
is better and you're not cross-compiling, sure, but `boycotting' it
because of broken vendor headers (i.e. no fault of GCC's!) is just
silly.
No, I boycott it because GCC insists on stashing copies of stuff from
/usr/include, which results in strange breakage and failure modes after
patches have been applied. You find a header problem, report it to the
vendor, get a patch, apply it - and GCC won't see the fix, or will barf
in OTHER strange ways because it's got out-of-sync headers.
A case could be made that the 'fixincludes' *hurts* the cause of
getting header files fixed - for instance, IBM *HAS* taken bug
reports on things like /bin/ld that *only* break with gcc, but not
with their compiler. If fixincludes didn't cover up the problem, then
I could tell IBM "This header file has problem XYZ - fix it so GCC will
accept it". It's a lot harder to get IBM to fix it when the product
already works around it.
Personally, I'd settle for a --diable-fixincludes flag on the ./configure.
/Valdis
11:38 a.m.
On Sun, 10 Jun 2001, Valdis Kletnieks gibbered:
On Sat, 09 Jun 2001 19:32:26 BST, Nix said:
> On Thu, 07 Jun 2001, Valdis Kletnieks said:
> > /Valdis (who boycotts gcc on platforms that have a vendor compiler, for exactly
> > this reason).
>
> It's a strange reason. Avoid GCC on platforms where the vendor compiler
> is better and you're not cross-compiling, sure, but `boycotting' it
> because of broken vendor headers (i.e. no fault of GCC's!) is just
> silly.
No, I boycott it because GCC insists on stashing copies of stuff from
/usr/include, which results in strange breakage and failure modes after
patches have been applied. You find a header problem, report it to the
vendor, get a patch, apply it
Normally that goes `report it to the vendor, vendor ignores you', or, if
you're lucky, `report it to the vendor, vendor says `it's fixed in the
next version' --- and what do we do then? Refuse to support the older
version, when we have a perfectly good (if kludgy) mechanism for
supporting it, after a fashion?
- and GCC won't see the fix, or
will barf
in OTHER strange ways because it's got out-of-sync headers.
It will give you a perfectly clear warning regarding outdated fixed
headers as of GCC 3. (This area was lacking before that, to be sure.)
A case could be made that the 'fixincludes' *hurts* the cause
of
getting header files fixed
You're quite right; it does reduce the incentive to vendors to fix them;
however, if the choice is cleaner vendor headers against people using
older versions of the OS that are incapable of using GCC *just because
of the headers* then I know what I'd rather do.
(Besides, when the vendors *do* fix their headers, those headers are no
longer fixed by GCC.)
If fixincludes didn't cover up the problem,
then
I could tell IBM "This header file has problem XYZ - fix it so GCC will
accept it".
Delete the fixincluded headers and you can still do that.
It's a lot harder to get IBM to fix it when the
product
already works around it.
Most of the faults that fixincludes fixes are quite obvious; a diff
between the fixed headers and the unfixed ones might almost be enough
for them. If IBM can't do *that*, I have *no* sympathy. (And I know that
some of them can do that!)
Personally, I'd settle for a --diable-fixincludes flag on the
./configure.
This would, in many cases, prevent GCC from building at all.
(But this is all offtopic for xemacs-beta anyway.)
--
`"This code is gross!" meaning "This code has over 144 compilation
errors."'
--- Correct use of English, from jer
5:38 a.m.
>>>> "Nix" == Nix
<nix(a)esperi.demon.co.uk> writes:
> - and GCC won't see the fix, or will barf in OTHER strange
ways
> because it's got out-of-sync headers.
Nix> It will give you a perfectly clear warning regarding outdated
Nix> fixed headers as of GCC 3. (This area was lacking before
Nix> that, to be sure.)
But this is Valdis's entire complaint, AFAICT. It's certainly mine.
GCC fixes (mostly) and breaks (altogether too often) a user's system
without telling him about it. And it keeps the evidence in a private
directory that can be rather hard to find if he's not used to the
strange ways of GCC. But those are the precise systems where the
includes are fuxed.
"As of GCC 3" is basically pleading nolo contendere, IMHO.
Nix> (But this is all offtopic for xemacs-beta anyway.)
Unfortunately, it is not. The report that started this thread came to
us. In particular, ME PERSONALLY. Not to bug-gcc. And it is a FAQ.
I don't have time or access to all the platforms where GCC does this
kind of thing (I develop on Linux). If it comes down to me answering
the question, I'm not going to read GCC docs and/or sources, I'm going
to say "Not Linux or *BSD? The first thing to try is a non-GCC compiler."
I'm sure that makes GCC developers unhappy, though. Pity, that. It's
not clear to me that being in a position where I feel it appropriate
to recommend avoiding GCC on many platforms is good for XEmacs, either.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
9:10 p.m.
On Mon, 11 Jun 2001, Stephen J. Turnbull gibbered:
>>>>> "Nix" == Nix
<nix(a)esperi.demon.co.uk> writes:
>> - and GCC won't see the fix, or will barf in OTHER strange ways
>> because it's got out-of-sync headers.
Nix> It will give you a perfectly clear warning regarding outdated
Nix> fixed headers as of GCC 3. (This area was lacking before
Nix> that, to be sure.)
But this is Valdis's entire complaint, AFAICT. It's certainly mine.
And mine, for what it's worth. It damned well should always have
emitted a warning when an outdated fixed header was used.
GCC fixes (mostly) and breaks (altogether too often) a user's
system
without telling him about it.
Breakage is, of course, a bug. It happens :( it's fairly rare in my
experience, but then I'm normally using rather aged boxes, and it's
newer OS releases that cause breakage (and fixincludes is not the only
culprit).
"As of GCC 3" is basically pleading nolo contendere, IMHO.
It's due out on Friday; it's not as though I'm saying `sometime in the
future it will...'; rather `it already does but you asked the question a
week too early'. (But this will not help everyone using earlier GCC's
until they upgrade, of course.)
Nix> (But this is all offtopic for xemacs-beta anyway.)
Unfortunately, it is not. The report that started this thread came to
us. In particular, ME PERSONALLY. Not to bug-gcc.
Oops :( All I can suggest is mentioning the incorrect fix to the GCC
list, really :(
Fixed headers are a kludge, but they're the best of a bad bunch of
possible options (the only other ones are `fall over when perfectly
valid programs are compiled, because of buggy vendor headers' (which is
of course not on) and `don't support systems with buggy vendor headers'
(which rules out 95% of the proprietary Unix OSes out there).
Probably the biggest problem with fixed headers is that in the past some
of the fixes have been rather too wide-ranging, and tended to pick up
dozens of headers with nothing actually wrong with them (because they
were exclusively regex-driven, once, so they couldn't e.g. spot comments
properly). This, again, is much less the case in GCC 3, and in fact it's
my unsupported impression that it's much less a problem in gcc-2.95 than
in earlier releases. Certainly egcs-1.0.x had the habit of fixing the
world when the world had nothing wrong with it...
I don't have time or access to all the platforms where GCC does
this
kind of thing (I develop on Linux).
fixincludes is run on Linux, because of bugs in some glibc releases.
If it comes down to me answering
the question, I'm not going to read GCC docs and/or sources, I'm going
to say "Not Linux or *BSD? The first thing to try is a non-GCC compiler."
It's my impression that many of them are too broken to bother
with. Certainly given the choice between, say, HP's compiler and GCC I'd
leap at GCC. (DEC's compiler in OSF/1 and Tru64 is very nice, though; I
prefer it to GCC on OSF/1 boxes.)
I'm sure that makes GCC developers unhappy, though. Pity, that.
It's
not clear to me that being in a position where I feel it appropriate
to recommend avoiding GCC on many platforms is good for XEmacs, either.
You could have configure.in print out a warning about possible fixed
header problems if GCC<3 was being used on all platforms except for
DG/UX, Interix, IRIX, Dynix/PTX, sco-*, NT, GNU (Linux and the HURD),
and perhaps the BSDs. (Except for the BSDs, those platforms have a small
set of hardwired fixes rather than the 68K list applied to other
platforms.)
I think fixed headers suck, too. I also think that they, or something
like them, are unavoidable if GCC is to support anywhere near as many
systems as it does without spamming the user with scads of incorrect
warnings and gratuitous errors and failures arising from brokennesses in
the vendor includes. Still, at least they're self-contained (in the
gcc/fixinc/ subdirectory).
FWIW the person to send new fixes to, or to notify of fixes that are
biting where they should not, is Bruce Korb <bkorb(a)gnu.org>.
--
`"This code is gross!" meaning "This code has over 144 compilation
errors."'
--- Correct use of English, from jer
10:31 p.m.
On Mon, 11 Jun 2001 21:10:47 BST, Nix said:
And mine, for what it's worth. It damned well should always have
emitted a warning when an outdated fixed header was used.
Yes.
Probably the biggest problem with fixed headers is that in the past
some
of the fixes have been rather too wide-ranging, and tended to pick up
dozens of headers with nothing actually wrong with them (because they
And this is the OTHER part of my complaint - on an AIX system, it would
fix a lot of non-broken stuff. Just for giggles, I grabbed a copy of
gcc 2.95.3, and here's the sort of thing it did when I built it under AIX 4.3.3:
*** locale.h Mon Jun 11 11:44:45 2001
--- /usr/include/locale.h Thu Sep 18 22:02:57 1997
***************
*** 45,51 ****
#ifdef _ANSI_C_SOURCE
#ifndef NULL
! #define NULL 0
#endif /* NULL */
struct lconv {
--- 45,51 ----
#ifdef _ANSI_C_SOURCE
#ifndef NULL
! #define NULL ((void *)0)
#endif /* NULL */
struct lconv {
Yee-haw.
10:59 p.m.
On Mon, 11 Jun 2001, Valdis Kletnieks said:
And this is the OTHER part of my complaint - on an AIX system, it
would
fix a lot of non-broken stuff. Just for giggles, I grabbed a copy of
gcc 2.95.3, and here's the sort of thing it did when I built it under AIX 4.3.3:
Aha, well this is not *necessarily* an error :)
*** locale.h Mon Jun 11 11:44:45 2001
--- /usr/include/locale.h Thu Sep 18 22:02:57 1997
***************
*** 45,51 ****
#ifdef _ANSI_C_SOURCE
#ifndef NULL
! #define NULL 0
#endif /* NULL */
struct lconv {
--- 45,51 ----
#ifdef _ANSI_C_SOURCE
#ifndef NULL
! #define NULL ((void *)0)
#endif /* NULL */
This is the Void_Null fix. That part of that header file may be compiled
by G++ (it's not obviously guarded by `#ifndef __cplusplus' or similar),
and in C++ ((void *)0) is an unwise definition for the null pointer
constant, because that runs foul of C++'s strong typing; in both C and
C++, 0 is a better definition. So we fix it to stop G++ giving lots of
fatal errors on fairly elementary C programs.
Now it may be that the `#ifdef _ANSI_C_SOURCE' I see at the top of that
hunk is supposed to prevent this code being compiled by a C++ compiler;
but, if so, they should have used #ifndef __cplusplus. `_ANSI_C_SOURCE'
is just, well, silly, and fixincludes doesn't know what it means.
(I can't think of any way of determining that some random preprocessor
token means `C++ will not see this code' in the general case, except for
some kind of hideous static analyser hooking into the C preprocessor and
determining that `this must always be on if this is on' and so forth,
and tracing back to __cplusplus and __STDC__ --- and even that won't
spot #defines that the vendor compiler turns on and that GCC doesn't yet
know that it turns on. Certainly GCC-2.95.3's essentially regex-based
fixincludes wouldn't have spotted it.)
I'd say that that fix is correct, within fixincludes's limited
capabilities, and even a much more powerful fixincluder would probably
have had to apply that transformation in that case (without a complete
locale.h and all headers it includes above that point on that platform,
I can't *guarantee* that it is required for proper C++ functioning,
though).
--
`"This code is gross!" meaning "This code has over 144 compilation
errors."'
--- Correct use of English, from jer
7:27 p.m.
>>>> "ST" == Stephen J Turnbull
<turnbull(a)sk.tsukuba.ac.jp> writes:
>>>> "Vikas" == Vikas Mishra
<vmishra(a)dal.asp.ti.com> writes:
Vikas> I could not find an e-mail address
to which to send a mail
Vikas> to in case of a compile problem. So I am sending this to
Vikas> you.
ST> No problem. FYI, you can use M-x report-emacs-bug (available from the
ST> Help menu, too) or send directly to xemacs-beta(a)xemacs.org. I am
ST> cc'ing this message there, so you needn't resend.
ST> It looks to me like you may have a problem in your GCC installation,
ST> where certain compiler helper functions or macros (__builtin_va_alist)
ST> are not getting defined. Beyond that I can't say; I hope the Solaris
ST> users on xemacs-beta will be able to give further help.
Vikas> I was trying to build Xemacs on Solaris 2.7 and am getting
Vikas> the following error while trying to compile the source.
ST> --BEGIN_SNIPPET__
ST> gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow
ST> -Wsign-compare -Wpointer-arith -Demacs -I. -DHAVE_CONFIG_H
ST> -I/usr/include -I/usr/local/include -I/usr/dt/include -I/usr/dt/include
ST> -I/usr/openwin/include/ bytecode.c
Rule for gcc users: You must not use -I/usr/include on your command
line! This defeats the fixinclude stuff the gcc is doing and it may be
fatal for files like varargs.h and stdargs.h!
gcc uses by default /usr/include as the last on its list of include
directories and that's where it belongs!
I've seen all the other posts and they are valid too but they will
probably not solve this particular compile time error.
So get a newer version of the gcc and configure your build without
-I/usr/include on the compile comand line and everything shoudl work
fine;-)
Thanks,
-- Marco
ST> bytecode.c: In function `funcall_compiled_function':
ST> bytecode.c:486: warning: comparison between signed and unsigned
ST> bytecode.c: In function `invalid_byte_code_error':
ST> bytecode.c:1492: `__builtin_va_alist' undeclared (first use in this
ST> function)
ST> bytecode.c:1492: (Each undeclared identifier is reported only once
ST> bytecode.c:1492: for each function it appears in.)
ST> bytecode.c:1488: warning: `args' might be used uninitialized in this
ST> function
ST> bytecode.c: In function `Fbyte_code':
ST> bytecode.c:2402: warning: comparison between signed and unsigned
ST> gmake[1]: *** [bytecode.o] Error 1
ST> gmake[1]: Leaving directory `/home/vmishra/xemacs-21.4.2/src'
ST> gmake: *** [src] Error 2
ST> __END_SNIPPET__
ST> I tried to look at the file bytecode.c but was unable to determine the
ST> cause of the error.
ST> Could you tell me what needs to be done to fix this ?
ST> Regards,
ST> Vikas
ST> My installation is described below :
ST> -------------------------------------
ST> uname -a: SunOS lift 5.7 Generic_106541-14 sun4u sparc SUNW,Ultra-5_10
ST> ./configure '--prefix=/home/vmishra/xemacs'
ST> '--x-includes=/usr/openwin/include/'
'--x-libraries=/usr/openwin/lib/'
ST> '--site-includes=/usr/include /usr/local/include /usr/dt/include'
ST> '--site-libraries=/usr/lib /usr/local/lib /usr/dt/lib'
ST> '--with-menubars=lucid' '--with-xpm' '--with-xface'
'--with-socks'
ST> '--with-cde' '--with-sound=native' '--with-xim'
ST> XEmacs 21.4.2 "Developer-Friendly Unix APIs" configured for
ST> `sparc-sun-solaris2.7'.
ST> Compilation / Installation:
ST> Source code location: /home/vmishra/xemacs-21.4.2
ST> Installation prefix: /home/vmishra/xemacs
ST> Additional header files: /usr/include /usr/local/include
ST> /usr/dt/include
ST> Additional libraries: /usr/lib /usr/local/lib /usr/dt/lib
ST> Runtime library search path:
ST>
/usr/ccs/lib:/usr/local/lib:/usr/dt/lib:/usr/openwin/lib/:/usr/local/gcc/2.95.2/lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.2
ST> Operating system description file: `s/sol2.h'
ST> Machine description file: `m/sparc.h'
ST> Compiler: gcc -g -O3 -Wall -Wno-switch
ST> -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Wpointer-arith
ST> Relocating allocator for buffers: yes
ST> GNU version of malloc: yes
ST> Window System:
ST> Compiling in support for the X window system:
ST> - X Windows headers location: /usr/dt/include
ST> /usr/openwin/include/
ST> - X Windows libraries location: /usr/dt/lib
ST> /usr/openwin/lib/
ST> - Handling WM_COMMAND properly.
ST> Using Lucid menubars.
ST> Using Lucid scrollbars.
ST> Using Motif dialog boxes.
ST> Using Motif native widgets.
ST> TTY:
ST> Compiling in support for ncurses.
ST> Images:
ST> Compiling in support for GIF images (builtin).
ST> Compiling in support for XPM images.
ST> Compiling in support for PNG images.
ST> Compiling in support for JPEG images.
ST> Compiling in support for TIFF images.
ST> Compiling in support for X-Face message headers.
ST> Sound:
ST> Compiling in support for sound (native).
ST> Databases:
ST> Compiling in support for GNU DBM.
ST> Compiling in support for LDAP.
ST> Internationalization:
ST> Mail:
ST> Compiling in support for "dot-locking" mail spool file locking method.
ST> Other Features:
ST> Compiling in support for ToolTalk.
ST> Compiling in support for SOCKS.
ST> Compiling in support for dynamic shared object modules.
ST> --
ST> University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
ST> Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
ST> _________________ _________________ _________________ _________________
ST> What are those straight lines for? "XEmacs rules."
--
1:43 p.m.
Marco Walther writes:
<SNIP>
Rule for gcc users: You must not use -I/usr/include on your command
line! This defeats the fixinclude stuff the gcc is doing and it may be
fatal for files like varargs.h and stdargs.h!
gcc uses by default /usr/include as the last on its list of include
directories and that's where it belongs!
I've seen all the other posts and they are valid too but they will
probably not solve this particular compile time error.
So get a newer version of the gcc and configure your build without
-I/usr/include on the compile comand line and everything shoudl work
fine;-)
Thanks folks, I did both of them. I logged on to a mchine with solaris 2.5
and did not specify /usr/include as the site includes and it compiled
without any problem.
Thanks,
Vikas
8547
days inactive
8551
days old
11 comments
6 participants
participants (6)
-
Marco Walther -
Nix -
Robert Pluim -
Stephen J. Turnbull -
Valdis Kl=?iso8859-4?Q?=BA?=tnieks -
Vikas Mishra