Allen@Grijjy

Thanks to Chris then! I wonder if we could unbundle the package during the pre-link stage and copy over the original .appex over the top of the Delphi ones after Delphi completes it's codesign step and then rebundle it before it's deployed? I imagine you already tried that though... have to give this some thought.

Thanks, I have been racking by brain about this. I wrote an article on how to do it back in 2018 for Grijjy but couldn't get any of it to work with Delphi 12 again. I tried just about everything so I appreciate the insight!

Did you ever figure anything out with this issue? I am exploring something similar and wondering if I should test an old Delphi version to see if it works.

If I use that command line, I always get '0' source lines. Here is the output for the following: -v -pause -bind:C:\Users\Allen\Desktop\Test1.exe C:\Users\Allen\Desktop\Test1.map -include:0001 ----> map2pdb - Copyright (c) 2021 Anders Melander Version 3.0.1 Constructed a new PDB GUID: {33C40D0A-BC13-43D4-A6E3-D7D23966F480} Output filename not specified. Defaulting to Test1.pdb Reading MAP file - Segments - Modules - Symbols Warning: [36728] Failed to resolve symbol to module: [0004:0000000000008260] SysInit.TlsLast Warning: [36731] Failed to resolve symbol to module: [0003:00000000FF887000] SysInit.__ImageBase - Line numbers Include filter eliminated 1,114 module(s), 60,204 symbol(s) Collected 0 modules, 0 symbols, 0 lines, 280 source files Constructing PDB file - Collecting source file names - Module streams - Strings stream - PDB Info stream - TPI stream - Symbols stream - DBI stream - IPI stream - Finalizing PDB file - 15 blocks written in 1 intervals Patching PE file - PE32+ image (64-bit) - PDB file name has been stored in debug data. - PE file has been updated. Elapsed time: 00:00:00.246 If I take the exact same map file and do the following instead, Here is the output: -v -pause -bind:C:\Users\Allen\Desktop\Test1.exe C:\Users\Allen\Desktop\Test1.map ----> map2pdb - Copyright (c) 2021 Anders Melander Version 3.0.1 Constructed a new PDB GUID: {44F58444-CC5E-4CA2-B03E-288B255CC688} Output filename not specified. Defaulting to Test1.pdb Reading MAP file - Segments - Modules - Symbols Warning: [36728] Failed to resolve symbol to module: [0004:0000000000008260] SysInit.TlsLast Warning: [36731] Failed to resolve symbol to module: [0003:00000000FF887000] SysInit.__ImageBase - Line numbers Collected 1,114 modules, 60,204 symbols, 155,944 lines, 280 source files Constructing PDB file - Collecting source file names - Module streams - Strings stream - PDB Info stream - TPI stream - Symbols stream - DBI stream - IPI stream - Finalizing PDB file ERangeError: Range check error Elapsed time: 00:00:03.714 Done - Press enter to continue Notice (2) things. First I get all the sources lines, but before I did not. Also I get a Range Check Error (at the bottom). I am really using the syntax correctly? I guess I don't understand the benefit of generating a PDB without line information? I am willing to send the .map file I am using for you to examine if there is a private means of doing so. I don't want to share it publicly. I grabbed to PE information for it. It does seem quite different from Delphi's output: Start Length Name Class 0001:0000000000401000 006CD7B8H .text CODE 0002:0000000000ACF000 000A9208H .data DATA 0003:0000000000B79000 00011F20H .bss BSS 0004:0000000000400000 00008260H .tls TLS 0005:0000000000BDE000 0004FF5CH .pdata PDATA I totally agree. If you have a QC report with Embarcadero I would be happy to vote for it and escalate it. I really would like to see if we could get to the bottom of these things because it's an important capability and I would live to share it with the wider audience. Happy to help in any way on this.

