Compiling bash-1.13.4 with GCC 2.4.5

Compiling bash-1.13.4 with GCC 2.4.5

Post by Anthony Love » Sat, 18 Dec 1993 23:30:58



I've recently compiled bash-1.13.4 under linux 0.99.14 using GCC 2.4.5
and have come across a small problem. The compile fails in waitstatus.h
with an error that seems impossible, I've included the relevent sections
of the include files, what happens is that somehow the tests

#if __BYTE_ORDER == _LITTLE_ENDIAN
and
#if __BYTE_ORDER == _BIG_ENDIAN

both return true and it tries to include both sections. By editing the
include to contain only the little endian defs I was able to compile
cleanly.
Does anybody have any idea why this should be.

/usr/include/waitstatus.h

#ifdef          __USE_BSD

#include <endian.h>

union wait
  {
    int w_status;
    struct
      {
#if     __BYTE_ORDER == __LITTLE_ENDIAN
        unsigned int __w_termsig:7; /* Terminating signal.  */
        unsigned int __w_coredump:1; /* Set if dumped core.  */
        unsigned int __w_retcode:8; /* Return code if exited normally.  */
        unsigned int:16;
#endif                                  /* Little endian.  */
#if     __BYTE_ORDER == __BIG_ENDIAN
        unsigned int:16;
        unsigned int __w_retcode:8;
        unsigned int __w_coredump:1;
        unsigned int __w_termsig:7;
#endif                                  /* Big endian.  */
      } __wait_terminated;
    struct
      {
#if     __BYTE_ORDER == __LITTLE_ENDIAN
        unsigned int __w_stopval:8; /* W_STOPPED if stopped.  */
        unsigned int __w_stopsig:8; /* Stopping signal.  */
        unsigned int:16;
#endif                                  /* Little endian.  */
#if     __BYTE_ORDER == __BIG_ENDIAN
        unsigned int:16;
        unsigned int __w_stopsig:8; /* Stopping signal.  */
        unsigned int __w_stopval:8; /* W_STOPPED if stopped.  */
#endif                                  /* Big endian.  */
      } __wait_stopped;
  };

/usr/include/endian.h

/* Definitions for byte order, according to significance of bytes, from low
   addresses to high addresses.  The value is what you get by putting '4'
   in the most significant byte, '3' in the second most significant byte,
   '2' in the second least significant byte, and '1' in the least
   significant byte.  */

#define         __LITTLE_ENDIAN 1234
#define         __BIG_ENDIAN    4321
#define         __PDP_ENDIAN    3412

/* This file defines `__BYTE_ORDER' for the particular machine.  */
#include <bytesex.h>

#ifdef          __USE_BSD
#define         LITTLE_ENDIAN   __LITTLE_ENDIAN
#define         BIG_ENDIAN      __BIG_ENDIAN
#define         PDP_ENDIAN      __PDP_ENDIAN
#define         BYTE_ORDER      __BYTE_ORDER
#endif

/usr/include/bytesex.h

#ifndef _BYTESEX_H
#define _BYTESEX_H

#undef __BYTE_ORDER
#define __BYTE_ORDER    1234

#endif /* _BYTESEX_H */

 
 
 

Compiling bash-1.13.4 with GCC 2.4.5

Post by J. M. O'Donne » Fri, 24 Dec 1993 04:37:00





>|> +---------------
>|> | I've recently compiled bash-1.13.4 under linux 0.99.14 using GCC 2.4.5
>|> | and have come across a small problem. The compile fails in waitstatus.h
>|> | with an error that seems impossible, I've included the relevent sections
>|> | of the include files, what happens is that somehow the tests
>|> |
>|> | #if __BYTE_ORDER == _LITTLE_ENDIAN
>|> | and
>|> | #if __BYTE_ORDER == _BIG_ENDIAN
>|> +---------------
>|>
>|> bash comes with a file endian.h and specifies -I. in the gcc command line, so
>|> it overrides the use of /usr/include/endian.h.  So the symbols are never
>|> defined and the #if's are all taken as #if 0 == 0 (both true).
>|>
>|> My hackaround was to add "#include_next <endian.h>" at the top of bash's
>|> endian.h.  Other solutions are also possible.
>|>

>I think I just removed endian.h.

>H.J.

Bash-1.13.5 does not seem to have this problem.

JMOD.

 
 
 

1. type ahead problem in bash-1.12 & bash-1.13.4

I'm experiencing a type-ahead problem with bash-1.12 and bash-1.13.4 on
Solaris 2.2: look at these lines: the commands have all been typed
before the first one finishes.
The only command that is executed then is "sleep 1"... What have the
others become ?

bash$sleep 10
sleep 1
sleep 2
sleep 3
sleep 4
bash$sleep 1
bash$

Has anyone else experienced the same problem and/or got the solution ?
Is this a known bug ?

(This bug only comes up on Solaris, it seems. I tried to trigger it on
a couple of machines, a SUN running SunOS 4.1.3 and a SYSV machine very
little known outside of France, on which we managed to compile and run
bash, but it never happened...)

Thanks for any help...

Bruno
--

Centre de Programmation de la Marine |   celles qui savent compter,
Paris, FRANCE                        |   et celles qui ne savent pas..."

2. Too many files open...

3. BASH BASH BASH BASH BASH BASH BASH BASH BASH BASH

4. please help with port forwarding

5. Bash for SCO that compiles with GCC

6. Mod_rewrite and its lock file on Apache 2

7. * Trouble compiling BASH using gcc under Solaris 2.5 x86 *

8. New to Linux, Flavor questions

9. bash-1.3.4 won't compile on Solaris 2.2

10. Compiling Bash-1.14.3 on Solaris 2.4

11. Compiling gcc 2.7.2.1 with gcc 3.2 on redhat 8.0

12. GCC-i2.6.3 compiling (gcc with pentium optimiz's) PLEASE HELP US!!

13. OpenBSD, GCC, ElectricFence, and PThreads -- order on gcc compile line is significant?