Rene, Yes, I do trust software systems with long LD_LIBRARY_PATH because these software systems do handle the LD_LIBRARY_PATH automatically for me. I would not trust it if I had to type it by hand. Pere > -----Original Message----- > From: Rene Brun [mailto:brun@pcbrun.cern.ch] > Sent: 06 December 2004 21:42 > To: Pere Mato Vila > Cc: Rene Brun; roottalk; Fons Rademakers > Subject: RE: [ROOT] Core dump due to long LD_LIBRARY_PATH > > Pere, > > a better solution than any existing solution can always be found. > Will you trust a software system with a LD_LIBRARY_PATH that > takes more than 4000 characters? > > Rene > > On Mon, 6 > Dec 2004, Pere Mato Vila wrote: > > > Thanks Rene. > > By the way. Why it needs to be a limit in the length? Can > not a better > > solution be found? > > > > Pere > > > > > -----Original Message----- > > > From: brun@pcbrun.cern.ch [mailto:brun@pcbrun.cern.ch] On > Behalf Of > > > Rene Brun > > > Sent: 06 December 2004 14:41 > > > To: Pere Mato Vila > > > Cc: roottalk; Fons Rademakers > > > Subject: Re: [ROOT] Core dump due to long LD_LIBRARY_PATH > > > > > > Hi Pere, > > > > > > Your "serious" problem will become a "no" problem if you execute > > > root.exe instead of root. > > > > > > The executable in $ROOTSYS/bin/root is a small fron-end > showing the > > > splash-screen and launching the main executable root.exe. > > > To launch root.exe the front-end has to set the > LD_LIBRARY_PATH for > > > root.exe. > > > Only 512 chars were allocated for an internal array to build the > > > LD_LIBRARY_PATH. I have extended this array to 4096 in the CVS > > > version. > > > The problem is only visible with groups having extremely long > > > LD_LIBRARY_PATH. > > > > > > Rene Brun > > > > > > Pere Mato Vila wrote: > > > > > > > > Dear rooters, > > > > > > > > We have in LHCb serious problems when using "root" within the > > > > new > > > > SLC3 platform. ROOT 3.10.02 core dumps at the start with > > > the following > > > > traceback: > > > > > > > > #0 0x00a5bbac in mempcpy () from /lib/tls/libc.so.6 > > > > #1 0x00a4f4b2 in _IO_default_xsputn_internal () from > > > > /lib/tls/libc.so.6 > > > > #2 0x00a28517 in vfprintf () from /lib/tls/libc.so.6 > > > > #3 0x00a443cc in vsprintf () from /lib/tls/libc.so.6 > > > > #4 0x00a2f02d in sprintf () from /lib/tls/libc.so.6 > > > > #5 0x0804931f in SetLibraryPath () > > > > #6 0x080497c9 in main () > > > > > > > > The reason I think is due to the change in length of the > > > > LD_LIBRARY_PATH due to the change in the platform tag we > > > use in this > > > > new platform. We have changed rh73_gcc3232 to slc3_ia32_gcc323 > > > > increasing the total length from 1110 bytes to 1166. > > > > > > > > Can this limitation be removed? Or build a protection that > > > it does not > > > > core dump? > > > > Thanks in advance, > > > > > > > > Pere > > > > > > >
This archive was generated by hypermail 2b29 : Sun Jan 02 2005 - 05:50:10 MET