Neale, Thanks so much for your help. The problem I am facing is that some of the development code relies on return values that should be used as a size_t being declared as an unsigned int.
In other cases it is a reliance on a pointer value being 32 bits and casted to an unsigned or signed int to do pointer arithmetic. While that works fine in a 32-bit environment it causes problems in a 64-bit environment. The immediate solution is to use the correct unit types where called for. I am attempting to identify those places where this occurs and use the correct typedef for the values used. If this is too burdensome a last resort will be to recompile all the 3rd party libraries as -m31 along with the application Any other ideas? On Wed, Nov 5, 2008 at 11:05 AM, Neale Ferguson <[EMAIL PROTECTED]> wrote: > What type of compiler issues are you having? In System z both for 32 and > 64-bit size_t is typedef'd as _SIZE_TYPE_ which is unsigned long. On 32 bit > this is a 32-bit field, on 64-bit a 64-bit field. > > > On 11/5/08 11:11 AM, "Paul Meier" <[EMAIL PROTECTED]> wrote: > >> They did use the switch; and it forces all of the 3rd party libraries >> to be recompiled that way as well, so either they stay with 64 bit for >> now and try to bull through the issues or redo everything as -m31 >> (including 3rd Party stuff). > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
