Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] [git commit] libtool: Apply upstream patch to set correct linkage on MIPS64
Date: Fri, 14 Feb 2014 17:08:58 +0100	[thread overview]
Message-ID: <52FE3F9A.6090806@mind.be> (raw)
In-Reply-To: <20131130080744.58B489BE78@busybox.osuosl.org>

On 30/11/13 09:03, Peter Korsgaard wrote:
> commit: http://git.buildroot.net/buildroot/commit/?id=4268d3967e2d691c151d6b5629e4051deb077b9a
> branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
> 
> This libtool change ensures that ld uses the right machine emulation file,
> which will allow to fix several MIPS64 n64 link failures, such as the one
> currently visible on the libiscsi package.  Packages affected by this
> problem will have to use <pkg>_AUTORECONF = YES to benefit from this libtool
> fix, until they are fixed upstream.
> 
> Acked-by: Markos Chandras <markos.chandras@imgtec.com>
> Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
> ---
>  .../libtool/libtool-0001-mips64-n64-linking.patch  |   47 ++++++++++++++++++++
>  1 files changed, 47 insertions(+), 0 deletions(-)
> 
> diff --git a/package/libtool/libtool-0001-mips64-n64-linking.patch b/package/libtool/libtool-0001-mips64-n64-linking.patch
> new file mode 100644
> index 0000000..ef9084d
> --- /dev/null
> +++ b/package/libtool/libtool-0001-mips64-n64-linking.patch
> @@ -0,0 +1,47 @@
> +sets correct linker ABI flags on MIPS64
> +http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=5f7f7d9615bf650cf99d581a33b3e18357f79951
> +
> +Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
> +
> +diff -ru libtool-2.4.2.orig/libltdl/m4/libtool.m4 libtool-2.4.2/libltdl/m4/libtool.m4
> +--- libtool-2.4.2.orig/libltdl/m4/libtool.m4	2013-11-11 11:44:30.419396295 +0000
> ++++ libtool-2.4.2/libltdl/m4/libtool.m4	2013-11-11 11:44:07.055032308 +0000

 Hi all,

 This patch triggers a funny problem on Fedora 10; I'd like some feedback
on how to solve it.

 Due to this patch, the Makefile will try to run automake, aclocal and
autoconf, because all of these depend on the libtool.m4 file.

 On most hosts, this will result in the following (output edited for
clarity):

./libltdl/config/missing --run aclocal-1.11 -I libltdl/m4
./missing: line 52: aclocal-1.11: command not found
WARNING: `aclocal-1.11' is missing on your system.  You should only need
it if
         you modified `acinclude.m4' or `configure.ac'.  You might want
         to install the `Automake' and `Perl' packages.  Grab them from
         any GNU archive site.
./libltdl/config/missing --run automake-1.11 --gnu
/./libltdl/config/missing: line 52: automake-1.11: command not found
WARNING: `automake-1.11' is missing on your system.  You should only need
it if
         you modified `Makefile.am', `acinclude.m4' or `configure.ac'.
         You might want to install the `Automake' and `Perl' packages.
         Grab them from any GNU archive site.
./libltdl/config/missing --run autoconf
aclocal.m4:16: warning: this file was generated for autoconf 2.68.
You have another version of autoconf.  It may work, but is not guaranteed to.
If you have problems, you may need to regenerate the build system entirely.
To do so, use the procedure documented by the package, typically
`autoreconf'.
/bin/sh ./config.status --recheck
...

 I.e., aclocal and automake fail because the 1.11 version is hardcoded in
Makefile.in. autoconf complains about the old aclocal but continues to
build configure, and configure is re-run.

 This is of course not nice, but not a big deal either.


 However, Fedora 10 does have automake 1.11, and you get this:

./libltdl/config/missing --run automake-1.11 --gnu
configure.ac:130: require Automake 1.11.1, but have 1.11
make[2]: *** [Makefile.in] Error 1

 I.e., if fails because configure.ac wants automake 1.11.1.


 Normally we would solve these issues by setting LIBTOOL_AUTORECONF=YES,
since we've modified the autotools input files. However, that won't work
for host-libtool because AUTORECONF adds a dependency on host-libtool...


 But in this case, the changes to the m4 file are only relevant for the
installed libtool, not during build. So my proposal is to manually apply
this patch on the installed host/usr/share/aclocal/libtool.m4 instead of
in the patch step. That way, make will not try to run aclocal, automake
and autoconf because libtool.m4 is not newer than the generated files.


 What do you think?

 Vicente, can you confirm that this patch is only needed on the installed
libtool.m4, not during build?


 Regards,
 Arnout


[snip]

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

  reply	other threads:[~2014-02-14 16:08 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-30  8:03 [Buildroot] [git commit] libtool: Apply upstream patch to set correct linkage on MIPS64 Peter Korsgaard
2014-02-14 16:08 ` Arnout Vandecappelle [this message]
2014-02-17 11:44   ` Vicente Olivert Riera

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52FE3F9A.6090806@mind.be \
    --to=arnout@mind.be \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox