Bhaskar, tiny questions:
- are there any internal checks/reliance on "installed" files being read-only? what is the goal anyway behind making them read-only if owned by root who is the one with ability to revert that anyways? - shouldn't gtminstall have 'set -e' (or explicit || exit 1) so in case configure call fails, gtminstall fails? - due to above my installation 'succeeds' while configure generates quite a bit of errors for me atm, e.g. pointing to missing gdehelp.dat etc cp: cannot stat `gdehelp.dat': No such file or directory chown: cannot access `/home/yoh/deb/perspect/fis-gtm/fis-gtm-gitsvn/debian/fis-gtm-5.5.000/usr/lib/fis-gtm/V5.5-000+git80-g211bd16_x86_64/gdehelp.dat': No such file or directory cp: cannot stat `gtmhelp.dat': No such file or directory chown: cannot access `/home/yoh/deb/perspect/fis-gtm/fis-gtm-gitsvn/debian/fis-gtm-5.5.000/usr/lib/fis-gtm/V5.5-000+git80-g211bd16_x86_64/gtmhelp.dat': No such file or directory chmod: cannot access `gtmcrypt_ref.c': No such file or directory chmod: cannot access `gtmcrypt_ref.h': No such file or directory chmod: cannot access `gtmcrypt_interface.h': No such file or directory chmod: cannot access `gtmxc_types.h': No such file or directory chmod: cannot access `maskpass.c': No such file or directory chmod: cannot access `gtmcrypt_dbk_ref.c': No such file or directory ... I guess they shouldn't just be ignored, right? but those .c's are the original sources which aren't installed with the "stage1" installation -- is that just some legacy pieces in configure or am I missing smth? On Tue, 19 Jun 2012, Bhaskar, K.S wrote: > On 06/19/2012 12:03 AM, Yaroslav Halchenko wrote: > >> On 06/18/2012 02:42 PM, Brad King wrote: > >> Here is a patch series that solves this problem. I've only done > >> some lightweight/manual testing with this. The first patch > >> refactors both i386 and x86_64 code paths that emit the path to > >> the source file into the object file to send source file path > >> lookup through a common point (in obj_source.c). The second > >> patch modifies this common point to read a 'gtm_destdir' env var > >> and strip the prefix it names from source file paths. > >I gave brief check to Brad's patches and adjusted Debian packaging in SVN to > >make use of them (but without yet placing actual patches into quilt -- I just > >grabbed the HEAD of his master for the .orig "tarball"). From the first > >look (dumping strings on generated .o and .so) it did exactly what I hoped > >them > >to do -- thanks Brad! Then I have tried to run those basic commands Bhaskar > >has listed but it seems that mumps doesn't even try to load libgtmutil.so to > >get access to all those pre-built .o's placed into this dynamic library on my > >amd64 laptop... so anything I try fails, e.g.: > [KSB3] What is the value of $gtmroutines in the shell before you enter GT.M? > Regards > -- Bhaskar -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
