[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [MoM] Packaging fis-get

On Mon, Jan 23, 2012 at 04:58:50PM -0500, Bhaskar, K.S wrote:
> [KSB] Even though both 32-bit and 64-bit GT.M for x86 are built from
> the same source code, the GT.M code generators are a couple of
> generations apart in design evolution.  The code generator for
> 32-bit is perhaps the most primitive version still in use and the
> 64-bit is one of the most modern.  The 32-bit code generator
> generates object code in an old format (I think XCOFF).  In both
> cases, the GT.M dynamic linker knows how to dynamically link .o
> files, but only the 64-bit .o files are in a format that ld
> understands, and only the 64-bit GT.M dynamic linker knows how to
> link object modules in .so shared libraries.

Any chance that such outdated build methods for 32-bit will be fixed in
the not so far future (considering the amount of developers Luis was
mentioning this should be doable IMHO).

> >>I'll look at converting the csh scripts.
> >Good.
> [KSB] Although I am personally a bash user, the entire GT.M
> automation infrastructure is build around tcsh (not even csh).  It
> may be easier to use tcsh for now and not try to convert the scripts
> till later.

While this is finally your decision I'd recommend replacing it where
possible anyway.  You can expect to have a POSIX shell installed on any
UNIX machine (whatever GT.M developers prefer as login shell).  Relying
on some specific shell just manifests the exceptional (=historically
grown) speciallities of GT.M.  I can not see a reason to not drop this
if possible.
> GT.M - Rock solid. Lightning fast. Secure. No compromises.

BTW, keeping csh scripts around is just a compromis. :-)
Kind regards



Reply to: