[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: [blfs-support] pcre-8.30 Fernando de Oliveira Mon Feb 13 08:00:38 2012

Ken, thank you very much for the replies.

Em 12-02-2012 19:16, Ken Moffat escreveu:
> On Sun, Feb 12, 2012 at 01:41:09PM -0800, Fernando de Oliveira wrote:
>> grep. That error message is from pcre-8.30 build log. It is called from the 
>> build script, after installation and ldconfig:
>>       BUILD_DIR_SIZE=`du -sck \
>>       $TMPDIR/$BUILDDIR | grep total | cut -d"t" -f1`
>> I believe you recognize. It is from your suggestion to me, some months ago. 
>> And it is good, not only for the intended purpose, but it warned me, with 
>> that complaint. I should not have tried to reboot without fixing pcre before.
>> Also it is a shame that I should have also paid more attention to the 
>> remarks on BLFS pcre-8.30 page *Command Explanations*
>> "--libdir=/lib: This option makes it install its libraries into /lib. If you 
>> reinstall Grep after installing PCRE, Grep will get linked against PCRE and 
>> this may cause problems during the boot process if /usr is a separate mount 
>> point. If you have /usr/lib on the same partition as /lib you can omit this 
>> option"
>> as one further warning to solve the issue before rebooting.
>  Thinking about this a bit more, why was the old rebuilt grep not
> using libpcre.so, rather than libpcre.so.0 ?  I've never rebuilt
> grep after pcre is installed, so I don't know.

Sorry. I do not understand this question. That is why I kept thinking and did 
not reply yesterday.

But reading Andy's post I received today, perhaps the answer is that paco 
removed the library.

And replying to your post also received today, I agree in part that:

>  ... yet another example of why package managers are *evil* 

In part, because paco really facilitates my view of installed packages. 
However, I will modify the scrips to not uninstall previous versions of 
packages. In this respect, I many times used *make uninstall*, before using 
paco, what is really evil is uninstall, not paco. Perhaps, somewhere in the 
book, there could be a recommendation of not uninstall, in the lines of Markku 

> When upgrading a working system, you should always
> keep the old version of a library installed, until all programs that
> depend on it are recompiled against the new one.

It may be I am wrong, but differently from you (citation following), I think 
there is a problem.

> I don't think there is a problem with the book.

>>> I always recommend booting to level 3 and using startx and not ?dm for 
>>> exactly this type of problem.
>> I used to do that for months (or even years?) until one day I read about 
>> security issues if not using a dm, and installed slim. I have spent about an 
>> hour now, trying to find it if it was on Arch or Gentoo, without success. As 
>> I do not have much security knowledge, I believed it.
>> Also, I notice that most linux distros use one.
>> Please, I would like advice on that, as life would be much easier without 
>> dm's.
>  My memory of slim is that I eventually hated it :)  Perhaps because
> the text was too small, but I forget.  It would be interesting to see
> that 'security' report.  I used to use gdm for convenience (before it
> changed and stopped me seeing the results of the shutdown scripts -
> unpleasant when my development created an error in them), but the
> reason distros use dm's is that "users expect to boot to a graphical
> desktop".  AFAIK, there are no security reasons to prefer a
> graphical login - although, arguably, in an office with multiple
> users a tty login where xorg is not running will not load a
> screensaver when a machine is unattended.

What I disliked more about slim was the lack of poweroff/reboot (if I recall 
correctly). Thus, I replaced it by lxdm, which is ok, but had to do some 
gymnastics to get it working (PAM, Xsession, to name two).

Now I am in the route to removing lxdm, as I will discuss in the reply to Bruce.

Thanks very much for the attention, again. Much appreciated.

FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page