From: Till Kamppeter <till.kamppeter@gmail.com>
To: "Wichmann, Mats D" <mats.d.wichmann@intel.com>
Cc: Wendy Phillips <wendy.phillips@sun.com>,
lsb-discuss <lsb-discuss@freestandards.org>,
Michael Sweet <mike@easysw.com>,
printing-architecture <printing-architecture@freestandards.org>,
"Printing-Sc (E-mail)" <printing-sc@freestandards.org>
Subject: Re: [Printing-architecture] [lsb-discuss] Agreement on directory structure for printing
Date: Mon, 14 Aug 2006 19:30:40 +0200 [thread overview]
Message-ID: <44E0B340.3010206@gmail.com> (raw)
In-Reply-To: <3F62CBEE02D6404E98C65934617EB58268B93F@fmsmsx414.amr.corp.intel.com>
Or should we say that on 64-bit systems with backward compatibility to a
32-bit system there should simply be a ../lib64/.. patch corresponding
to each ../lib/.. path but we do not specify for what the ../lib64/..
path is.
In general if an absolute ../lib/.. path is given in a PPD a 64-bit
system has to use ../lib64/.. instead if needed.
Or can we do away with ../lib64/.. completely and make the driver
supplier responsible for supplying a 64-bit version of their driver
which works on the LSB-compliant 64-bit distros. 64-bit experts: Does
this work without having ../lib64/.. paths in the printer driver
directory structure?
Till
Wichmann, Mats D wrote:
>
> you're getting into tricky space here, is all I can say.
> Some 64-bit distros are 32-bit plus 64-bit runtime support,
> while others are 64-bit plus 32-bit runtime support.
> I'm not sure there's a universal answer for either
> LSB architecture, either - e.g. I think some ppc64's
> are one way, some the other.
>
next parent reply other threads:[~2006-08-14 17:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <3F62CBEE02D6404E98C65934617EB58268B93F@fmsmsx414.amr.corp.intel.com>
2006-08-14 17:30 ` Till Kamppeter [this message]
2006-08-17 17:45 [Printing-architecture] [lsb-discuss] Agreement on directory structure for printing McDonald, Ira
[not found] <1B47D24854C7BC4FA8DA28BEBB59B0BA463262@orsmsx419.amr.corp.intel.com>
2006-08-09 16:52 ` Till Kamppeter
[not found] ` <m3fyg4pmm8.fsf@gromit.moeb>
2006-08-11 1:30 ` Christopher Yeoh
2006-08-11 2:06 ` Michael Sweet
2006-08-14 17:10 ` Till Kamppeter
2006-08-17 15:56 ` Till Kamppeter
[not found] <1B47D24854C7BC4FA8DA28BEBB59B0BA4176AE@orsmsx419.amr.corp.intel.com>
2006-08-07 15:52 ` Till Kamppeter
2006-08-08 23:58 ` Wendy Phillips
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=44E0B340.3010206@gmail.com \
--to=till.kamppeter@gmail.com \
--cc=lsb-discuss@freestandards.org \
--cc=mats.d.wichmann@intel.com \
--cc=mike@easysw.com \
--cc=printing-architecture@freestandards.org \
--cc=printing-sc@freestandards.org \
--cc=wendy.phillips@sun.com \
/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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.