On Thursday 17 April 2008 05:26, Brian Dessent wrote:
> Denys Vlasenko wrote:
>
> > Only in my case, $prefix contain neither as nor ld. gcc lives in
>
> Okay, so prepend /usr/app/binutils-2.18-x86_64-linux-uclibc/bin to PATH
> and gcc will find and use x86_64-linux-uclibc-{as,ld} without any of
>
Denys Vlasenko wrote:
> Only in my case, $prefix contain neither as nor ld. gcc lives in
Okay, so prepend /usr/app/binutils-2.18-x86_64-linux-uclibc/bin to PATH
and gcc will find and use x86_64-linux-uclibc-{as,ld} without any of
--with-{as,ld}.
> it's much better for sanity that way.
I would a
On Thursday 17 April 2008 04:04, Brian Dessent wrote:
> > What happened to the good old concept of looking up executables'
> > location in $PATH if they have no slashes on the name?
> >
> > (Oh well)^2. Recompiling with --with-as="/usr/bin/$CROSS-as"...
>
> Why do you think it's necessary to spec
On Thursday 17 April 2008 03:35, Denys Vlasenko wrote:
> On Thursday 17 April 2008 02:40, Denys Vlasenko wrote:
> > I believe I solved it with --with-sysroot...
> > Will try again and let you know.
I got over the problem of includes not being found using --with-sysroot,
and reached
"/usr/bin/x86_6
Denys Vlasenko wrote:
> (Is it necessary to do this "/../../../../" thing?)
A useful trick to make this easier for a human to read is to pipe the
output through
sed -e :a -e "s,[^/]*/\.\.\/,," -e ta
I don't guarantee that this will always result in the correct semantics
in all situations but it
On Thursday 17 April 2008 02:40, Denys Vlasenko wrote:
> I believe I solved it with --with-sysroot...
> Will try again and let you know.
So far I only discovered that --with-as="$CROSS-as" is not going to work.
Fixing configure is not enough:
23651 access("x86_64-linux-uclibc-as", X_OK) = -1 ENOE
On Thursday 17 April 2008 00:42, Daniel Jacobowitz wrote:
> On Wed, Apr 16, 2008 at 10:24:35PM +0200, Denys Vlasenko wrote:
> > It seems that 4.2.1 was testing "/usr/lib/../x86_64-linux-uclibc/include",
> > i.e. "$libdir/../x86_64-linux-uclibc/include". From the listing above
> > I see them 4.3.0 d
On Wed, Apr 16, 2008 at 10:24:35PM +0200, Denys Vlasenko wrote:
> It seems that 4.2.1 was testing "/usr/lib/../x86_64-linux-uclibc/include",
> i.e. "$libdir/../x86_64-linux-uclibc/include". From the listing above
> I see them 4.3.0 does not do that anymore - there is no
> "/../x86_64-linux-uclibc/i
On Wednesday 16 April 2008 21:59, Daniel Jacobowitz wrote:
> On Wed, Apr 16, 2008 at 09:55:09PM +0200, Denys Vlasenko wrote:
> > #include "..." search starts here:
> > #include <...> search starts here:
> > include
> > libbb
> >
> > /.share/usr/app/gcc-4.3.0-x86_64-linux-uclibc/bin/../lib/gcc/x
On Wed, Apr 16, 2008 at 09:55:09PM +0200, Denys Vlasenko wrote:
> #include "..." search starts here:
> #include <...> search starts here:
> include
> libbb
>
> /.share/usr/app/gcc-4.3.0-x86_64-linux-uclibc/bin/../lib/gcc/x86_64-linux-uclibc/4.3.0/include
>
> /.share/usr/app/gcc-4.3.0-x86_64-l
On Wednesday 16 April 2008 21:17, Daniel Jacobowitz wrote:
> On Wed, Apr 16, 2008 at 09:01:44PM +0200, Denys Vlasenko wrote:
> > As I mentined in the first mail, it's not the end of a story.
> > Next issue: can't find header files. This used to work with 4.2.1:
>
> Try -v to see where it is search
On Wed, Apr 16, 2008 at 09:01:44PM +0200, Denys Vlasenko wrote:
> As I mentined in the first mail, it's not the end of a story.
> Next issue: can't find header files. This used to work with 4.2.1:
Try -v to see where it is searching.
--
Daniel Jacobowitz
CodeSourcery
On Wednesday 16 April 2008 17:21, Denys Vlasenko wrote:
> I do it not not only for gcc but for almost everything.
>
> I discovered that a lot of packages will "remember" patchs given
> to configure and use those at runtime. I want them to use
> /ust/bin/something rather than /usr/app/bar/bin/somet
On Wed, Apr 16, 2008 at 07:02:30PM +0200, Denys Vlasenko wrote:
> The patch is below. Do you think it makes sense?
No opinion. There is room for confusion about relocation...
--
Daniel Jacobowitz
CodeSourcery
On Wednesday 16 April 2008 17:43, Daniel Jacobowitz wrote:
> On Wed, Apr 16, 2008 at 05:21:55PM +0200, Denys Vlasenko wrote:
> > Maybe gcc can use paths relative to executable's location?
> > readlink("/proc/self/exe") and all that.
> > It will make gcc installation movable without rebuilding.
>
>
On Wed, Apr 16, 2008 at 05:21:55PM +0200, Denys Vlasenko wrote:
> Maybe gcc can use paths relative to executable's location?
> readlink("/proc/self/exe") and all that.
> It will make gcc installation movable without rebuilding.
It already does. That's exactly what the code causing you a problem
i
On Wednesday 16 April 2008 16:23, Daniel Jacobowitz wrote:
> On Tue, Apr 15, 2008 at 05:34:17AM +0200, Denys Vlasenko wrote:
> > --bindir=/usr/bin \
>
> > bindir=$STATIC/bin \
>
> Why are you configuring for one set of paths which are half in $STATIC
> a
On Tue, Apr 15, 2008 at 05:34:17AM +0200, Denys Vlasenko wrote:
> --bindir=/usr/bin \
> bindir=$STATIC/bin \
Why are you configuring for one set of paths which are half in $STATIC
and half in /usr, and installing in paths which are all in $STATIC?
That'
Ok, I give up.
I killed many hours trying to build a cross-compiling
x86_64-linux-uclibc-gcc, version 4.3.0.
After many "WTF?" moments I decided to go back and try
to build a cross-compiler which I already have,
just older version: I decided to build i486 one,
not x86_64.
Because I already have
19 matches
Mail list logo
