Yaroslav, I assume that you will take care of setting LC_ALL in the debian package build, correct?
Luis, One comment down below. On 06/20/12 15:34, Bhaskar, K.S wrote: > > > On 06/20/2012 03:26 PM, Luis Ibanez wrote: >> >> Status Update: >> >> 1) The execution permissions problem has been solved. >> (it was due to a problem with LD_LIBRARY_PATH >> and fakeroot). Brad fixed it here: >> https://github.com/luisibanez/fis-gtm/commit/8dde79ed64efebc53e4ac2dbd6c4ed0c394e5286 >> >> >> 2) The installed files now do not have any internal references >> to the destdir directory. (which is good news !) >> >> >> 3) We are now tracking a problem with GTMHELP.o GTMHLPD.o >> The "configure" script compiles them, but the it deletes them, >> and that prevents the help from working. > > [KSB] On the 64-bit platform, configure should use ld to put them in the > shared library $gtm_dist/libgtmutil.so and then > delete the .o files. $gtmroutines should end in $gtm_dist/libgtmutil.so to > find these files. On the 32-bit platform, no > shared library should be built, the .o files should remain in $gtm_dist, and > $gtmroutines should end in $gtm_dist. [amul] I fixed this (thanks for bringing it to our attention) and added to the list of fixes we need to make in the upstream. While testing zhelp, I noticed that the global directory files were missing in the install directory. I fixed this. > >> >> >> 4) As far as testing goes, after installing the Debian package, >> we managed to run: helloworld.m and fibonacci.m but >> have trouble running threee1nf.m. >> >> We created the local database using the installed gtm, >> but then, when running threeen1f.m, the program starts >> and doesn't quit in the usual 30 seconds, but instead >> continues running. > > [KSB] Did you source the gdedefaults file with GDE when you created the > database, or did you just exit from GDE and use its > default values? If the latter, the values for database key and record size > may not be large enough for threeen1f. In this > case, the child processes probably errored out leaving the parent processing > waiting for ever (it's a demo/test program, not > production grade application code). Check for non-empty *.mjo and *.mje > files, which are the stdout/stderr of the child > processes. > > Regards > -- Bhaskar > >> >> >> We will need help from >> Amul and Bhaskar to figure out items (3) and (4).... :-) >> >> >> Luis >> > > -- > GT.M - Rock solid. Lightning fast. Secure. No compromises. _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
