public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Norbert Lange <nolange79@gmail.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: "Frank Ch. Eigler" <fche@redhat.com>,
	gdb@sourceware.org, Gary Benson <gbenson@redhat.com>,
	 Sergio Durigan Junior <sergiodj@redhat.com>
Subject: Re: Automatically fetching Build ID from remote libraries and resole them locally?
Date: Mon, 6 Apr 2020 16:41:08 +0200	[thread overview]
Message-ID: <CADYdroOfFBjo7cvpxPgUD2G-3kQ8j+z_q3ZaU9b-+pf+JLFg8A@mail.gmail.com> (raw)
In-Reply-To: <CADYdroNhKDy7Qrafs-tOuo5S6_ukb0tcw2f1A2cAhWSpquhG0g@mail.gmail.com>

@Jan: You said

> > GDB 9.0 certainly does not use *Build-Ids from the 'remote'*,
>
> According to a test I have made now I agree. Maybe Gary Benson will suggest
> more.

did you talk about upstream or Fedora (with your patches) here?

I got GDB compiling with almost all Fedora patches included. Ready to test soon.

I encountered some headaches when cross-compiling, it seems you have an bug
with --with-rpm=auto (the default).
(thats the output following the lines 'if test "x$with_rpm" != "xno"; then')

+ test xauto = xyes
+ test xauto = xauto
+ LIBRPM=librpm.so
+ RPM_REQUIRE=false
+ DLOPEN_REQUIRE=false
+ LIBRPM_STRING='"librpm.so"'
+ printf '%s\n' 'configure:6650: checking specific librpm version'
+ printf %s 'checking specific librpm version... '
checking specific librpm version... + HAVE_DLOPEN_LIBRPM=false
+ save_LIBS='-ldl '
+ LIBS='-ldl  -ldl'
+ test yes = yes
+ :
+ printf '%s\n' 'configure:6656: error: in `/tmp/build/gdb/gdb'\'':'
+ printf '%s\n' 'configure: error: in `/tmp/build/gdb/gdb'\'':'
configure: error: in `/tmp/build/gdb/gdb':
+ as_fn_error 'cannot run test program while cross compiling
See `config.log'\'' for more details.' 6659 5
+ as_status='cannot run test program while cross compiling
See `config.log'\'' for more details.'
+ test cannot run test program while cross compiling See
'`config.log'\''' for more details. -eq 0
/tmp/build/source/gdb/gdb/configure: line 406: test: too many arguments
+ test ''
+ printf '%s\n' 'configure: error: 6659'
configure: error: 6659
+ as_fn_exit cannot run test program while cross compiling See
'`config.log'\''' for more details.
+ set +e
+ as_fn_set_status cannot
+ return cannot
/tmp/build/source/gdb/gdb/configure: line 295: return: cannot: numeric
argument required
+ exit cannot
/tmp/build/source/gdb/gdb/configure: line 305: exit: cannot: numeric
argument required
+ exit_status=2
+ echo

Am Mo., 6. Apr. 2020 um 14:53 Uhr schrieb Norbert Lange <nolange79@gmail.com>:
>
> Am Mo., 6. Apr. 2020 um 14:16 Uhr schrieb Jan Kratochvil
> <jan.kratochvil@redhat.com>:
> >
> > On Mon, 06 Apr 2020 14:08:55 +0200, Norbert Lange wrote:
> > > How do I read the list at https://src.fedoraproject.org/rpms/gdb/tree/master.
> > > Are all patches applied, or are the ones starting with 'gdb-6.6' only
> > > for that version?
> >
> > All of them are applied, in this order:
> >         https://src.fedoraproject.org/rpms/gdb/blob/master/f/_patch_order
> >
> > Although I would find it most easy to just use some Fedora virtual machine
> > (when you do not run Fedora natively).
>
> I doubt that, given that I tend to use gdb via IDE, and that we
> currently internally distribute dev tools over a debian repository.
> Lastly, Ill have to build a gdbserver for the target also.
>
> >
> >
> > > An a different note, I dont know if you are a GDB maintainer,
> >
> > I am no longer.
>
> Ok, then sorry if I came across disgruntled (I am disgruntled but you
> certainly arent to blame)
>
> >
> > > but the topic should be the upstream version?
> >
> > This mailing list is sure about the upstream version.  Just saying the problem
> > is solved in Fedora version so the patches could be somehow imported.
>
> Thanks, gonna try applying them locally and bugging debian maintainers
> to add them.
> Upstream might take a while, from what it seems. If you can, please
> try if you can push those patches somehow.
>
> Norbert

      reply	other threads:[~2020-04-06 14:41 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-27 14:20 Norbert Lange
2020-03-28  0:40 ` Frank Ch. Eigler
2020-03-30  8:35   ` Norbert Lange
2020-03-30  8:45     ` Jan Kratochvil
2020-03-30  9:04       ` Norbert Lange
2020-03-30  9:19         ` Jan Kratochvil
2020-03-30 18:43           ` Gary Benson
2020-04-06 11:31           ` Norbert Lange
2020-04-06 11:49             ` Jan Kratochvil
2020-04-06 12:08               ` Norbert Lange
2020-04-06 12:16                 ` Jan Kratochvil
2020-04-06 12:53                   ` Norbert Lange
2020-04-06 14:41                     ` Norbert Lange [this message]

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=CADYdroOfFBjo7cvpxPgUD2G-3kQ8j+z_q3ZaU9b-+pf+JLFg8A@mail.gmail.com \
    --to=nolange79@gmail.com \
    --cc=fche@redhat.com \
    --cc=gbenson@redhat.com \
    --cc=gdb@sourceware.org \
    --cc=jan.kratochvil@redhat.com \
    --cc=sergiodj@redhat.com \
    /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).