Re: fis-gtm

[Thorsten Alteholz <debian-med@alteholz.de>]

Hi Bhaskar,

On Mon, 25 Jul 2011, Bhaskar, K.S wrote:
> For Linux, root.root is preferred and bin.bin is acceptable.  Also, the
> norm should be to allow world execution of GT.M.

ok, finally I have got it ;-).

> [KSB2] I don't understand the part about calling the configure script
> twice.

Oh, I thought so much about the configure script, I confused it with the 
make process here.

>        Even though they are compiled from the same source code, the 32-
> and 64-bit binaries of GT.M are different and packaged & installed
> separately.

Yes, but in case I want to create the 32-bit version on a 64-bit CPU, I need 
to call make twice and do a 'setenv OBJECT_MODE 32' in between, right?

> Why do you say that you don't expect anyone to run GT.M on arm?

While working with ARM processors there have been always resource problems 
sooner or later. But you are right, I didn't thought about those things 
you mentioned. So we need a bootstrap for arm :-).

> [KSB2] Someone installing a new version would choose the latest release.
> But we have users who distribute applications on top of GT.M.  They may
> have a periodic repackage / release cycle, and if they are running
> stably, there is less work for them to do to continue using an existing
> GT.M version until their next cycle.

Ok, but we are talking about the distribution via Debian/Ubuntu or 
whatever derivate. So if someone has another application that depends on 
one release, then of course due to this dependency this release won't be 
deleted. If someone uses Debian as a basis and adds his own stuff before 
distributing it, he should either announce this fact and the needed 
release won't be deleted. Or he does his own thing and uses "his" release 
in any way.
So I don't see any problem that unused releases might be deleted in a new 
Debian release. In this case deleting doesn't mean that the packages 
disappears. All of the next 23 releases will remain in the archive and can 
be used!

> If GT.M is unfriendly to other UTF-8 locales, I definitelyt want to know
> so that we can fix it.  If GT.M requires en_US.utf8 that may be
> unfriendly, and we'll consider what we can do about it.

There are severeal lines like:
 utflocale=`locale -a | grep -i en_us ...`
in configure and later there is a test:
  if [ $utflocale = "" ]; then
or:
  if [ "$found_icu" -ne 0  -a "$utflocale" != "" ] ; then
     doutf8=1
  else
     doutf8=0
  fi
May I say that this is an unfriendly behaviour?

There is another issue. After updating my sid machine it wasn't possible 
to build the package from sources. It says something about missing 
include file. Other packages replaced the -I- with -iquote which does not 
work in your case. After adding the attached patch, everything was fine again.

  Thorsten


--- fis-gtm-server.org/sr_linux/gtm_env_sp.mk	2011-08-02 18:16:25.000000000 +0200
+++ fis-gtm-server/sr_linux/gtm_env_sp.mk	2011-08-02 18:47:37.000000000 +0200
@@ -65,8 +65,11 @@
 gt_cc_option_optimize=-O2 -fno-defer-pop -fno-strict-aliasing -ffloat-store
 gt_cc_options_common+= -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_XOPEN_SOURCE=600 -fsigned-char
 
+# add this to compile for Debian
+gt_cc_option_I= -I/usr/include/asm
+
 ifeq ($(gt_build_type),32)
-gt_cc_option_I=-I-
+gt_cc_option_I+=-I-
 endif
 
 ifeq ($(gt_machine_type), x86_64)
@@ -85,8 +88,8 @@
 # with always includeing it.
 
 gt_cc_option_I+= -I/emul/ia32-linux/usr/include/
-else
-gt_cc_option_I=
+#else
+#gt_cc_option_I=
 endif
 endif