f.l. wrote:
to this topic, the problem is that what i used is different version
than lfs-book has,
you dont want to try with new version, why you dont like others do this?
The issue isn't that you're using different versions from the book, the
problem is that you're deviating from the book and
Chris Staub a écrit :
> [EMAIL PROTECTED] wrote:
>>>
>>> certainly can change instructions and versions, assuming that you
>>> actually know what you're doing. However, if you do something like
>>> change the location of /tools, then you clearly *do not* know what you
>>> are doing. It's that simpl
[EMAIL PROTECTED] wrote:
certainly can change instructions and versions, assuming that you
actually know what you're doing. However, if you do something like
change the location of /tools, then you clearly *do not* know what you
are doing. It's that simple.
--
i dont think /tools is that import
You *can* do your own stuff (after all, the motto of LFS is "Your
distro, your rules). However, there is a difference between customizing
to your liking, and making stuff different for absolutely no reason. You
sure there are reason to do so, one is that if noone will try this,
then no one will
[EMAIL PROTECTED] wrote:
Chris,
thanks for your reply, really.
but i think the problem is not as described by you.
as you know, instruction on the lfs-book are some sort of road map,
as long as you know what you are doing, you can do your own stuff, surely.
to this topic, the problem is that
Chris,
thanks for your reply, really.
but i think the problem is not as described by you.
as you know, instruction on the lfs-book are some sort of road map,
as long as you know what you are doing, you can do your own stuff, surely.
to this topic, the problem is that what i used is different v
[EMAIL PROTECTED] wrote:
seems fixinc.sh have been run, and thus caused this problem,
maybe i have to modify the Makefile.in
No, the problem is you are ignoring the book's instructions and doing
your own thing. Did you even bother reading even one word I wrote? If
you aren't going to listen to
f.l. a écrit :
> On 7/3/06, kriss <[EMAIL PROTECTED]> wrote:
>> can you tell how you make gcc-4.1.1 pass1 ?
>> cause in it the doc say that bootstrap don't work anymore
>> --
>
> like this,
>
> ../gcc-4.1.1/configure --prefix=/tools \
>--libexecdir=/tools/lib --with-local-prefix=/tools \
>
On 7/3/06, kriss <[EMAIL PROTECTED]> wrote:
can you tell how you make gcc-4.1.1 pass1 ?
cause in it the doc say that bootstrap don't work anymore
--
like this,
../gcc-4.1.1/configure --prefix=/tools \
--libexecdir=/tools/lib --with-local-prefix=/tools \
--disable-nls --enable-shared --en
seems fixinc.sh have been run, and thus caused this problem,
maybe i have to modify the Makefile.in
On 7/3/06, Chris Staub <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
> On 7/3/06, Chris Staub <[EMAIL PROTECTED]> wrote:
>>
>> You can't do that. You must use /tools. It doesn't matter what
kriss wrote:
can you tell how you make gcc-4.1.1 pass1 ?
cause in it the doc say that bootstrap don't work anymore
I've run make bootstrap on GCC 4.1.1 many times. Where exactly does it
say this?
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/
can you tell how you make gcc-4.1.1 pass1 ?
cause in it the doc say that bootstrap don't work anymore
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
[EMAIL PROTECTED] wrote:
On 7/3/06, Chris Staub <[EMAIL PROTECTED]> wrote:
You can't do that. You must use /tools. It doesn't matter what $LFS is
and what /tools points to, but it MUST be /tools.
--
i think its ok to use /tool , as long as its point to /lfs/tool
and even
/_anything_ will wor
On 7/3/06, Chris Staub <[EMAIL PROTECTED]> wrote:
You can't do that. You must use /tools. It doesn't matter what $LFS is
and what /tools points to, but it MUST be /tools.
--
i think its ok to use /tool , as long as its point to /lfs/tool
and even
/_anything_ will work, if it links to /lfs/_th
[EMAIL PROTECTED] wrote:
On 6/30/06, steve crosby <[EMAIL PROTECTED]> wrote:
On 6/30/06, f. l. <[EMAIL PROTECTED]> wrote:
> +#define DYNAMIC_LINKER "/tool/lib/ld-linux.so.2"
>
assuming it's not a typo, this should be "tools", not "tool", correct?
no , its not a typo, i use a different prefi
I recall someone else had the same problem doing the exact same thing
you are (except binutils-2.17) a couple months ago. Like Chris said,
though, most of the people here aren't using the newer versions until
we can get this damn release done. How did you do the toolchain
adjustment? Why are y
On 6/30/06, steve crosby <[EMAIL PROTECTED]> wrote:
On 6/30/06, f. l. <[EMAIL PROTECTED]> wrote:
> +#define DYNAMIC_LINKER "/tool/lib/ld-linux.so.2"
>
assuming it's not a typo, this should be "tools", not "tool", correct?
no , its not a typo, i use a different prefix
/tool => /lfs/tool
--
h
[EMAIL PROTECTED] wrote:
thanks .
i did have problem with expect-5.44.1, which require tkConfig.sh to be
present,
and after install tk it seemed ok, expect was not used much up to now,
so there's little chance for me to find it,
nor did i noticed the claim on expect site.
i do want to try with
On 6/29/06, f. l. <[EMAIL PROTECTED]> wrote:
well, short answer is yes.
On 6/30/06, Chris Staub <[EMAIL PROTECTED]> wrote:
Oh, yeah. Please don't top-post and try to trim down the replies to
just what's relevant. Thanks.
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ
On 6/29/06, f. l. <[EMAIL PROTECTED]> wrote:
i created a new partition, make symbolic link to /tool,
clean all enviroment variables except HOME, TERM and so on,
binutils-2.17
gcc-4.1.1 pass 1
Linux-Libc-Headers-2.6.12.0
Glibc-2.4
Tcl-8.4.13
Tk-8.4.13
Expect-5.44.1
DejaGNU-1.4.4
On 6/30/06, f. l. <[EMAIL PROTECTED]> wrote:
+#define DYNAMIC_LINKER "/tool/lib/ld-linux.so.2"
assuming it's not a typo, this should be "tools", not "tool", correct?
--
-- -
Steve Crosby
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.
still no luck,
i think gcc/config/sh/linux.h is not required for an i386 , isn't it?
my patch to gcc-4.1.1:(between ` and ')
`
diff -ru gcc-4.1.1/gcc/config/i386/linux.h
../build/gcc-4.1.1/gcc/config/i386/linux.h
--- gcc-4.1.1/gcc/config/i386/linux.h 2005-08-11 01:53:01.0
f.l. wrote:
hi,
i'm using gcc-4.1.1 to build the tool chain,
while it blocked at pass 2,
and gcc reported no limits.h was found.
my patch to gcc source:
in gcc/configure:
change STMP_FIXINC=stmp-fixinc
to STMP_FIXINC=
in gcc/cppdefaults.h:
added
#undef STANDARD_INCLUDE_DIR
#define STANDAR
thanks .
i did have problem with expect-5.44.1, which require tkConfig.sh to be present,
and after install tk it seemed ok, expect was not used much up to now,
so there's little chance for me to find it,
nor did i noticed the claim on expect site.
i do want to try with newer version, most of them
[EMAIL PROTECTED] wrote:
well, short answer is yes.
i created a new partition, make symbolic link to /tool,
clean all enviroment variables except HOME, TERM and so on,
binutils-2.17
gcc-4.1.1 pass 1
Linux-Libc-Headers-2.6.12.0
Glibc-2.4
Tcl-8.4.13
Tk-8.4.13
Expect-5.44.1
DejaGNU-1.4.4
well, short answer is yes.
i created a new partition, make symbolic link to /tool,
clean all enviroment variables except HOME, TERM and so on,
binutils-2.17
gcc-4.1.1 pass 1
Linux-Libc-Headers-2.6.12.0
Glibc-2.4
Tcl-8.4.13
Tk-8.4.13
Expect-5.44.1
DejaGNU-1.4.4
these all went fine, and f
[EMAIL PROTECTED] wrote:
hi,
i'm using gcc-4.1.1 to build the tool chain,
while it blocked at pass 2,
and gcc reported no limits.h was found.
my patch to gcc source:
in gcc/configure:
change STMP_FIXINC=stmp-fixinc
to STMP_FIXINC=
in gcc/cppdefaults.h:
added
#undef STANDARD_INCLUDE_DIR
#d
27 matches
Mail list logo
