Experimental Physics and Industrial Control System
|
Putting the following define in all .c source files (after the last
#include)
#define NULL 0L
does indeed fix things.
It may fix things on your 64-bit machine, but it won't everywhere --
you're providing a long argument when the XtVaSetValues() routine is
looking for a pointer; the two may still be different sizes on other
machines.
NULL is a strange beast. On my linux-x86 machine gcc 4.0.2 defines it
as ((void *)0) whereas g++ 4.0.2 defines it as __null. The Solaris C
C++ compiler defines it to be 0 in all circumstances; the C compiler
uses 0L if we're compiling for LP64 archs, else 0.
I think that the correct solution is to accept the compiler's definition
and just use NULL. Thus if removing NULL from dbDefs.h solves this
problem then that's the right solution for now and it'll be that way
from R3.14.9 onwards.
- Andrew
--
There is considerable overlap between the intelligence of the smartest
bears and the dumbest tourists -- Yosemite National Park Ranger
- Replies:
- Re: Getting alh to run on AMD64 (linux 64-bit OS) John William Sinclair
- Re: Getting alh to run on AMD64 (linux 64-bit OS) Kay-Uwe Kasemir
- Navigate by Date:
- Prev:
Re: Getting alh to run on AMD64 (linux 64-bit OS) Andrew Johnson
- Next:
Re: Getting alh to run on AMD64 (linux 64-bit OS) John William Sinclair
- Index:
2002
2003
2004
2005
<2006>
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Getting alh to run on AMD64 (linux 64-bit OS) Andrew Johnson
- Next:
Re: Getting alh to run on AMD64 (linux 64-bit OS) John William Sinclair
- Index:
2002
2003
2004
2005
<2006>
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|
ANJ, 02 Feb 2012 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|