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