On Apr 16, 2013, at 3:49 PM, Pierre Labastie wrote:
With LFS-SVN-20130403, I got the same errors with luit and xmodmap.
Actually, they are warnings treated as errors. I added --disable-
selective-werror
to the configure switches, and could build them. Maybe we could use
that
until upstream
On 04/16/2013 11:40 AM, Ken Moffat wrote:
> On Tue, Apr 16, 2013 at 04:33:41PM +0100, Ken Moffat wrote:
>> On Tue, Apr 16, 2013 at 09:57:21AM -0500, Bruce Dubbs wrote:
>>> For linux, the .la files are just not needed. They will be used if
>>> present, but the only problem I've ever had was when so
Le 02/04/2013 19:50, NP a écrit :
> Hi,
>
> Tried to build X on a brand new LFS SVN-20130329 base
> (Linux-3.8.4/GCC-4.8.0) with x86_64 architecture.
>
> Got build errors with 2 packages in the Xorg applications :
> - luit-1.1.1
> - xmodmap-0.7.0
>
> In both cases the reported error was "implic
On Tuesday 16 April 2013 19:57:24 Bruce Dubbs wrote:
> Whether to use ipv4 or ipv6 really depends on the ISP. Generally an
> office only needs one address and then uses NAT (network address
> translation) internally. NAT multiplexes a single address into many.
> Any office can use private IP a
> - Original Message -
> From: lf...@cruziero.com
> Sent: 04/02/13 10:41 PM
> To: BLFS Support List
> Subject: Re: [blfs-support] Autofs problem on LFS7.2
>
> > Date: Tue, 02 Apr 2013 18:19:44 -0400
> > From: "Cliff McDiarmid"
> > To: "akhiezer" ,
> > "BLFS Support List"
> >
> > Subject:
lux-integ wrote:
> Greetings
>
> I caught the linux bug in 1999. and I have been a fan of LFS/CLFS/BLFS for at
> least a decade. From my early days of linux I have been hearing about ipv6.
> But it appears not many people are using it (STILL). AND there are business
> interests who have inv
On Tue, Apr 16, 2013 at 01:33:56PM -0300, Fernando wrote:
>
> Just to justify previous message, I am curious if it is a notebook,
> desktop (both could be fast machines), phone (could not be, it would not
> be a "faster machine"), because I have been wondering if linux could be
> installed in an o
On Tue, Apr 16, 2013 at 01:02:25PM -0300, Fernando wrote:
> Em 16-04-2013 12:33, Ken Moffat escreveu:
>
> ...
>
> > The first build was on my phonon, which is supposedly a faster
> > machine (SBU times now suggest otherwise, at least with ondemand
> > cpufreq).
>
> I have no idea what "phonon"
Greetings
I caught the linux bug in 1999. and I have been a fan of LFS/CLFS/BLFS for at
least a decade. From my early days of linux I have been hearing about ipv6.
But it appears not many people are using it (STILL). AND there are business
interests who have invested in the moribund-ip
Le 16/04/2013 13:47, LM a écrit :
>
> Ken Moffat wrote:
> > LFS itself took about 3 hours.
>
> That is very impressive. Was experimenting with a build of just gcc
> over the weekend and that took 4 hours by itself. Didn't try the -j
> option. Some of the systems I've tried it on just locked up
Em 16-04-2013 13:02, Fernando escreveu:
> Em 16-04-2013 12:33, Ken Moffat escreveu:
>
> ...
>
>> The first build was on my phonon, which is supposedly a faster
>> machine (SBU times now suggest otherwise, at least with ondemand
>> cpufreq).
>
> I have no idea what "phonon" means, here. Know abo
Ken Moffat wrote:
> On Tue, Apr 16, 2013 at 04:33:41PM +0100, Ken Moffat wrote:
>> On Tue, Apr 16, 2013 at 09:57:21AM -0500, Bruce Dubbs wrote:
>>>
>>> For linux, the .la files are just not needed. They will be used if
>>> present, but the only problem I've ever had was when some .la files are
>>>
Em 16-04-2013 12:33, Ken Moffat escreveu:
...
> The first build was on my phonon, which is supposedly a faster
> machine (SBU times now suggest otherwise, at least with ondemand
> cpufreq).
I have no idea what "phonon" means, here. Know about it in linux and in
physics.
--
[]s,
Fernando
--
On Tue, Apr 16, 2013 at 04:40:57PM +0100, Ken Moffat wrote:
Retry, that didn't make sense -
> Also, it turns out I'm only doing that for libtool archives in /usr
> (I based the process on what I do for static libs). It turns out
> I've still got *many* in directories below /usr/lib.
>
I'm on
Fernando wrote:
> Em 16-04-2013 11:57, Bruce Dubbs escreveu:
>
> ...
>
>> For linux, the .la files are just not needed. They will be used if
>> present, but the only problem I've ever had was when some .la files are
>> present and dependent files are deleted. The solution has always been
>> rm /u
On Tue, Apr 16, 2013 at 04:33:41PM +0100, Ken Moffat wrote:
> On Tue, Apr 16, 2013 at 09:57:21AM -0500, Bruce Dubbs wrote:
> >
> > For linux, the .la files are just not needed. They will be used if
> > present, but the only problem I've ever had was when some .la files are
> > present and depen
On Tue, Apr 16, 2013 at 09:57:21AM -0500, Bruce Dubbs wrote:
>
> For linux, the .la files are just not needed. They will be used if
> present, but the only problem I've ever had was when some .la files are
> present and dependent files are deleted. The solution has always been
> rm /usr/lib/*
Em 16-04-2013 11:57, Bruce Dubbs escreveu:
...
> For linux, the .la files are just not needed. They will be used if
> present, but the only problem I've ever had was when some .la files are
> present and dependent files are deleted. The solution has always been
> rm /usr/lib/*.la
I have nev
On Tue, Apr 16, 2013 at 09:13:42PM +0800, Iru Cai wrote:
>
> I'm glad to see a mupdf user in the BLFS Support List. I've tried to
> install mupdf in my LFS system before, but I failed due to dependencies. So
> I hope it can be written in BLFS book.
What was your problem ? I've just built a DEST
LM wrote:
> I also found out that Debian and some other distributions eliminate the .la
> files before installing and I've been making a habit of doing that. I'm
> trying to avoid hard-coded locations of files whenever possible and the .la
> files have a lot of them. Am trying to keep the hard-c
2013/4/16 LM
> On Tue, Apr 16, 2013 at 2:00 AM, William Tracy wrote:
>
>>
>> This is new and interesting to me. How does mupdf stack up against xpdf?
>
>
> I really haven't done any timing tests. However, I've read that mupdf was
> designed by some of the ghostscript developers to be more effici
On Tue, Apr 16, 2013 at 1:47 PM, LM wrote:
> Is there an equivalent for passing include paths (CFLAGS) and libraries
> (LIBS, LDFLAGS)
> or do those environment variable settings work with cmake too?
There are CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH for include and
library paths.
Also, CMAKE_C_
On Tue, Apr 16, 2013 at 2:00 AM, William Tracy wrote:
>
> This is new and interesting to me. How does mupdf stack up against xpdf?
I really haven't done any timing tests. However, I've read that mupdf was
designed by some of the ghostscript developers to be more efficient than
poppler (poppler
Bruce Dubbs wrote:
>Passing parameters with -Dsome_long_name is a little cumbersome
Is there an equivalent for passing include paths (CFLAGS) and libraries
(LIBS, LDFLAGS)
or do those environment variable settings work with cmake too?
>Also, I bet you'd find autotools equally loathsome if you did
24 matches
Mail list logo
