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 > > > > ------------------------------------------------------- > 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 ------------------------------------------------------- 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
