From: Jason Price <jprice@cyberbuzz.gatech.edu>
To: Bart Schaefer <schaefer@candle.brasslantern.com>
Cc: Zsh hackers list <zsh-workers@sunsite.dk>,
Jason Price <jprice@CyberBuzz.GaTech.edu>
Subject: Re: Bugs on SourceForge
Date: Mon, 14 May 2001 14:09:48 -0400 [thread overview]
Message-ID: <20010514140948.A16312@oobleck.gatech.edu> (raw)
In-Reply-To: <1010514162145.ZM10006@candle.brasslantern.com>; from schaefer@candle.brasslantern.com on Mon, May 14, 2001 at 04:21:44PM +0000
>} I'll have to try this out when I get a moment. But given the headers are
>} screwy for Solaris 8 (see below), I rather suspect I won't be able to
>} reproduce it. Certainly works OK on 8 with zsh compiled under 6.
> Note that it was Solaris 6 where Jason is having `rlimit64' problems, so
> the fact that you're able to compile on Solaris 6 but he is not may be
> indicative of ... something ...
Probably largefile support if I had to make a guess... See below.
>}> On to the datasize tests.
>} These worked, right? Else I'm missing something.
> They worked. I closed out the bug report on SourceForge.
Quite correct... I wasn't very clear.
>>> In file included from /usr/include/sys/wait.h:24, from configure:2638:
>>> /usr/include/sys/resource.h:148: warning: `struct rlimit64' declared
>>> inside parameter list
>> This looks like another header problem, but this time it's more than
>> just configure complaining. struct rlimit64 should be defined:
>> [...]
>> 5.8 system. The complaints are presumbably from the lines
>> extern int setrlimit64(int, const struct rlimit64 *);
>> extern int getrlimit64(int, struct rlimit64 *);
> Your header certainly makes it appear that it shouldn't be possible to
> compile the above two lines without also having rlimit64 defined. I've
> already sent mail to Jason asking what his resource.h looks like (and
> he's Cc'd on this message).
Line 148 is:
extern int setrlimit(int, const struct rlimit *);
Here is the relevant portion of resource.h on solaris 2.6:
/*************************************************************************/
#if defined(__STDC__)
extern int setrlimit(int, const struct rlimit *); /* ** line 148 ** */
extern int getrlimit(int, struct rlimit *);
/* transitional large file interfaces */
#if defined(_LARGEFILE64_SOURCE) && !((_FILE_OFFSET_BITS == 64) && \
!defined(__PRAGMA_REDEFINE_EXTNAME))
extern int setrlimit64(int, const struct rlimit64 *);
extern int getrlimit64(int, struct rlimit64 *);
#endif /* _LARGEFILE64_SOURCE... */
extern int getpriority(int, id_t);
extern int setpriority(int, id_t, int);
extern int getrusage(int, struct rusage *);
#else /* __STDC__ */
extern int getrlimit();
extern int setrlimit();
/* transitional large file interfaces */
#if defined(_LARGEFILE64_SOURCE) && !((_FILE_OFFSET_BITS == 64) && \
!defined(__PRAGMA_REDEFINE_EXTNAME))
extern int setrlimit64();
extern int getrlimit64();
#endif /* _LARGEFILE64_SOURCE... */
extern int getpriority();
extern int setpriority();
extern int getrusage();
#endif /* __STDC__ */
/*************************************************************************/
And here's what it looks like in Solaris 8:
/*************************************************************************/
#if defined(__STDC__)
extern int setrlimit(int, const struct rlimit *);
extern int getrlimit(int, struct rlimit *);
/* transitional large file interfaces */
#if defined(_LARGEFILE64_SOURCE) && !((_FILE_OFFSET_BITS == 64) && \
!defined(__PRAGMA_REDEFINE_EXTNAME))
extern int setrlimit64(int, const struct rlimit64 *);
extern int getrlimit64(int, struct rlimit64 *);
#endif /* _LARGEFILE64_SOURCE... */
extern int getpriority(int, id_t);
extern int setpriority(int, id_t, int);
extern int getrusage(int, struct rusage *);
#else /* __STDC__ */
extern int getrlimit();
extern int setrlimit();
/* transitional large file interfaces */
#if defined(_LARGEFILE64_SOURCE) && !((_FILE_OFFSET_BITS == 64) && \
!defined(__PRAGMA_REDEFINE_EXTNAME))
extern int setrlimit64();
extern int getrlimit64();
#endif /* _LARGEFILE64_SOURCE... */
extern int getpriority();
extern int setpriority();
extern int getrusage();
#endif /* __STDC__ */
/*************************************************************************/
(I can get solaris 7's version too)
If I had to shoot into the dark about what's causing this, it'd be the
migration path Sun took from 32 bit to 64 bit. 2.6 was the first,
partially 64 bit OS sun made (IIRC). It only did a 64 bit file system,
leaving the rest of the kernel relativly unharmed. Solaris 7 was fully 64
bit.
If I can help with things, let me know.
Jason
--
"Friendship is the bridge between lonely and loved, between a glance and a
gaze. It stretches from the fog into sunshine, hopelessness into faith,
between despair and joy. It crosses the chasm from hell and to heaven, from
God to man, and from you to me." --Unknown Jason Price jprice@gatech.edu
next prev parent reply other threads:[~2001-05-14 18:10 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-05-14 14:55 (Fwd) " Bart Schaefer
2001-05-14 15:23 ` Peter Stephenson
2001-05-14 16:21 ` Bart Schaefer
2001-05-14 18:09 ` Jason Price [this message]
[not found] ` <20010516130705.A25104@oobleck.gatech.edu>
[not found] ` <1010516194927.ZM15038@candle.brasslantern.com>
2001-05-16 21:24 ` Jason Price
-- strict thread matches above, loose matches on Subject: below --
2001-03-29 9:51 Sven Wischnowsky
2001-03-29 6:53 Bart Schaefer
2001-03-29 10:19 ` Peter Stephenson
2001-03-29 11:27 ` Peter Stephenson
2001-03-29 14:36 ` Peter Stephenson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20010514140948.A16312@oobleck.gatech.edu \
--to=jprice@cyberbuzz.gatech.edu \
--cc=schaefer@candle.brasslantern.com \
--cc=zsh-workers@sunsite.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).