From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.31.162.195 with SMTP id l186mr4407466vke.18.1486860571965; Sat, 11 Feb 2017 16:49:31 -0800 (PST) X-Received: by 10.157.62.29 with SMTP id a29mr1246337otd.5.1486860571910; Sat, 11 Feb 2017 16:49:31 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!1.eu.feeder.erje.net!feeder.erje.net!2.us.feeder.erje.net!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder1.iad1.usenetexpress.com!216.166.98.84.MISMATCH!border1.nntp.dca1.giganews.com!nntp.giganews.com!q58no896640qte.0!news-out.google.com!78ni1048itm.0!nntp.google.com!e137no398390itc.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sat, 11 Feb 2017 16:49:31 -0800 (PST) In-Reply-To: <7b13c405-96c8-40c9-84a6-2c3d760c30bb@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=144.132.203.17; posting-account=wavAeAoAAAAZF_sXSZepBukuPCBO0Zqt NNTP-Posting-Host: 144.132.203.17 References: <427190d2-0fb4-465b-b1be-0a10d9b2d290@googlegroups.com> <1ce198d4-7316-436d-8867-e323a5ab1741@googlegroups.com> <7b13c405-96c8-40c9-84a6-2c3d760c30bb@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Visual Studio IDE - Integration From: alby.gamper@gmail.com Injection-Date: Sun, 12 Feb 2017 00:49:31 +0000 Content-Type: text/plain; charset=UTF-8 Xref: news.eternal-september.org comp.lang.ada:33334 Date: 2017-02-11T16:49:31-08:00 List-Id: On Wednesday, February 8, 2017 at 2:41:15 PM UTC+11, alby....@gmail.com wrote: > On Tuesday, February 7, 2017 at 7:37:18 PM UTC+11, Dmitry A. Kazakov wrote: > > On 07/02/2017 08:46, Hadrien Grasland wrote: > > > > > To clarify, GDB is actually pretty awesome as a command-line tool. > > > But no one has ever bothered - or managed - to write a good GUI frontend > > for it. > > > > In fact GPS has a pretty cool debugger's front end. It has a bit less > > comfortable debugging interface than Visual Studio's, but still all > > bells and whistles. > > > > IMO GPS is far better than latter incarnations of Visual Studio. Since > > VS 2005 it goes clearly down the slope. The only thing where Studio is > > better than GPS is debugging. [*] > > > > The problem is that it becomes usable when the project gets any larger > > and more complex. > > > > Knowing that AdaCore has awesome software designers and that other parts > > of the tool-chain are working seamless, I put blame squarely on GDB. > > > > ----------------- > > * And MS linker. GNU linker is a disaster with regard to performance. It > > takes literally an hour to link a large stand-alone relocatable library. > > > > -- > > Regards, > > Dmitry A. Kazakov > > http://www.dmitry-kazakov.de > > Dear Dmitry > > I've looked at using gcc to compile a simple hello world app in "C" and then > link using the MS linker. This does work (after a bit of tweaking. However > Ada/gnat is a bit harder due to the additional RTS/mingw dependencies and > VC 2015 runtime has dropped of support for some legacy routines (for example > __iob_func ...) > > I believe the best approach may be to built the RTS using gcc and then link > using MS linker. Once that is done, then linking normal apps against this new > RTS should be straight forward. > > Problem is I have little documentation available on how to rebuild the actual > RTS (I can compile the Ada sources, but their is a bunch of "C" files that also > need to be compiled, and subsequently linked to produce the RTS (ie libgnat.a) > > Thanks > > Alex Dear Dmitry I have managed to build a new RTS (libgnat) using the MS linker and a small test Ada application that links against this RTS using the MS Linker. The bad news is that all debug info is lost in the process. I believe the info is still in the final exe, but the relevant DWARF ".debug_xxx" sections get renamed to 8 chars by the MS linker and no longer usable/convertable ! Alex