Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail From: Chet Ramey Newsgroups: gnu.bash.bug Subject: Re: [PATCH] AIX NFS patches part1 Date: Thu, 20 Sep 2018 19:03:09 -0400 Organization: ITS, Case Western Reserve University Lines: 25 Approved: bug-bash@gnu.org Message-ID: References: <3e8bbc8a0597982c2679f158e71d07e7.squirrel@mail.pie-dabas.net> Reply-To: chet.ramey@case.edu NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Trace: usenet.stanford.edu 1537484600 11299 208.118.235.17 (20 Sep 2018 23:03:20 GMT) X-Complaints-To: action@cs.stanford.edu Cc: chet.ramey@case.edu To: gasha@pie-dabas.net, bug-bash@gnu.org Envelope-to: bug-bash@gnu.org X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:cc:subject:to:references:from :organization:message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=ZR09kKo2SXBRwqReWO2wnBIChC+5AyCrcp1rWrm+HOU=; b=Avt3BE8a32k5ySdokwF45HskEtOTJCbmL6DKnFuuFam3re309iF/AqYfeHfBAeulDT QKXVHIkp9ltxxoXIamDPbjbT7PqSjVNMzjBxzY+P/ZZy7Hda8XC7Zox1kVQvKE6yk9du rzDuWzY3hU2te4hn8Y9mXJvF+TtRgBnX8ctw3zdmGrqpG9aS+6OUXyFIXd5bRK2bjWI7 ce8NPKxvJlccLGYlhUfxo99BXeu2hzfPAt+a9MD+nKAjoSFsRaYHXsMyC78Wm5iHhHOt gDO17b9iwEedSg1XZ0XrrT00v2ZIQkpT+xc0bKvVY40dGlNUnvsZat0GMm99yXWyu63b dL/A== X-Gm-Message-State: APzg51BKmcALt9J3NE+NczdlQmVWX6sp7KHVFbSG+pN9G3ld/yOMM0TA 2n0LcJjO8siEC3iFVvjgGST4XUqdtG4RSPX8B58q/k0QSxNvEXpJWEAZo5Y4au+z09S6rww7v2I xRN+w+LPRQjk= X-Received: by 2002:a24:3a88:: with SMTP id m130-v6mr3833585itm.151.1537484591569; Thu, 20 Sep 2018 16:03:11 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZi4WyUdmvwVSvY5K2+xoowFBv7AQsEvRJf/cIu9xsdZ6JRmFVE4GHIENDYRcesPL3eYJH/GA== X-Received: by 2002:a24:3a88:: with SMTP id m130-v6mr3833570itm.151.1537484591287; Thu, 20 Sep 2018 16:03:11 -0700 (PDT) User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 In-Reply-To: <3e8bbc8a0597982c2679f158e71d07e7.squirrel@mail.pie-dabas.net> Content-Language: en-US X-Junkmail-Status: score=7/90, host=mpv2-2015.case.edu X-Junkmail-PrAS-Raw: score=7/90, refid=2.7.2:2018.9.20.215717:17:7.944, ip=, rules=__YOUTUBE_RCVD, __X_GOOGLE_DKIM_SIGNATURE, __HAS_REPLYTO, __HAS_CC_HDR, __SUBJ_REPLY, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __TO_MALFORMED_2, __TO_NO_NAME, __REFERENCES, __HAS_FROM, FROM_EDU_TLD, __HAS_MSGID, __SANE_MSGID, DATE_TZ_NA, __USER_AGENT, __MOZILLA_USER_AGENT, __MIME_VERSION, __IN_REP_TO, __CT, __CT_TEXT_PLAIN, __CTE, __REPLYTO_SAMEAS_FROM_ADDY, __REPLYTO_SAMEAS_FROM_ACC, __FROM_DOMAIN_IN_ANY_CC1, __FROM_DOMAIN_IN_ANY_CC2, __REPLYTO_SAMEAS_FROM_DOMAIN, __ANY_URI, __URI_WITH_PATH, __URI_NO_WWW, __CP_URI_IN_BODY, __SUBJ_ALPHA_NEGATE, __URI_IN_BODY, __URI_NOT_IMG, __FORWARDED_MSG, __NO_HTML_TAG_RAW, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_900_999, __MIME_TEXT_P1, __MIME_TEXT_ONLY, __URI_NS, HTML_00_01, HTML_00_10, BODY_SIZE_5000_LESS, IN_REP_TO, MSG_THREAD, __FROM_DOMAIN_IN_RCPT, MULTIPLE_REAL_RCPTS, [TRUNCATED], so=2010-03-03 19:42:08, dmn=2016-08-03-0138 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 129.22.103.227 X-BeenThere: bug-bash@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Bug reports for the GNU Bourne Again SHell List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Xref: csiph.com gnu.bash.bug:14614 On 9/20/18 6:57 PM, gasha@pie-dabas.net wrote: > > Thanks for pointing to old threads. > I was able to find root cause of this issue, somewhere in LKML. > And was forced to patch and recompile some more freeware tools, like "tar" > and "make", used in our development environment. > > Sad truth about all that - lack of consistent LARGEFILE support in GNU > header files and Makefiles/autoconfig/etc... > > There is no magic - someone has to write some code between #if and #endif :( Yes. My answer assumes you're using the `standard' AIX header files, which should #define opendir as opendir64 if _LARGE_FILES is defined. Similarly for dirent64/readdir64/closedir64. If you're using replacement GNU header files, yes, similar code will have to be in those header files. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet@case.edu http://tiswww.cwru.edu/~chet/