> On Sep 19, 2016, at 04:18, René J.V. Bertin wrote:
>
> On Monday September 19 2016 03:46:32 Jeremy Huddleston Sequoia wrote:
>
>>> TMPDIR points into /var/folders.
>>
>> Yes, and it looks like those do get cleared out on boot.
>>
>> Note, however, that this particular case relates to the ca
On Monday September 19 2016 03:46:32 Jeremy Huddleston Sequoia wrote:
> > TMPDIR points into /var/folders.
>
> Yes, and it looks like those do get cleared out on boot.
>
> Note, however, that this particular case relates to the cache dir, not tmp
> (C, not T).
Oh, right, but there are icon cac
> On Sep 19, 2016, at 03:31, René J.V. Bertin wrote:
>
> On Monday September 19 2016 03:02:38 Jeremy Sequoia wrote:
>
>> /var/tmp definitely isn't cleared though.
>
> TMPDIR points into /var/folders.
Yes, and it looks like those do get cleared out on boot.
Note, however, that this particular
On Monday September 19 2016 03:02:38 Jeremy Sequoia wrote:
> /var/tmp definitely isn't cleared though.
TMPDIR points into /var/folders.
Here's an example entry from macports's icon cache:
%> sudo afsctool -vvv
/var/folders/11/_bf842l54ngf42g66hkzslmwgp/C/com.apple.IconServices/FFB06CC518D1
Sent from my iPhone...
> On Sep 19, 2016, at 02:52, René J.V. Bertin wrote:
>
> On Monday September 19 2016 02:08:12 Jeremy Huddleston Sequoia wrote:
>
>>> The icon cache sits in the user's $TMPDIR, and AFAIK that directory is
>>> emptied at boot.
>>
>> No. /tmp is emptied at boot, not /va
On Monday September 19 2016 02:08:12 Jeremy Huddleston Sequoia wrote:
>> The icon cache sits in the user's $TMPDIR, and AFAIK that directory is
>> emptied at boot.
>
>No. /tmp is emptied at boot, not /var/tmp and not /var/folders.
Did that change after 10.9? I keep a Finder window open on $TMPD
> On Sep 19, 2016, at 00:34, René J.V. Bertin wrote:
>
> On Sunday September 18 2016 19:23:01 Jeremy Huddleston Sequoia wrote:
>
Yes, of course it's possible. Don't. There's nothing special about the
UID in this case that has anything to do with what you're seeing.
>>>
>>> So what
On Sunday September 18 2016 19:23:01 Jeremy Huddleston Sequoia wrote:
>>> Yes, of course it's possible. Don't. There's nothing special about the
>>> UID in this case that has anything to do with what you're seeing.
>>
>> So what does make the difference?
>
>What is "the difference" that you wa
> On Sep 18, 2016, at 18:10, René J.V. Bertin wrote:
>
> On Sunday September 18 2016 17:24:55 Jeremy Huddleston Sequoia wrote:
>
>> That all looks as expected for someone on OS X 10.9. launchd2 in 10.10+ did
>> away with per-user launchd. All domains are managed by the same process.
>
> Sti
On Sunday September 18 2016 17:24:55 Jeremy Huddleston Sequoia wrote:
> That all looks as expected for someone on OS X 10.9. launchd2 in 10.10+ did
> away with per-user launchd. All domains are managed by the same process.
Still, why would a background user without even an interactive shell be
On Sun, Sep 18, 2016 at 8:41 PM, Brandon Allbery
wrote:
> Some port somewhere likely builds the icon cache while building or
> "installing" (destrooting) since it "knows" that it would only be built by
> the person intending to use it and that nobody uses packaging on OS X. :/
...or maybe some
On Sun, Sep 18, 2016 at 8:24 PM, Jeremy Huddleston Sequoia <
jerem...@apple.com> wrote:
> > Anyway, I don't see any valid reason why the macports user would have a
> fullblown icon cache. In my case each cache directory eats up about 900Mb.
> Some may find that insignificant; I still consider it a
> On Sep 18, 2016, at 04:25, René J.V. Bertin wrote:
>
> Hi,
>
> This isn't actually about codesigning but something that may have come up
> because of my testing in that domain.
>
> I got a low disk space warning (for an unrelated reason) and hunting down the
> space eater I noticed this:
>
Hi,
This isn't actually about codesigning but something that may have come up
because of my testing in that domain.
I got a low disk space warning (for an unrelated reason) and hunting down the
space eater I noticed this:
{{{
%> id macports
uid=502(macports) gid=503(macports)
groups=503(macpo
On 2016-09-16 10:18, Jeremy Huddleston Sequoia wrote:
> Yeah, this contradicts what I'm seeing as expected. Given that
> you've signed /opt/local/bin/ggdb with an entitlement, it should be
> CS_RESTRICT which should imply CS_HARD. The lack of a code signature
> would trigger !CS_VALID which would
> On Sep 10, 2016, at 17:56, Jeremy Sequoia wrote:
>
> On Sep 10, 2016, at 16:51, Rainer Müller wrote:
>
>> I got gdb to work now on Sierra now. In fact I did not even have to sign
>> any of the libraries it links to.
>>
>>
>> $ otool -L /opt/local/bin/ggdb |awk 'NR>1 {print $1}' \
>>|gr
> On Sep 13, 2016, at 2:06 AM, René J.V. Bertin wrote:
>
> On Tuesday September 13 2016 01:39:41 Jeremy Huddleston Sequoia wrote:
>
>> That's just the nature of things.
>
> Yeah, life sucks and all that ...
>
>> Do you have 3rd party menu extras? IIRC, you're on 10.9, and 3rd party menu
>>
On Tuesday September 13 2016 01:39:41 Jeremy Huddleston Sequoia wrote:
> That's just the nature of things.
Yeah, life sucks and all that ...
>Do you have 3rd party menu extras? IIRC, you're on 10.9, and 3rd party menu
>extras run in SystemUIServer. I frequently got SystemUIServer crashes than
> On Sep 13, 2016, at 00:14, René J.V. Bertin wrote:
>
> On Monday September 12 2016 21:51:55 Jeremy Sequoia wrote:
>
> I can confirm that there *is* feedback on radars, though I do have to admit
> that in my case it is usually one of 3 forms:
> - works as intended
> - please check if the issu
On Monday September 12 2016 21:51:55 Jeremy Sequoia wrote:
I can confirm that there *is* feedback on radars, though I do have to admit
that in my case it is usually one of 3 forms:
- works as intended
- please check if the issue still exists in the latest release (typically
months later)
- pleas
Sent from my iPhone...
> On Sep 12, 2016, at 21:44, Brandon Allbery wrote:
>
>
> On Tue, Sep 13, 2016 at 12:24 AM, Jeremy Sequoia wrote:
>>> I just noticed this. Received wisdom "out here" is that ``nobody is
>>> listening and nobody ever responds, so don't bother filing radars.''
>>
>> Th
On Tue, Sep 13, 2016 at 12:24 AM, Jeremy Sequoia wrote:
> I just noticed this. Received wisdom "out here" is that ``nobody is
> listening and nobody ever responds, so don't bother filing radars.''
>
>
> That is very very very false.
>
That may be, but I got paraphrases of that response from a nu
Sent from my iPhone...
> On Sep 12, 2016, at 20:57, Brandon Allbery wrote:
>
>> On Sat, Sep 10, 2016 at 12:14 PM, Jeremy Huddleston Sequoia
>> wrote:
>> Please file radars and point me to them, so I can make sure they get routed
>> to the right place (likely as dupes, but dupes are very use
On Sat, Sep 10, 2016 at 12:14 PM, Jeremy Huddleston Sequoia <
jerem...@apple.com> wrote:
> Please file radars and point me to them, so I can make sure they get
> routed to the right place (likely as dupes, but dupes are very useful
> "votes" for bugs).
I just noticed this. Received wisdom "out h
Can you please file a radar and toss me the number. This might be somehow
falling through the cracks with the new logging changes and didn't get noticed
yet. Hopefully we can get it fixed in an update soon if there isn't a
workaround.
Sent from my iPhone...
> On Sep 11, 2016, at 05:07, Raine
On 2016-09-11 02:56, Jeremy Sequoia wrote:
>> By the way, as I did lots of trial and error, is there a way to get
>> debug output (from taskgated?) to see why task_for_pid() was denied?
>
> Is it not being logged? You should see it in the system log
> (Console.app, log collect, etc).
That is whe
On Sunday September 11 2016 00:24:17 Jeremy Huddleston Sequoia wrote:
>Well, you can certainly upgrade the storage after purchase if you want (cf
>https://eshop.macsales.com/shop/ssd/owc/macbook-pro-retina-display/2013-2014-2015)
Sure ... and that's not even 10x more expensive than a 1TB HDD, an
On Sunday September 11 2016 00:24:17 Jeremy Huddleston Sequoia wrote:
>The secure thing to do is not escalate until we need to, prompt, do our thing,
>then throw away the privs when done. The problem with that is that we'd ask
>for credentials 2-3 times during the install and only when we need
> On Sep 10, 2016, at 09:44, René J.V. Bertin wrote:
>
> On Saturday September 10 2016 08:45:38 Jeremy Huddleston Sequoia wrote:
>
>> Yes, for most cases we would probably not need root access at activation
>> time, but for those cases you just listed, we would. We could do a pass
>> over th
Sent from my iPhone...
> On Sep 10, 2016, at 16:51, Rainer Müller wrote:
>
> On 2016-09-10 17:52, Jeremy Huddleston Sequoia wrote:
>>> On OS X 10.10 Yosemite, signing only the ggdb binary was certainly
>>> enough. I cannot reproduce this on macOS 10.12 Sierra, so the
>>> requirements might ha
On 2016-09-10 17:52, Jeremy Huddleston Sequoia wrote:
>> On OS X 10.10 Yosemite, signing only the ggdb binary was certainly
>> enough. I cannot reproduce this on macOS 10.12 Sierra, so the
>> requirements might have changed.
>
> 10.10 predates SIP and related hardening around ptrace(). That
> ve
> On Sep 10, 2016, at 09:38, Clemens Lang wrote:
>
> Hi,
>
> On Sat, Sep 10, 2016 at 09:14:16AM -0700, Jeremy Huddleston Sequoia wrote:
>> No, the DYLD_INSERT_LIBRARIES approach is the right one here.
>> Interested users would need to disable SIP.
>
> "Interested users" would be everybody who
On Saturday September 10 2016 18:38:36 Clemens Lang wrote:
> I don't see why the kernel, dyld, or whoever strips the flags could not
> just behave like running a copy of the binary at hand when it sees a
> DYLD variable, i.e. do the workaround we're doing manually at the
> moment.
Then what would
On Saturday September 10 2016 08:45:38 Jeremy Huddleston Sequoia wrote:
> Yes, for most cases we would probably not need root access at activation
> time, but for those cases you just listed, we would. We could do a pass over
> the bom to determine if root access is needed or not. The UI for h
Hi,
On Sat, Sep 10, 2016 at 09:14:16AM -0700, Jeremy Huddleston Sequoia wrote:
> No, the DYLD_INSERT_LIBRARIES approach is the right one here.
> Interested users would need to disable SIP.
"Interested users" would be everybody who uses MacPorts. I'd vote
against telling all our users to disable S
> On Sep 10, 2016, at 05:22, Clemens Lang wrote:
>
> Hi,
>
> On Fri, Sep 09, 2016 at 01:59:50PM -0700, Jeremy Huddleston Sequoia wrote:
>>> As an aside, I'd be in favour of setting up MacPorts such that
>>> ${prefix} is owned by a ${macports_operator} who's got admin rights
>>> (= myself) and r
> On Sep 10, 2016, at 05:09, Rainer Müller wrote:
>
> On 2016-09-09 22:59, Jeremy Huddleston Sequoia wrote:
>>
>>> On Sep 9, 2016, at 04:38, René J.V. Bertin wrote:
>>>
>>> On Friday September 09 2016 12:10:05 Rainer Müller wrote:
>>>
>>>
> different than your case either. Either way,
s, boot args, etc.
>> There >are also many types of restrictions that have different effects.
>
> Hah, TMI :)
>
>> Because of the CS_HARD restriction, all libraries that are linked against
>> require a valid code signature.
>
> Out of curiosity, if an IDE
On Saturday September 10 2016 15:56:54 Clemens Lang wrote:
> cat and rm deal with files, consequently trace mode needs its code to be
> injected into them (as would fakeroot). Not copying them would mean
> their unmodified copies run without the "sandbox" enabled, since
> DYLD_INSERT_LIBRARIES wou
Hi,
On Sat, Sep 10, 2016 at 03:45:25PM +0200, René J.V. Bertin wrote:
> But I see quite a few items on there that are unlikely to call other
> applications. If this is only about preserving DYLD_LIBRARY_PRELOAD,
> why do you need to treat utilities like cat or rm?
cat and rm deal with files, cons
On Saturday September 10 2016 15:15:54 Clemens Lang wrote:
Hi,
>There are no other solutions that I'm aware of on OS X. We discussed
Sorry, I meant for Apple to develop something like fakeroot from the ground up.
>FYI, I'm including a list of the files that are currently affected on my
>system
Hi,
On Sat, Sep 10, 2016 at 02:42:36PM +0200, René J.V. Bertin wrote:
> >Except that fakeroot uses library preloading, a technique that's more
> >or less dead on modern OS X thanks to Apple's changes related to SIP:
> >DYLD_INSERT_LIBRARIES is stripped for all binaries with the SIP bit
> >set.
>
On Saturday September 10 2016 14:22:16 Clemens Lang wrote:
Hi,
>Except that fakeroot uses library preloading, a technique that's more or
>less dead on modern OS X thanks to Apple's changes related to SIP:
>DYLD_INSERT_LIBRARIES is stripped for all binaries with the SIP bit set.
Fakeroot uses lib
Hi,
On Fri, Sep 09, 2016 at 01:59:50PM -0700, Jeremy Huddleston Sequoia wrote:
> > As an aside, I'd be in favour of setting up MacPorts such that
> > ${prefix} is owned by a ${macports_operator} who's got admin rights
> > (= myself) and reserve use of actual root privilege to those few
> > ports t
On 2016-09-09 22:59, Jeremy Huddleston Sequoia wrote:
>
>> On Sep 9, 2016, at 04:38, René J.V. Bertin wrote:
>>
>> On Friday September 09 2016 12:10:05 Rainer Müller wrote:
>>
>>
different than your case either. Either way, the debugger and all
its dependencies need to be signed by a v
On 2016-09-10 00:23, Jeremy Sequoia wrote:
>>> YES! We should not be needing to do such things as root. That is
>>> 100% true, and I am in full support of moving away from that and only
>>> using root for activate. We should be able to use fakeroot
>>> (https://wiki.debian.org/FakeRoot) for dest
y default but can be configured through SIP flags, boot args, etc. There
>>are also many types of restrictions that have different effects.
Hah, TMI :)
>Because of the CS_HARD restriction, all libraries that are linked against
>require a valid code signature.
Out of curiosity, i
Sent from my iPhone...
On Sep 9, 2016, at 14:46, Lawrence Velázquez wrote:
>> On Sep 9, 2016, at 4:59 PM, Jeremy Huddleston Sequoia
>> wrote:
>>
>>> On Sep 9, 2016, at 04:38, René J.V. Bertin wrote:
>>>
>>> As an aside, I'd be in favour of setting up MacPorts such that ${prefix} is
>>> o
> On Sep 9, 2016, at 4:59 PM, Jeremy Huddleston Sequoia
> wrote:
>
>> On Sep 9, 2016, at 04:38, René J.V. Bertin wrote:
>>
>> As an aside, I'd be in favour of setting up MacPorts such that ${prefix} is
>> owned by a ${macports_operator} who's got admin rights (= myself) and
>> reserve use of
hat it only links against Apple-provided
executables, so that solves that dependency.
> And lldb requires only the debugserver executable to be signed.
Again, because debugserver uses entitlements, all its dependencies need to be
signed as well.
$ otool -L /opt/local/libexec/llvm-devel/b
es that
have to be built in the right order.
You probably saw my thread about standalone building of lldb. In short: it
almost works. Of course I can only tell if it has any benefits over my current
approach once I've gotten it to work ;)
> If that is needed, it should be addressed
e control... well, that sounds like an antipattern to me.
The point remains that we may want to push this functionality out as soon as
it's ready to be tested in the wild, at least as far as selective signing of
specific applications is concerned. Otherwise a port like lldb will have to
> On Sep 9, 2016, at 10:28 AM, René J.V. Bertin wrote:
>
>> On Friday September 09 2016 09:27:31 Lawrence Velázquez wrote:
>>
>> If our release process is too cumbersome and infrequent, we should change
>> that. I don't see reason to divide base's functionality more than it already
>> is.
>
>
On Friday September 09 2016 09:27:31 Lawrence Velázquez wrote:
>> I know there's been talk about making at least parts of "base" updateable as
>> a port; this could be an easy alternative.
>
>If our release process is too cumbersome and infrequent, we should change
>that. I don't see reason to d
> On Sep 9, 2016, at 6:00 AM, Rainer Müller wrote:
>
>> On 2016-09-09 03:38, Jeremy Sequoia wrote:
>> You are describing a system to automatically create and automatically
>> trust a code signing certificate that contains a private key in a file
>> on disk that is not encrypted with a passphrase
> On Sep 9, 2016, at 7:38 AM, René J.V. Bertin wrote:
>
> I do a lot of development on projects for which I also maintain ports; in
> fact, development that's tightly coupled to the fact the code is available
> via a port. Doing all that work "as myself" only to transfer it to the port
> after
> On Sep 9, 2016, at 4:17 AM, René J.V. Bertin wrote:
>
> As a side-thought: it shouldn't be particularly difficult to implement a
> "base" feature which defines a set of PortGroups to be included by default by
> every port, if such a thing doesn't already exist.
As Josh has said previously, t
On Friday September 09 2016 14:25:53 Rainer Müller wrote:
>I think you misunderstand this sentence. codesign will search in this
>keychain for the certificate itself, but the keychain will not be used
>to find other certificates in the certificate chain (all intermediates
>up to a root CA). With a
On 2016-09-09 13:38, René J.V. Bertin wrote:
>> At least on OS X 10.10 Yosemite, I can use any path to a keychain with
>> `codesign --keychain`. This keychain does not have to be listed in
>> `security list-keychains`.
>
> Does `man codesign` still mention the search list requirement in the
> do
it is enough to sign /opt/local/bin/ggdb with a trusted certificate to
> get it working.
And lldb requires only the debugserver executable to be signed.
> Did this change with El Capitan or Sierra?
I'm guessing that would somehow be evident from the lldb-3.9 CMake files and
build ins
ave the impression we are talking about different things here. I
only want to add code-signing to the binaries that require it to work,
such as gdb and lldb.
I see no reason to and no benefits in adding a (ad-hoc) signature to
every binary MacPorts creates.
Rainer
__
On 2016-09-09 11:26, Jeremy Huddleston Sequoia wrote:
> Yes. The fact that we aren't doing that for the binary packages that
> we ship is quite embarrassing. We should solve this problem more
> generally such that we can ship properly signed binaries for every
> port. Users installing the binary
On 2016-09-09 03:38, Jeremy Sequoia wrote:
> You are describing a system to automatically create and automatically
> trust a code signing certificate that contains a private key in a file
> on disk that is not encrypted with a passphrase and only depends on file
> system ACLs to protect it.
>
> Th
One more thought: if indeed we're going to try to codesign everything at some
point, in the post-destroot, we'll probably want to ignore errors during that
particular step, i.e. catch the codesign return code and simply raise a warning
instead of bailing out. Ports that *require* signing (and on
unpredictable things?
Can you elaborate here? What do you mean by "a different key"? Adhoc signing
does not use a key. What do you expect might break or be unpredictable?
> In my book that would be a clear argument *against* signing everything, and
> for signing only those thi
ge their configuration and then what? Rebuild everything if they've
been building from source, because everything from before that magic moment
will have been signed with a different key that *might* break unpredictable
things?
In my book that would be a clear argument *against* signi
icate creation.
>>
>> Don't. This should be a manual process. The user should create a keychain
>> and specify the path to the keychain in macports.conf. If that's not set,
>> we should just adhoc sign.
>
> Adhoc code-signing does not solve the problem at
e should not hide this
>> detail from users. It needs to be very explicit.
>
> At the moment it is very explicit. We have no automation at all and you
> need to do all of the code-signing yourself or gdb/lldb will not work as
> intended.
>
> The alternative way,
n
> and specify the path to the keychain in macports.conf. If that's not set, we
> should just adhoc sign.
Adhoc code-signing does not solve the problem at hand with gdb/lldb as
that requires a trusted certificate in keychain as far as I understand it.
For what use case would ad-hoc
have no automation at all and you
need to do all of the code-signing yourself or gdb/lldb will not work as
intended.
The alternative way, recommended in the notes of the gdb port, requires
disabling SIP to edit /System/Library/com.apple.taskgated.plist, which I
would consider even worse for
ructions for setting up a signing key it isn't very
> explicit at all what's going on for someone who (honestly?) doesn't really
> care. It's just tedious. I think that a good compromise would be if an
> implementation of a codesigning procedure prints the
On Thursday September 08 2016 13:09:33 Jeremy Huddleston Sequoia wrote:
>> codesign.files ${prefix}/bin/binary1 developer \
>> ${prefix}/bin/binary2 firewall
>> codesign.identifier org.macports.${name}
>
>
>I don't like this approach.
>
>We should solve this type of probl
> On Sep 5, 2016, at 03:49, Rainer Müller wrote:
>
> On 2016-09-05 00:57, René J.V. Bertin wrote:
>> In a first draft the command accepted a list of binaries to sign, and read
>> the identify from a configuration file. I suppose that corresponds to what
>> you mean with a declarative syntax?
>
> On Sep 2, 2016, at 05:19, Rainer Müller wrote:
>
> On 2016-08-31 23:25, Lawrence Velázquez wrote:
>>> On Aug 31, 2016, at 4:57 PM, René J.V. Bertin wrote:
>>>
>>> I noticed that Apple don't ship an lldb-mi executable (at least they don't
>
> I'm tempted to say that as long as gdb cannot be a true alternative to
> lldb there's little point in maintaining the port if in addition it
> requires users to do all kinds of unhealthy things. It's not like it's
> particularly difficult to build gdb (for the port
teed to use the same data for everyone, making builds and
installs more reproducible
> > So, why would you force an expiration date on users? Say they install
> > lldb-3.x and stay at that version for whatever reason. That port isn't
> > going to change anymore at some poi
plications", whatever that means.
>
> So, why would you force an expiration date on users? Say they install
> lldb-3.x and stay at that version for whatever reason. That port isn't going
> to change anymore at some point, so why force people to go through the hassle
> even
On 2016-09-05 13:29, René J.V. Bertin wrote:
> Reminds me: I'm not really comfortable with the idea that PortFiles
> would be able to create and store certificates. I'd rather see a form
> where they can check for the availability of the identity, and then
> inform the user exactly what command to
eamlined as
possible, but are the steps to get lldb (or gdb) to work really too complicated
to follow for the intended audience of those ports?
>
> I am thinking of a list of files and policies such as:
>
> codesign.files ${prefix}/bin/binary1 developer \
>
the TN, OS X does not care
> about the expiration date for both verification or signing for "simple
> applications", whatever that means.
So, why would you force an expiration date on users? Say they install lldb-3.x
and stay at that version for whatever reason. That port isn&#x
On 2016-09-05 00:57, René J.V. Bertin wrote:
> In a first draft the command accepted a list of binaries to sign, and read
> the identify from a configuration file. I suppose that corresponds to what
> you mean with a declarative syntax?
> I then went to a simpler, single-binary interface because
On 2016-09-02 14:19, Rainer Müller wrote:
> For step 4), how to give user 'macports' access to the System.keychain
> without entering a password? As an alternative, how to import the
> identity (both private/public key) into a different keychain with
> unlocked access?
I found the missing informat
trust. That needs to be
> automated.
I wouldn't be completely surprised if it turns out to be impossible to
automated the whole process; Apple could well have seen to that as a protection
against unexpected certificates popping up, with unlimited trust etc. It's been
a while since I u
On 2016-09-02 14:45, René J.V. Bertin wrote:
> On Friday September 02 2016 14:19:02 Rainer Müller wrote:
>
>>> https://trac.macports.org/ticket/45251
>>
>> That would equivalent to what gdb recommends for codesigning.
>
> Yes, minus the part related to taskgated. And plus a few extra steps that
On Friday September 02 2016 14:19:02 Rainer Müller wrote:
>> https://trac.macports.org/ticket/45251
>
>That would equivalent to what gdb recommends for codesigning.
Yes, minus the part related to taskgated. And plus a few extra steps that
probably serve to add the certificate to the trust store.
On 2016-08-31 23:25, Lawrence Velázquez wrote:
>> On Aug 31, 2016, at 4:57 PM, René J.V. Bertin wrote:
>>
>> I noticed that Apple don't ship an lldb-mi executable (at least they don't
>> for OS X 10.9).
>
> Xcode 7.3 includes it (`xcrun --run lldb-mi`) b
On Wednesday August 31 2016 23:51:46 René J.V. Bertin wrote:
> The lldb build system is apparently less well prepared to set the appropriate
> Python include path; the build just failed because pyconfig.h couldn't be
> found. Or I have something I shouldn't have: a dire
#x27;t if there are other ways to get the software to work.
As to gdb, is it even possible to make it work normally? Last times I tried gdb
it was at least crippled for code written in C++.
I'm tempted to say that as long as gdb cannot be a true alternative to lldb
there's little point
(over) 2y ago, time enough for someone to
have looked into this without necessarily updating or knowing of that ticket.
The document Eric cites hasn't changed (much), and isn't that difficult to
follow (presuming the instructions to reboot aren't actually required).
I have now sca
> On Aug 31, 2016, at 5:06 PM, Brandon Allbery wrote:
>
>> On Wed, Aug 31, 2016 at 4:57 PM, René J.V. Bertin
>> wrote:
>>
>> The real problem is going to be with the code-signing. This is done
>> automagically by lldb's Xcode projects so it's not entirely clear which
>> files have to be sign
> On Aug 31, 2016, at 4:57 PM, René J.V. Bertin wrote:
>
> I noticed that Apple don't ship an lldb-mi executable (at least they don't
> for OS X 10.9).
Xcode 7.3 includes it (`xcrun --run lldb-mi`) but Xcode 4.6.3 does not. Someone
else is welcome to bisect on that.
On Wed, Aug 31, 2016 at 4:57 PM, René J.V. Bertin
wrote:
> The real problem is going to be with the code-signing. This is done
> automagically by lldb's Xcode projects so it's not entirely clear which
> files have to be signed ... nor if an "ad-hoc" signing identify ("-") will
> lead to a usable
Hi,
I noticed that Apple don't ship an lldb-mi executable (at least they don't for
OS X 10.9). Lldb-mi is used by KDevelop5's lldb debugger plugin, so I'm trying
to hack together a PoC port:lldb-3.8 .
Has anyone looked at building an lldb port before? My current appro
93 matches
Mail list logo
