Randy McMurchy wrote:
Well, actually it is the doxywizard program which doesn't compile.
Are you saying it compiles for you, using current LFS book
instructions?
Oh, I see. Doxywizard requires Qt which I don't have installed so I wasn't aware of
the problem. Doxygen compiles fine for me like so
t
Randy McMurchy wrote:
Well, actually it is the doxywizard program which doesn't compile.
Are you saying it compiles for you, using current LFS book
instructions?
I've just tested it here and it's working for me. I'm as baffled as
I've no doubt you will be Randy! That said, I've now got a 157K p
Andrew Benton wrote these words on 05/16/05 14:45 CST:
> Matthew Burgess wrote:
>
>>Maybe it would be prudent to
>>roll back to 2.5.4a? At least that one manages to get doxygen to
>>compile successfully!
>
> Doxygen compiles fine for me. The problem compiling doxygen is introduced by
> the
>
Matthew Burgess wrote:
Maybe it would be prudent to
roll back to 2.5.4a? At least that one manages to get doxygen to
compile successfully!
Doxygen compiles fine for me. The problem compiling doxygen is introduced by the
patch LFS applies to flex-2.5.31
--
http://linuxfromscratch.org/mailman/li
I have been testing, we can safely remove flex from the LFS system if we
use FSF. There are two false dependencies listed in the book, on for kbd
and the other module init tools, they do not require flex.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org
Matthew Burgess wrote:
>Folks,
>
>I'm proposing we stop tracking/using HJL's binutils. Here's my
>reasons:
>
>1) It adds host dependencies of bison and flex
>2) Recent bugs with HJL (stripping libc.a) have been hard to diagnose
>
>and fix
>3) FSF recently released 2.16, bringing it back up to
Randy McMurchy wrote:
Bruce Dubbs wrote these words on 05/15/05 18:42 CST:
Matthew Burgess wrote:
As for flex, it looks
like the maintainers went AWOL again :(
http://sourceforge.net/projects/lex/ currently lists 30 open bugs, and
11 submitted patches yet to be applied. Maybe it would be p
Bruce Dubbs wrote these words on 05/15/05 18:42 CST:
> Matthew Burgess wrote:
>>As for flex, it looks
>>like the maintainers went AWOL again :(
>>http://sourceforge.net/projects/lex/ currently lists 30 open bugs, and
>>11 submitted patches yet to be applied. Maybe it would be prudent to
>>roll bac
Matthew Burgess wrote:
> As for flex, it looks
> like the maintainers went AWOL again :(
> http://sourceforge.net/projects/lex/ currently lists 30 open bugs, and
> 11 submitted patches yet to be applied. Maybe it would be prudent to
> roll back to 2.5.4a? At least that one manages to get doxygen
Bruce Dubbs wrote:
Does this imply that LFS will drop bison and flex?
From chapter 5, certainly.
If so, they will
need to be added to BLFS. I would hope that they would be retained in
Chapter 6 as they are a part of an overall development base.
Well, I really don't mind keeping bison around. As
Matthew Burgess wrote:
> Folks,
>
> I'm proposing we stop tracking/using HJL's binutils. Here's my reasons:
>
> 1) It adds host dependencies of bison and flex
Does this imply that LFS will drop bison and flex? If so, they will
need to be added to BLFS. I would hope that they would be retained
On Sun, 15 May 2005, Matthew Burgess wrote:
>
> So, does anyone think we should still stick with HJL binutils, and if
> so, what are the compelling reasons for doing so?
>
I will be less than surprised if the multi-architecture book has to use
HJL for some architectures, in the past HJL has alwa
Matthew Burgess wrote:
Folks,
I'm proposing we stop tracking/using HJL's binutils. Here's my reasons:
1) It adds host dependencies of bison and flex
2) Recent bugs with HJL (stripping libc.a) have been hard to diagnose
and fix
3) FSF recently released 2.16, bringing it back up to speed with
mode
Folks,
I'm proposing we stop tracking/using HJL's binutils. Here's my reasons:
1) It adds host dependencies of bison and flex
2) Recent bugs with HJL (stripping libc.a) have been hard to diagnose
and fix
3) FSF recently released 2.16, bringing it back up to speed with modern
features we were rel
14 matches
Mail list logo
