From: SourceForge.net <no...@so...> - 2010-02-19 22:45:24
|
Bugs item #2703968, was opened at 2009-03-22 11:18 Message generated for change (Comment added) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2703968&group_id=119701 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Interpreter >Group: v4.0 >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Mike Protts (mikeprotts) Assigned to: Rick McGuire (bigrixx) Summary: NetBSD Alpha build macro expansion ARGUMENT_TYPE___int64-t Initial Comment: This is a problem on FreeBSD Alpha (64 bit), it does not occur on Linux Intel 32 bit. RexxMethod2 (and others) macro expansion fails, e.g. for: RexxMethod2(int64_t, stream_lines, CSELF, streamPtr, OPTIONAL_CSTRING, option) the int64_t expands to ARGUMENT_TYPE___int64_t, and therefore generates an error. As a quick circumvent I changed to using the OPTIONAL value which worked - e.g.: RexxMethod2(OPTIONAL_int64_t, stream_lines, CSELF, streamPtr, OPTIONAL_CSTRING, option) Typical errors: ===== ./interpreter/streamLibrary/StreamNative.cpp:1729: error: 'ARGUMENT_TYPE___int64_t' does not name a type ./interpreter/streamLibrary/StreamNative.cpp: In function '__uint16_t* stream_lines(RexxMethodContext*, ValueDescriptor*)': ./interpreter/streamLibrary/StreamNative.cpp:1729: error: 'union ValueDescriptor::<anonymous>' has no member named 'value___int64_t' ./interpreter/streamLibrary/StreamNative.cpp:1729: error: 'stream_lines_impl' was not declared in this scope ./interpreter/streamLibrary/StreamNative.cpp: At global scope: ./interpreter/streamLibrary/StreamNative.cpp:1729: error: 'ARGUMENT_TYPE___int64_t' does not name a type *** Error code 1 ===== Failing freebsd alpha gcc version ========= $ gcc --version gcc (GCC) 4.1.2 20061021 prerelease (NetBSD nb3 20061125) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Does work with Linux gcc: =========== # gcc --version gcc (GCC) 4.2.2 Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Mike ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2010-02-19 14:45 Message: The fix for this item was in the 4.0.0 release. ---------------------------------------------------------------------- Comment By: Rick McGuire (bigrixx) Date: 2009-03-29 08:48 Message: Committed revision 4327. Thanks Mike. ---------------------------------------------------------------------- Comment By: Mike Protts (mikeprotts) Date: 2009-03-29 08:34 Message: Thanks for your help. I've uploaded the svn diff. There were three underscores originally. >From /usr/include/sys/types.h: #ifndef int64_t typedef __int64_t int64_t; #define int64_t __int64_t #endif #ifndef uint64_t typedef __uint64_t uint64_t; #define uint64_t __uint64_t #endif I've set up a NetBSD intel VM so I can check there as well. I'll also try Solaris (sparc) later as I can test there quite easily. Thanks Mike ---------------------------------------------------------------------- Comment By: Rick McGuire (bigrixx) Date: 2009-03-29 07:27 Message: Mike, I'm not sure I understand your patch. Why are you using 3 underscores for the type rather than 2? Or did the the characters just run together in the original report? Also, could you generate the patch using svn diff? That will make it easier to apply the change. ---------------------------------------------------------------------- Comment By: Rick McGuire (bigrixx) Date: 2009-03-29 07:22 Message: My suspicion is the include files for that platform #define int64_t et al to _int64_t. This gets substituted in the initial macro expansion, which messes everything else up. A serious pain, but I think we can work around the problem. ---------------------------------------------------------------------- Comment By: Mike Protts (mikeprotts) Date: 2009-03-29 07:18 Message: There were a couple of others, and I also had a problem with value___uintptr_t; in ./extensions/rexxutil/platform/unix/rexxutil.cpp. The attached patch gets these built. It's a bit strange how the expansion is not consistent, it would be nice to understand the difference. Cheers Mike ---------------------------------------------------------------------- Comment By: Rick McGuire (bigrixx) Date: 2009-03-28 15:02 Message: I might have a fix for this (already checked in). Hopefully this is confined to the int64_t and uint64_t types. ---------------------------------------------------------------------- Comment By: Mike Protts (mikeprotts) Date: 2009-03-28 13:51 Message: I've generated the preprocessor output as a file. There are a few examples where expansion has resulted in ___ instead of _, In each case I think it's where an int64_t or uint64_t type is used. ---------------------------------------------------------------------- Comment By: Mike Protts (mikeprotts) Date: 2009-03-22 12:18 Message: (updated as it's NetBSD, not FreeBSD) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2703968&group_id=119701 |