Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Simon Marchi <simon.marchi@polymtl.ca>
Cc: Tom Tromey <tom@tromey.com>, gdb-patches@sourceware.org
Subject: Re: [RFC 0/6] A different approach to startup-with-shell on macOS
Date: Sat, 29 Sep 2018 20:38:00 -0000	[thread overview]
Message-ID: <6b845215-68ae-45e4-3b39-6b01323a76cd@redhat.com> (raw)
In-Reply-To: <46289fbb7b8eaffa131a96f600dbe31f@polymtl.ca>

On 09/29/2018 08:50 PM, Simon Marchi wrote:
> On 2018-09-29 14:43, Pedro Alves wrote:
>> On 09/26/2018 12:11 PM, Tom Tromey wrote:
>>
>>> One question I have is whether it's possible to build gdb on an older
>>> version of macOS and then run it on a newer version.  If this can be
>>> done, then the #if-based approach taken in the final patch will not
>>> work.
>>
>> I'd suspect so.  What, e.g., does Homebrew do?  Do they have packages
>> built once for every Darwin version, or a single binary for several
>> Darwin versions?  I'd think the latter, but I don't really know.
>> And if indeed the latter, do they always build on the newest
>> Darwin, or perhaps the oldest?
> 
> Here's the answer I got on the homebrew IRC channel:
> 
>> homebrew generally does this (but i think it's probably more conservative than it needs to be)
>> a bottle should never be deployed to an older macos version than it was built on, anyway
> 
> "this" refers to whether the binaries always run on the same macos version as the one on which they have been built.

Great, that clears it up.

Thanks,
Pedro Alves


  reply	other threads:[~2018-09-29 20:38 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-26 11:12 Tom Tromey
2018-09-26 11:11 ` [RFC 1/6] Unify shell-finding logic Tom Tromey
2018-09-28 21:39   ` Simon Marchi
2018-09-26 11:12 ` [RFC 5/6] Do not reopen temporary files Tom Tromey
2018-09-26 14:12   ` Eli Zaretskii
2018-09-26 21:44     ` Tom Tromey
2018-09-29  3:22   ` Simon Marchi
2018-10-01  9:15     ` Tom Tromey
2018-09-26 11:12 ` [RFC 2/6] Move make_temp_filename to common/pathstuff.c Tom Tromey
2018-09-26 11:12 ` [RFC 4/6] Use mkostemp, not mkstemp Tom Tromey
2018-09-29  3:09   ` Simon Marchi
2018-09-29 12:49     ` Tom Tromey
2018-09-29 14:04       ` Simon Marchi
2018-09-26 11:20 ` [RFC 3/6] Move mkdir_recursive to common/filestuff.c Tom Tromey
2018-09-26 22:11   ` Tom Tromey
2018-09-26 23:16     ` Tom Tromey
2018-09-26 11:20 ` [RFC 6/6] Cache a copy of the user's shell on macOS Tom Tromey
2018-09-29  3:37   ` Simon Marchi
2018-10-01 19:27     ` Tom Tromey
2018-10-01 19:31       ` Simon Marchi
2018-09-28 21:21 ` [RFC 0/6] A different approach to startup-with-shell " Simon Marchi
2018-09-29 18:43 ` Pedro Alves
2018-09-29 19:50   ` Simon Marchi
2018-09-29 20:38     ` Pedro Alves [this message]
2018-10-01  9:12       ` Tom Tromey

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=6b845215-68ae-45e4-3b39-6b01323a76cd@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=simon.marchi@polymtl.ca \
    --cc=tom@tromey.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