Re: LFS vs procfs on SunOS

["Filip Hajny" <filip%joyent.com@localhost>]

On 5. 3. 2012, at 19:46, David Holland wrote:

> On Mon, Mar 05, 2012 at 11:32:48AM +0100, Filip Hajny wrote:
>> there are some packages which fail on SunOS (unless ABI=64),
>> because they try to have both large file support and
>> procfs. However, the procfs headers on SunOS are in a deliberate
>> conflict with LFS. Sometimes the procfs requirement can be dropped
>> using a patch or CONFIGURE_ENV, or _FILE_OFFSET_BITS can be
>> undefined, but I'm unsure about the validity of either.
>> 
>> Examples are print/cups (discovers and tries to use ucred.h, which
>> pulls in procfs) and net/nagios-plugins (the swap plugin looks for
>> procfs).
>> 
>> Should the package just hard fail in such case (e.g. if ABI not set
>> to 64 on SunOS), or should one try to work around at risk of
>> limited functionality? What'd be the best practice under pkgsrc?
> 
> Can you explain *why* it's deliberately broken? Is it because their
> kernel procfs code is bollocks and needs to be kept in a padded cell,
> or is it some kind of library/headers management issue? Or is it just
> Sun being deliberately difficult to discourage use of 32-bit code
> and/or large files?

This is the only relevant discussion that I could find (now that
Jive is dead):

"[...] the kernel has no way of knowing that a 32-bit process was
compiled with large file support, only that it's a 32-bit process
vs a 64-bit process. So to do what you want to do, there's no good
way to use the more painless large file compilation environment,
and you end up doing what they other poster said and using
the transitional interfaces of the *64() form."

http://www.mail-archive.com/opensolaris-code%opensolaris.org@localhost/msg08229.html

http://www.mail-archive.com/opensolaris-code%opensolaris.org@localhost/msg05873.html

-F