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,LOTS_OF_MONEY autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,4c6ea3271d0f95a2 X-Google-Attributes: gid103376,public From: "Tom Hargraves" Subject: Re: Elaboration of Ada object archive. Possible/Alternatives? Date: 2000/11/21 Message-ID: <3a1a54fd@rsl2.rslnet.net> X-Deja-AN: 696115396 References: X-Original-NNTP-Posting-Host: van-port100.imag.net X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Trace: 21 Nov 2000 02:57:01 -0800, van-port100.imag.net Newsgroups: comp.lang.ada Date: 2000-11-21T00:00:00+00:00 List-Id: Hi Gordon, The Ada LRM has the following "Implementation Advice", so maybe you could grep the symbol files for "adainit" and have some fun while you're waiting for the compiler vendor to reply. If this is a "common problem", then perhaps the Ada LRM has not been specific enough in this area? Regards, Tom H. B.1 Interfacing Pragmas 39 If an implementation supports pragma Export to a given language, then it should also allow the main subprogram to be written in that language. It should support some mechanism for invoking the elaboration of the Ada library units included in the system, and for invoking the finalization of the environment task. On typical systems, the recommended mechanism is to provide two subprograms whose link names are "adainit" and "adafinal". Adainit should contain the elaboration code for library units. Adafinal should contain the finalization code. These subprograms should have no effect the second and subsequent time they are called. 40 Automatic elaboration of preelaborated packages should be provided when pragma Export is supported. "Jeff Creem" wrote in message news:t1fokco5opii74@corp.supernews.com... I'd contact Rational tech support (and then once you find out that anything tougher than a license key causes them to brain lock) and then contact your local sales rep who can put you in contact with the local tech rep. The tech reps are usually very knowledgeable and are a great resource for handling issues like this. The problem here is that the approach you take will be somewhat different with different compilers so probably the vendor is the best shot. As a general rule there is often some way of determining the entry point to the elaboration code and then calling it. This may require that you make a special elaboration procedure that calls multiple entries in the "proper" order. "Gordon Brunton" wrote in message news:ozER5.653999$8u4.9941815@news1.rdc1.bc.home.com... > Having been fruitless in my search for a solution to my problem I am hoping > someone on this newsgroup can assist. I am convinced there has to be > someone who has encountered this problem before. > > Background: > I'm currently involved in the implementation of a large scale Air Traffic > Control System written primarily written using Ada 83. The development > environment is Rational Apex on a Solaris platform. The > integration/delivery platform is HP/UX. > > Problem: > There are several components for the current system we intend to reuse from > another system in the product line (These components are written in Ada as > is the rest of the system). The requirement is that the source code for > these reused components is a non deliverable item. The source code for the > rest of the system is deliverable however and there is a requirement for the > customer to be able to maintain the system after delivery and thus they need > to be able to compile/link against the components we have not delivered the > source code for. > > My intention was to provide an API subsystem housing the components for > which no source code is delivered. The API subsystem would contain an API > interface and an object archive of the code we are not delivering. > > As way of an example, I have an API that looks like (the API is deliverable > code): > > foo_api.1.ada: > package foo_api is > > procedure Do_Something; > > end foo_api; > > foo_api.2.ada: > package body foo_api is > > procedure Do_Something; > pragma Import (Convention => Ada, Entity => Do_Something); > > end foo_api; > > Then I have the implementation that looks like (the implementation is the > non deliverable code that will be complied into an object archive): > > foo_implementation.1.ada > package foo_implementation is > > procedure Do_Something; > pragma Export (Convention => Ada, Entity => Do_Something); > > end; > > foo_implementation.2.ada > package body foo_implementation is > > procedure Do_Something is > begin > -- The work is performed here. > end; > > end foo_implementation; > > Note that the example above is given only as way of an example. The actual > API has many interfaces and the implementation is composed of many packages > most of which require some elaboration. > > This all works to the extent that I am able to compile all the code and > produce an object archive of the implementation (non deliverable code) with > which to resolve the symbols at link stage. However, as nothing in the main > program (that calls the API interfaces) includes any of the implementation > directly in it's closure a program error is resultant on execution. > > The problem is, is there anything I can do to force the code in the archive > library to be elaborated without doing an explicit pragma elaborate (which > would require me to 'with' the implementation and thereby defeat the whole > purpose of the exercise). > > I have encountered the 'pragma Export_Elaboration_Procedure' but can't find > any real examples of its usage (or if it would indeed be able to assist in > my problem). If anyone has experience using this and feels it may be of use > then please let me know. > > I would be grateful if anyone could assist me in providing a resolution to > this problem (or suggest an alternative approach that still meets my needs). > Note that it is preferable not to alter the non deliverable component code. > > Thanks in advance. > > Gordon Brunton > Senior Software Engineer > Ratheon Systems > (gordon_brunton@raytheon.com) > >