This is where I am confused (and I have read all the existing documentation). You recommend configuring a tool in Delphi with these parameters: -debug -v -pause -bind:$EXENAME $PATH($EXENAME)$NAMEONLY($EXENAME).map -include:0001 When I do this, it will parse my map file correctly, but it won't load any source lines regardless of the segments that I include. If I I change to something like this: -v -pause -bind:$EXENAME $PATH($EXENAME)$NAMEONLY($EXENAME).map -include:0001;0003;0004 It also doesn't load any source lines. I checked this within the debugger directly. It enumerates the files correctly, it just doesn't consume them into the FSourceLines collection. Is my syntax correct or am I supposed to be doing this: -debug -v -pause -bind:$EXENAME $PATH($EXENAME)$NAMEONLY($EXENAME).map -include:0001;0002;* so I am indicating both filenames and segments to include? I would be happy to assist in any way I can. I think it's a great tool and would love to do an Embarcadero Coderage MVP session on how to use some of the industry standard profilers with your utility in the future, if that's okay. I noticed other people have encountered the same issue with consuming overlapping segments. In my case I modified the code to skip the overlapping segments instead of raising an exception and stopping. For example, Delphi emitted the map file segments as: Start Length Name Class 0001:0000000000401000 006CD7B8H .text CODE 0002:0000000000ACF000 000A9208H .data DATA 0003:0000000000B79000 00011F20H .bss BSS 0004:0000000000400000 00008260H .tls TLS 0005:0000000000BDE000 0004FF5CH .pdata PDATA TDebugInfoSegment.CheckOverlap subsequently raised an exception: Project map2pdb.exe raised exception class Exception with message 'Overlapping segments: .tls [0004:0000000000400000] and .text [0001:0000000000401000]'.

Guess we are both working on this at the same time! I had the same issue yesterday, but I figured out that -include:0001 (or whatever code segments you are analyzing) doesn't actually load the source lines. I haven't debugged it fully yet, but if I switch to -include:* (using a filename wildcard instead) it works. The main thing is to make sure that the -debug output says it loaded more than 0 lines. Also, it has some issue with overlapping segments from the map files, so I had to make a source code change to work around it, but that issue may be project specific.

I am little late to this party, but stumbled across this wonderful utility, so thank you for it! At first map2pdb didn't consume my map files without throwing some exceptions, but I made a few code changes and it works wonderfully now. I was able to use it with Intel VTune which is really nice! The issues I encountered was that it complained about 'overlapping segments' between .tls and the .data segments. It also wouldn't load source lines if I use -include:0001 or -include:0001;0002;etc.. I was able to modify the sources to exclude the .tls segment and if I changed to -include:* using a wildcard then it properly loaded all the source lines from the various segments. Anyway, thanks for this!

I always love how Apple breaks our apps with each subsequent release! There are still various internal issues with Ventura causing random floating point exceptions that crash Delphi apps that have yet to be resolved by Apple.

I am also seeing the Stop (17) error messages with the latest Linux configuration for Delphi.

The Grijjy and Lumicademy team is looking for someone special to join our development team! We are based in San Diego, CA but this is a remote position. If you have experience in WebRtc or SIP coding would be a big plus. https://vl247.careerplug.com/j/0144yx3

Our latest Grijjy article on how you could build your own Geolocation and Geotargetting in Delphi for your cloud service or backend, https://blog.grijjy.com/2022/01/04/grijjys-5th-anniversary/

Seems to be caused by remnants in the project .dsk files. If you edit them or purge them, the problem appears to go away. Do a search for "Documentation.htm" in your *.dsk files.

Same issue for me with the latest release. Someone already opened a QC report for this RSP-33590.

Sorry, missed your original post on this. I don't mind your efforts here. OpenSsl is particularly tricky because quite often it is installed with the operating system and if you use dynamic library version the imports will get confused about which library you are using, since there are 2 of them that cross-reference each other. To avoid this, I try to build the static versions which are linked directly into the project using the "dependency" keyword. Also, the Mac was particularly a pain because symbolic linking will force the dynamic library to find OpenSsl elsewhere so I merged both libraries into one to avoid that. But yes, placing all the libraries into a single path with the header unit avoids a lot of frustration for static libraries.

Did some more reading here. Apple specifically says that extensions are not allowed to launch their host application unless it's a Today widget, "A Today widget (and no other app extension type) can ask the system to open its containing app by calling the openURL:completionHandler: method of the NSExtensionContext class. " https://developer.apple.com/library/archive/documentation/General/Conceptual/ExtensibilityPG/ExtensionOverview.html#//apple_ref/doc/uid/TP40014214-CH2-SW2 You may get rejected by Apple from the App Store for violating guidelines. That being said, I suspect from reading on StackOverflow that is exactly what some Share extensions are doing and they are in the App store. I attached an example ShareViewController.m that *may* work. Of course you will need to modify the urlString and replace https:// with abcd:// to launch the Url Protocol handler. ShareViewController.m