Bhaskar, This may be a bit off topic (re licensing), but it does relate to the linking.
I recently divided my program up into modules, with a bunch of debug code all grouped into one TMGDEBUG.m file. When I did this, I noticed that my execution speed went way down. It seemed that the module is being loaded and dumped with every call. Is this true? Kevin --- "K.S. Bhaskar" <[EMAIL PROTECTED]> wrote: > Maury -- > > There are several cases of linking to consider with > GT.M for x86 > GNU/Linux. > > The most common is the default, when a process > executes a Do ^XYZ or a > ZLINK "XYZ". This is dynamically linked. > > With GT.M the top level of a process does not have > to be M code, but can > be in C (or another language). Any calls from C to > M are dynamically > linked, as are calls from M to C. C to C calls can > be dynamically > linked, or if two C modules are in the a shared > library, they are > statically linked to each other. Two C modules in > different shared > libraries are dynamically linked. > > Thus, for GT.M for x86 GNU/Linux, any code in M is > always dynamically > linked, and code in C is dynamically linked with > code in M, and for two > modules in C, it depends on how they are packaged. > > With GT.M on AIX, HP-UX and Tru64 UNIX, where code > in M can be put into > shared libraries, the same rule applies to M modules > as to C modules on > x86 GNU/Linux, namely that two M modules in the same > shared library are > considered statically linked to each other, and > dynamically linked to > anything not in that shared library. > > So, bottom line is that at least as far as GT.M is > concerned, linking is > always dynamic unless someone explicitly chooses to > make it static. > This means that if someone makes an add on to VistA > under the GPL, and > someone else makes another add on to VistA that is > under a license > incompatible with the GPL, the fact that linking is > dynamic means that > the GPL license of one module does not affect the > GPL-incompatible > license of another module. > > Your question was very incisive, and I guess the > answer means that much > of our licensing discussion was unnecessary! I am > copying the > vista-open-source at yahoogroups.com, since much of > the licensing > discussion happened over there. > > Hope this explains things satisfactorily. If not, > please ask. > > -- Bhaskar > > On Fri, 2004-12-03 at 21:42, Maury Pepper wrote: > > Bhaskar, > > > > As long as you have the hood up, I'd like to ask > about GT.M with respect to "linking". As you know, > the recent conversations about open source licensing > touched on the issue of static versus dynamic > linking. This seems to be the line that separates > "contaminated" from "uncontaminated" code. (Excuse > the euphemisms.) So, what I would like is your > explanation of the linking that exists between > routines from two different packages running in a > single user's job space. For example, if you are > running FOIA VistA and an add-on accounting package > together, how might they be linked? If there are > multiple answers, that's OK. I think this is > relevant -- because, based on my understanding of > what is going on, I think we may need to redefine > certain terms in an M context because I'm not sure > that the industry standard terms apply. > > > > -maury- > > > > > > ----- Original Message ----- > > From: "K.S. Bhaskar" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Friday, December 03, 2004 8:12 PM > > Subject: RE: [Hardhats-members] Krung Thai Bank > goes live on GT.M > > > > > > Steve -- > > > > There are some differences down in the detail > level, mostly as a result > > of differences between hardware architectures, > operating systems, as > > well as what development found funding and what > did not. > > > > There are differences between GT.M on Alpha/VMS > and GT.M on UNIX/Linux: > > the underlying OS platforms are different enough > that we have different > > manuals for them - although the manuals are > generated from a common > > source with conditional text. The UNIX > implementations support > > identical implementations of the M language, but > here are some examples > > of the differences: > > > > * Some platforms support a "Direct IO" flag > which turns on the > > O_DIRECT setting for journal IO, which can > either speed things > > up or slow things down depending on the IO > subsystem. > > > > * GT.M on Sun SPARC Solaris supports Sun RPC > call-ins. The others > > don't. > > > > * The GT.M compiler on AIX, HP-UX and Tru64 > UNIX creates object > > files in a format that can be incorporated > into .so shared > > libraries. The GT.M compiler on Linux and > Solaris does not. > > > > * There may be differences in the ability to > pass parameters in > > registers when calling between M and C on > the different > > platforms, but I can't remember right now. > > > > * A GT.M process on AIX can have fewer > database files open at one > > time than on other platforms (the limit is > something like 9 > > caused by fact that each shared memory > segment uses a segment > > register). > > > > -- Bhaskar > > > > On Fri, 2004-12-03 at 18:44, Tomlinson, ,Steven B > wrote: > > > Aloha Bhaskar, > > > Thanks for the clarification, I have been > wondering what (if any) > > > differences there were between the GT.M > distributions. > > > > > > Steven B. Tomlinson > > > [EMAIL PROTECTED] > > > Pacific Telehealth and Technology Hui > > > www.PacificHui.org > > > > > *************************************************************************** > > This electronic mail transmission contains > confidential and/or privileged information intended > only for the person(s) named. > > Any use, distribution, copying or disclosure by > another person is strictly prohibited. > > > *************************************************************************** > > > > NOTE: Ce courriel est destine exclusivement au(x) > destinataire(s) mentionne(s) ci-dessus et peut > contenir de l'information privilegiee, > confidentielle et/ou dispensee de divulgation aux > termes des lois applicables. Si vous avez recu ce > message par erreur, ou s'il ne vous est pas destine, > veuillez le mentionner immediatement a l'expediteur > et effacer ce courriel. > > > > > > > > > > > > > ------------------------------------------------------- > > SF email is sponsored by - The IT Product Guide > > Read honest & candid reviews on hundreds of IT > Products from real users. > > Discover which products truly live up to the hype. > Start reading now. > > http://productguide.itmanagersjournal.com/ > > _______________________________________________ > > Hardhats-members mailing list > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/hardhats-members > === message truncated === __________________________________ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250 ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Hardhats-members mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hardhats-members
