Thread

  1. Re: [HACKERS] port/getrusage.c?

    Hal Snyder <hal@vailsys.com> — 1998-03-12T06:51:23Z

    > From: dg@illustra.com (David Gould)
    > Date: Wed, 11 Mar 1998 22:37:59 -0800 (PST)
    
    ...
    > > Good question. I don't see one, but the config stuff is not familiar
    > > ground. There is reference to "sco" on line 85 of
    > > 
    > >   src/include/utils/memutils.h - "#if ! defined(sco)"
    > > 
    > > but I think nothing sets this any more. (Actually this is another
    > > thing on the list of SCO breakage in 6.3). I'd add something to the
    > > template for sco.
    
    > What is the policy for defines on Postgres?
    > 
    > It is often suggested that that 'ifdef defined(RANDOM_PLATFORM)' is not a
    > nice way to proceed. Far better to use for example 'defined(HAS_FEATURE_XYZ)'
    > than something like:
    > 
    > 'defined(SOLARIS) or defined(SUNOS) or defined(PYRAMID) && !defined(WIN32)'.
    > 
    > In the case at hand, perhaps something like  'if defined(BROKEN_CPP_GCC_271)',
    > and then define it in the SCO part of the build system. After all, SCO
    > might survive long enough to upgrade to a current compiler...
    
    Ack. How about changing
    
      CFLAGS:
    
    to
    
      CFLAGS:-DLAME_CPP
    
    in src/templates/sco?
    
    
    
  2. Re: [HACKERS] port/getrusage.c?]

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-03-12T13:42:58Z

    > > 'defined(SOLARIS) or defined(SUNOS) or defined(PYRAMID) && !defined(WIN32)'.
    > > 
    > > In the case at hand, perhaps something like  'if defined(BROKEN_CPP_GCC_271)',
    > > and then define it in the SCO part of the build system. After all, SCO
    > > might survive long enough to upgrade to a current compiler...
    > 
    > Ack. How about changing
    > 
    >   CFLAGS:
    > 
    > to
    > 
    >   CFLAGS:-DLAME_CPP
    > 
    > in src/templates/sco?
    
    But we don't want that if they use a good compiler under SCO.  I have
    asked them to run src/tools/ccsym and send the output.  Should be
    something unique in there.
    
    -- 
    Bruce Momjian                          |  830 Blythe Avenue
    maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
      +  If your life is a hard drive,     |  (610) 353-9879(w)
      +  Christ can be your backup.        |  (610) 853-3000(h)
    
    
  3. SCO vs. the monster macro

    Hal Snyder <hal@vailsys.com> — 1998-03-12T20:55:29Z

    > But we don't want that if they use a good compiler under SCO.  I have
    > asked them to run src/tools/ccsym and send the output.  Should be
    > something unique in there.
    
    On SCO, ccsym becomes /bin/cc -b elf -ii -E foo.c, which after filtering
    gives the symbols below. If I omit "-b elf", the last line is replaced
    by the two lines
    '-D_M_COFF'
    '-D_SCO_COFF'
    
    How about _SCO_DS as the define when testing for SCO's native
    compiler? (I confess ignorance as to SCO's intended use of this symbol.)
    
    '-D__i386'
    '-D_SCO_DS=1'
    '-D__unix'
    '-D_M_I386'
    '-D_M_XENIX'
    '-D_M_UNIX'
    '-D_SCO_C_DIALECT=1'
    '-D_STRICT_NAMES'
    '-D_M_I86'
    '-D_M_I86SM'
    '-D_M_SDATA'
    '-D_M_STEXT'
    '-D_M_BITFIELDS'
    '-D_M_INTERNAT'
    '-D_M_SYS5'
    '-D_M_SYSV'
    '-D_M_SYSIII'
    '-D_M_WORDSWAP'
    '-Di386'
    '-Dunix'
    '-DM_I386'
    '-DM_UNIX'
    '-DM_XENIX'
    '-D_SCO_XPG_VERS=4'
    '-D_SCO_ELF'
    
    
    
  4. Re: [HACKERS] SCO vs. the monster macro

    David Gould <dg@illustra.com> — 1998-03-12T21:12:41Z

    > > But we don't want that if they use a good compiler under SCO.  I have
    > > asked them to run src/tools/ccsym and send the output.  Should be
    > > something unique in there.
    > 
    > On SCO, ccsym becomes /bin/cc -b elf -ii -E foo.c, which after filtering
    > gives the symbols below. If I omit "-b elf", the last line is replaced
    > by the two lines
    > '-D_M_COFF'
    > '-D_SCO_COFF'
    > 
    > How about _SCO_DS as the define when testing for SCO's native
    > compiler? (I confess ignorance as to SCO's intended use of this symbol.)
    > 
    > '-D__i386'
    > '-D_SCO_DS=1'
    > '-D__unix'
    > '-D_M_I386'
    > '-D_M_XENIX'
    > '-D_M_UNIX'
    > '-D_SCO_C_DIALECT=1'
    > '-D_STRICT_NAMES'
    > '-D_M_I86'
    > '-D_M_I86SM'
    > '-D_M_SDATA'
    > '-D_M_STEXT'
    > '-D_M_BITFIELDS'
    > '-D_M_INTERNAT'
    > '-D_M_SYS5'
    > '-D_M_SYSV'
    > '-D_M_SYSIII'
    > '-D_M_WORDSWAP'
    > '-Di386'
    > '-Dunix'
    > '-DM_I386'
    > '-DM_UNIX'
    > '-DM_XENIX'
    > '-D_SCO_XPG_VERS=4'
    > '-D_SCO_ELF'
    > 
    
    Or even: '-D_SCO_C_DIALECT=1' as in:
    
    #if _SCO_C_DIALECT == 1 ...
    
    Can't get much more specific than that.
    
    -dg
    
    David Gould            dg@illustra.com           510.628.3783 or 510.305.9468 
    Informix Software  (No, really)         300 Lakeside Drive  Oakland, CA 94612
     - I realize now that irony has no place in business communications.
    
    
    
  5. Re: SCO vs. the monster macro

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-03-12T21:15:54Z

    > 
    > > But we don't want that if they use a good compiler under SCO.  I have
    > > asked them to run src/tools/ccsym and send the output.  Should be
    > > something unique in there.
    > 
    > On SCO, ccsym becomes /bin/cc -b elf -ii -E foo.c, which after filtering
    > gives the symbols below. If I omit "-b elf", the last line is replaced
    > by the two lines
    > '-D_M_COFF'
    > '-D_SCO_COFF'
    > 
    > How about _SCO_DS as the define when testing for SCO's native
    > compiler? (I confess ignorance as to SCO's intended use of this symbol.)
    
    I am inclined to choose:
    
    	-D_SCO_C_DIALECT=1
    
    Not to test for the value of one, but just to test if it is defined.
    
    -- 
    Bruce Momjian                          |  830 Blythe Avenue
    maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
      +  If your life is a hard drive,     |  (610) 353-9879(w)
      +  Christ can be your backup.        |  (610) 853-3000(h)