On 2016-08-31 23:25, Lawrence Velázquez wrote: >> On Aug 31, 2016, at 4:57 PM, René J.V. Bertin <[email protected]> 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. > >> Has anyone looked at building an lldb port before? > >> 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 debugger. > > You opened a ticket about this a while ago. One of Eric's comments hints at > what a pain it might be to get it working with code signing. > > https://trac.macports.org/ticket/45251
That would equivalent to what gdb recommends for codesigning. https://sourceware.org/gdb/wiki/BuildingOnDarwin#Giving_gdb_permission_to_control_other_processes In my opinion, the actual implementation of codesigning should be in base: 1) Create a self-signed certificate/identity for code-signing 2) Import certificate/identity into keychain 3) Add it to trust store (`security add-trusted-cert ...`) 4) In activate phase, if requested in Portfile, codesign the binary Unsolved problems: For step 1), how to to automate certificate creation. We cannot click that in Keychain Assistent. That means finding a way to do it programmatically with other tools. As far as I see, this is just a standard x509 certificate which could be done with openssl, but which extensions need to be enabled? 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? Rainer _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
