bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: No rule to make target `../opcodes/libopcodes.la', needed by `as-new


From: Jonathan Andrews
Subject: Re: No rule to make target `../opcodes/libopcodes.la', needed by `as-new'. Stop.
Date: Mon, 30 Jan 2012 11:20:48 +0000

On Mon, 2012-01-30 at 09:40 +0000, nick clifton wrote:
> Hi Jonathan,
> 
>  > make
> [...]
> > make[2]: Entering directory `/root/src/GNU/unmodified_gnu/binutils-2.22/gas'
> > make[2]: *** No rule to make target `../opcodes/libopcodes.la', needed by 
> > `as-new'.  Stop.
> 
> > Anyone any ideas ?
> 
> Does "make all-gas" work ?
> 
> How did you configure the sources before building ?
> Are the opcodes sources actually present in the source tree ?
> Did the build system attempt to built libopcodes.la ?  If so were any 
> errors reported ?
> 
> Note - you appear to be building in the source tree itself.  Whilst this 
> is supposed to work
As a point of interest in the end it did work, building out of tree made
no difference; I tried both ways.

>  it is more common to build in a separate tree.  So 
> you might like to try this:
> 
>    % mkdir -p /root/build/GNU/unodified_gnu/binutils-2.22
>    % cd /root/build/GNU/unmodified_gnu/binutils-2.22
>    % /root/src/GNU/unmodified_gnu/binutils-2.22/configure <...>
>    % make all-gas all-ld all-binutils
>    % make install-gas install-ld install-binutils
Thanks for this. I did find an example like this and give it a go. 

It took lots of hacking around and even "strace make" as well as "make
-d" to figure out all the reasons why binutils didn't build.   Mine was
a pretty painful case of upgrading an early gcc3 toolchain with 2.4
kernel to gcc 4.x and Kernel 3.x  

The development system was hand built and for reasons that are tedious
to go into it cant simply be replaced with a standard distribution.

As someone who does not need to build this kind of stuff much I
struggled...

1) The readme in the main binutils-2.22 directory is piss poor
unhelpful. 

"       ./configure
        make
To install them (by default in /usr/local/bin, /usr/local/lib, etc),
then do:
        make install"

Aha ...



2) Nice trap to trip people up here:
OnSight_PC: 10.10.10.16> ls -l README
-rw-rw-rw-    1 501      501          1719 May  3  1999 README
OnSight_PC: 10.10.10.16> cd binutils/
OnSight_PC: 10.10.10.16> ls -l README 
-rw-rw-rw-    1 501      501         10886 Jul 14  2009 README
OnSight_PC: 10.10.10.16> pwd
/root/src/GNU/unmodified_gnu/binutils-2.22/binutils


3) building gas depends on lots but checks nothing ! If you
# cd gas
# ./configure
# make

As the first action it WILL fail, configure should know this?

It did work in the end after much head scratching.  I learnt a couple of
things, one is gas has woeful checking in configure and secondly the
output from early versions of make can be very unhelpful !

It seems odd to me that if gas depends on libopcodes.la in its relative
tree could configure not check it exists ?

I would have thought a lot of people who need to update the assembler
for gcc would not need to build most of binutils. It would make sense
for gas to build in a more self contained way, or at very least crap out
with a "build <this package> first" message for its dependencies ?

Thanks,
Jon






reply via email to

[Prev in Thread] Current Thread [Next in Thread]