Randy McMurchy wrote:
> Bruce Dubbs wrote these words on 12/15/12 22:41 CST:
>> Randy McMurchy wrote:
>>> Bruce Dubbs wrote these words on 12/15/12 22:29 CST:
The glibc folks left it out for a couple of versions and then put it
back after a lot of complaints. LFS 7.1 had the problem of l
Bruce Dubbs wrote these words on 12/15/12 22:41 CST:
> Randy McMurchy wrote:
>> Bruce Dubbs wrote these words on 12/15/12 22:29 CST:
>>> The glibc folks left it out for a couple of versions and then put it
>>> back after a lot of complaints. LFS 7.1 had the problem of leaving it out.
>> Which mean
Randy McMurchy wrote:
> Bruce Dubbs wrote these words on 12/15/12 22:29 CST:
>> The glibc folks left it out for a couple of versions and then put it
>> back after a lot of complaints. LFS 7.1 had the problem of leaving it out.
>
> Which means the text in the BLFS book should be modified ever so sl
Bruce Dubbs wrote these words on 12/15/12 22:29 CST:
> The glibc folks left it out for a couple of versions and then put it
> back after a lot of complaints. LFS 7.1 had the problem of leaving it out.
Which means the text in the BLFS book should be modified ever so slightly.
--
Randy
rmlscsi:
Randy McMurchy wrote:
> Hi all,
>
> I am a bit confused with the language in the libtirpc instructions.
> Paraphrasing,
> it says that /usr/include/rpc/rpc.h should not be installed by default if the
> version of Glibc is >=2.14, but I just installed current LFS-Development that
> includes Glibc-2
Hi all,
I am a bit confused with the language in the libtirpc instructions.
Paraphrasing,
it says that /usr/include/rpc/rpc.h should not be installed by default if the
version of Glibc is >=2.14, but I just installed current LFS-Development that
includes Glibc-2.16 and that header file *is* insta
DJ Lucas wrote:
> On 12/04/2011 04:25 PM, Bruce Dubbs wrote:
>> DJ Lucas wrote:
>>> On 12/03/2011 06:09 PM, Ken Moffat wrote:
>>>
I had noticed functions up to des_crypt.c were removed in debian,
and was attempting to merge their changes with yours by hand.
>>> Actually, removal of des_cr
On 12/04/2011 04:25 PM, Bruce Dubbs wrote:
>>
>> What 'reversal of the GLibc changes in LFS' are you referring to?
>>
>> -- Bruce
Oops...no, I meant upstream's changes, not LFS's changes (well actually
the LFS changes too as that patch puts the headers back, but it also
allows us to link to
On 12/04/2011 04:25 PM, Bruce Dubbs wrote:
> DJ Lucas wrote:
>> On 12/03/2011 06:09 PM, Ken Moffat wrote:
>>
>>> I had noticed functions up to des_crypt.c were removed in debian,
>>> and was attempting to merge their changes with yours by hand.
>> Actually, removal of des_crypt.c is all that is req
DJ Lucas wrote:
> On 12/03/2011 06:09 PM, Ken Moffat wrote:
>
>> I had noticed functions up to des_crypt.c were removed in debian,
>> and was attempting to merge their changes with yours by hand.
>
> Actually, removal of des_crypt.c is all that is required if we avoid
> upstream's ridiculous pol
On 12/03/2011 06:09 PM, Ken Moffat wrote:
> I had noticed functions up to des_crypt.c were removed in debian,
> and was attempting to merge their changes with yours by hand.
Actually, removal of des_crypt.c is all that is required if we avoid
upstream's ridiculous policy of "break stuff to light
On Sat, Dec 03, 2011 at 01:14:51PM -0600, Bruce Dubbs wrote:
> Ken Moffat wrote:
> > On Sat, Dec 03, 2011 at 12:16:19PM -0600, DJ Lucas wrote:
> >> I don't particularly care about NIS myself, but libtirpc is still broken
> >> without your NIS patch, even after re-exporting the glibc
> >> symbols.
Ken Moffat wrote:
> On Sat, Dec 03, 2011 at 12:16:19PM -0600, DJ Lucas wrote:
>> I don't particularly care about NIS myself, but libtirpc is still broken
>> without your NIS patch, even after re-exporting the glibc
>> symbols...specifically _des_crypt_call is still undefined.
>>
> Does the attac
On Sat, Dec 03, 2011 at 12:16:19PM -0600, DJ Lucas wrote:
> I don't particularly care about NIS myself, but libtirpc is still broken
> without your NIS patch, even after re-exporting the glibc
> symbols...specifically _des_crypt_call is still undefined.
>
Does the attached patch help in this ca
DJ Lucas wrote:
> I don't particularly care about NIS myself, but libtirpc is still broken
> without your NIS patch, even after re-exporting the glibc
> symbols...specifically _des_crypt_call is still undefined.
Yes, that's why the patch is required.
-- Bruce
--
http://linuxfromscratch.org
On 12/03/2011 11:31 AM, Bruce Dubbs wrote:
> DJ Lucas wrote:
>
>> What a disaster! Even RedHat hasn't got this far yet. There is more we
>> need to do to GLibc than install the headers. I'm suggesting that we
>> follow suit, as the rest of the distros have, and re-export the symbols
>> in LFS and c
DJ Lucas wrote:
> What a disaster! Even RedHat hasn't got this far yet. There is more we
> need to do to GLibc than install the headers. I'm suggesting that we
> follow suit, as the rest of the distros have, and re-export the symbols
> in LFS and continue to install the headers until a *complet
On 12/03/2011 11:19 AM, Bruce Dubbs wrote:
> DJ Lucas wrote:
>> What is the purpose of the libtirpc patch? It builds fine without it on
>> development LFS. I notice that the rpc-headers tarball does not contain
>> all of the rpcsvc/ headers, is this the reason for the patch? From a
>> casual glance
DJ Lucas wrote:
> What is the purpose of the libtirpc patch? It builds fine without it on
> development LFS. I notice that the rpc-headers tarball does not contain
> all of the rpcsvc/ headers, is this the reason for the patch? From a
> casual glance, it doesn't appear so. I don't see anything i
On 12/03/2011 09:39 AM, DJ Lucas wrote:
> This question still stands. I was not able to find anything readily
> available.
>
> -- DJ Lucas
What a disaster! Even RedHat hasn't got this far yet. There is more we
need to do to GLibc than install the headers. I'm suggesting that we
follow suit, as th
On 12/03/2011 08:40 AM, DJ Lucas wrote:
> On 12/03/2011 08:05 AM, DJ Lucas wrote:
>> What is the purpose of the libtirpc patch? It builds fine without it on
>> development LFS. I notice that the rpc-headers tarball does not contain
>> all of the rpcsvc/ headers, is this the reason for the patch? Fr
On 12/03/2011 08:05 AM, DJ Lucas wrote:
> What is the purpose of the libtirpc patch? It builds fine without it on
> development LFS. I notice that the rpc-headers tarball does not contain
> all of the rpcsvc/ headers, is this the reason for the patch? From a
> casual glance, it doesn't appear so. I
What is the purpose of the libtirpc patch? It builds fine without it on
development LFS. I notice that the rpc-headers tarball does not contain
all of the rpcsvc/ headers, is this the reason for the patch? From a
casual glance, it doesn't appear so. I don't see anything in the three
omitted fil
23 matches
Mail list logo
