From: "Érico Nogueira" <ericonr@disroot.org>
To: "Petr Ovtchenkov" <ptr@void-ptr.info>
Cc: <elfutils-devel@sourceware.org>
Subject: Re: [PATCH 1/1] support cross compilation
Date: Wed, 26 May 2021 12:41:51 -0300 [thread overview]
Message-ID: <CBNAI9VU5X0I.S4RV3J5LBS91@mussels> (raw)
In-Reply-To: <20210526135850.1b967be8@void-ptr.info>
On Wed May 26, 2021 at 10:58 AM -03, Petr Ovtchenkov wrote:
> On Wed, 26 May 2021 10:09:31 -0300
> Érico Nogueira <ericonr@disroot.org> wrote:
>
> > Hi! Are you sure this is necessary? In Void Linux, we cross compile
> > elfutils for arm and aarch64 without any issue, and I have built it a
> > few times for powerpc as well.
> >
>
> Hello!
>
> Yes, I am sure. I do not know about you process (check, that you really
> cross, not run via qemu or like). Build process _run_ i386_gendis to
> generate headers:
Yes, we really cross.
>
> <snip>
> if MAINTAINER_MODE
> noinst_HEADERS += memory-access.h i386_parse.h i386_data.h
>
> noinst_PROGRAMS = i386_gendis$(EXEEXT)
>
> $(srcdir)/%_dis.h: %_defs i386_gendis$(EXEEXT)
> $(AM_V_GEN)./i386_gendis$(EXEEXT) $< > $@T <================
> $(AM_V_at)mv -f $@T $@
>
> else
>
> $(srcdir)/%_dis.h:
> @echo '*** missing $@; configure with --enable-maintainer-mode'
> @false
>
> endif
> </snip>
We always use the release tarballs, which already have the %_dis.h
files. This explains why we haven't hit any issues.
>
> > > +if CROSS
> > > +i386_gendis_LINK = ${CC_FOR_BUILD} ${LDFLAGS} -o $@
> > > +
> > > +$(i386_gendis_OBJECTS): CC=${CC_FOR_BUILD}
> > > +endif
> >
> > Isn't this hardcoding an assumption that the build machine is x86?
>
> I think no. But this question is for original author:
Indeed it isn't, I hadn't looked into it properly yet.
>
> commit 3cbdd387c752999255aea91600b5cfdefbeac7d0
> Author: Ulrich Drepper <drepper@redhat.com>
> Date: Wed Jan 2 17:44:39 2008 +0000
>
> propagate from branch 'com.redhat.elfutils.disasm' (head
> d15b4eb794e81e477f9896fe82a74cb5ecf4514c) to branch
> 'com.redhat.elfutils' (head
> eaacbf01f8cc89d043ec6eca9b5e35cb5c4cde06)
>
> ;)
Anyway, couldn't you (re)use the distribution tarball generation stuff
for cross setups from git master? Otherwise this would add a dependency
on autoconf-archive for anyone generating the configure script
locally... I think a final version of this patch should document the
autoconf-archive requirement, if it's merged.
Cheers,
Érico
next prev parent reply other threads:[~2021-05-26 15:48 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20210526073239.21270-1-ptr@void-ptr.info>
2021-05-26 7:32 ` Petr Ovtchenkov
2021-05-26 13:09 ` Érico Nogueira
2021-05-26 13:58 ` Petr Ovtchenkov
2021-05-26 15:41 ` Érico Nogueira [this message]
2021-05-26 16:34 ` Petr Ovtchenkov
2022-12-21 12:26 ` Mark Wielaard
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=CBNAI9VU5X0I.S4RV3J5LBS91@mussels \
--to=ericonr@disroot.org \
--cc=elfutils-devel@sourceware.org \
--cc=ptr@void-ptr.info \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).