 |
 |
Thanks, that sounds great, Lukasz! -Daniel On 09/18/2014 07:06 AM, Lukasz Janyst wrote: > The problem is not there in master anymore. The reason you see it is > that your tag "4.0.0rc3-qsClient2.lsst1" gets concatenated with > "first_cache_imp_alja". The resulting string exceeds the number of > allowed characters. In master and in v4.0.1 this has been changed to > XrdFileCache, and the problem is not there anymore. The following > commit shortens the version string length to 25 characters. > > https://github.com/xrootd/xrootd/commit/0df6150bfbae4d7ff5c3edc6944e5abfe499c3a3 > > > Lukasz > > On 09/18/2014 02:21 PM, Andrew Hanushevsky wrote: >> Hi Lukasz, >> >> It's much more generous. The string allows for 40 bytes. So, it has to >> be truncated at 39 to allow for the null byte. >> >> Andy >> >> On Thu, 18 Sep 2014, Lukasz Janyst wrote: >> >>> I can put this in. Andy, what is the size limit for the tag? Is it 24 >>> characters? >>> >>> Cheers, >>> Lukasz >>> >>> On 09/18/2014 03:13 AM, Daniel L. Wang wrote: >>>> Um, I recognize that the "ideal" solution may be difficult. Did you >>>> see >>>> the "realistic" solution I proposed (report a warning and creatively >>>> shorten)? I think this could be implemented in genversion.sh . >>>> >>>> Incidentally, I looked for the documentation, and I didn't see it >>>> on the >>>> web pages or in the source tree, *except* in XrdVersion.hh.in, >>>> which has >>>> a declaration for a 40-byte char-array, and if you follow the code, >>>> you >>>> might infer that XrdVERSION is token-pasted together with a few other >>>> fields to fill that char-array. One might also guess (luckily) that >>>> genversion.sh computes XrdVersion.hh from XrdVersion.hh.in . I was the >>>> only one in the group lucky enough to connect the dots, perhaps only >>>> because of a hallway conversation several months ago where you >>>> mentioned >>>> that you figured out how to derive a version number from git tags. >>>> >>>> Anyway, I think that having genversion.sh warn/complain/bail-out on a >>>> too-long tag is not super hard to do. I don't know exactly what the >>>> limit is (I never got comfy with token pasting with the cpp), but >>>> putting this sort of code in genversion.sh should be of great help to >>>> the average user/sysadmin to go from "wha? initializer string too >>>> long? >>>> I didn't touch that part of the code." to "Ah. tags are used in xrootd >>>> for internal version numbers. I guess I can't use whatever tag I >>>> want. I >>>> can fix that.". >>>> >>>> We've worked around this by shortening the tag, but it might be >>>> nice to >>>> preventatively add a warning so as to avoid a future bug report from >>>> somebody else who used a tag too long (which could be us, if we >>>> forget). >>>> >>>> Cheers, >>>> -Daniel >>>> >>>> On 09/17/2014 02:24 PM, Andrew Hanushevsky wrote: >>>>> Indeed, I think this is documented. The field length is fixed at a >>>>> certain number of characters (usually long enough). Since the setting >>>>> is done using a simple macro, there is no way to do the suggested >>>>> calculations. Changing it would be deemed an ABO change which we are >>>>> prohibited from doing in EPEL. So, it would be wise to shorten the >>>>> tag. >>>>> >>>>> Andyx== >>>>> >>>>> On Wed, 17 Sep 2014, Daniel L. Wang wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> We have encountered what looks like a bug while building Xrootd that >>>>>> seems to be triggered by having a long git tag. >>>>>> >>>>>> Here is a build log snippet: >>>>>> Building CXX object >>>>>> src/CMakeFiles/XrdFileCache.dir/XrdFileCache/XrdFileCacheFactory.cc.o >>>>>> >>>>>> [ 97%] [ 97%] [ 97%] [ 97%] Building CXX object >>>>>> src/CMakeFiles/XrdFileCache.dir/XrdFileCache/XrdFileCacheIOEntireFile.cc.o >>>>>> >>>>>> >>>>>> >>>>>> Building CXX object >>>>>> src/CMakeFiles/XrdFileCache.dir/XrdFileCache/XrdFileCacheIOFileBlock.cc.o >>>>>> >>>>>> >>>>>> >>>>>> Building CXX object >>>>>> src/CMakeFiles/XrdFileCache.dir/XrdFileCache/XrdFileCachePrefetch.cc.o >>>>>> >>>>>> Building CXX object >>>>>> src/CMakeFiles/XrdFileCache.dir/XrdFileCache/XrdFileCacheInfo.cc.o >>>>>> Linking CXX executable xrdadler32 >>>>>> Linking CXX shared library libXrdPosixPreload.so >>>>>> Linking CXX shared library libXrdSecgsi.so >>>>>> [ 97%] Built target XrdPosixPreload >>>>>> [ 97%] Built target xrdadler32 >>>>>> [ 97%] Built target XrdSecgsi >>>>>> Linking CXX executable xrdfs >>>>>> Scanning dependencies of target XrdSecgsiGMAPDN >>>>>> [ 97%] Building CXX object >>>>>> src/CMakeFiles/XrdSecgsiGMAPDN.dir/XrdSecgsi/XrdSecgsiGMAPFunDN.cc.o >>>>>> Linking CXX shared library libXrdFfs.so >>>>>> /lsst/home/lsstsw/build/xrootd/src/XrdFileCache/XrdFileCacheFactory.cc:49: >>>>>> >>>>>> >>>>>> error: initializer-string for array of chars is too long >>>>>> [ 97%] Built target xrdfs >>>>>> [ 97%] Built target XrdFfs >>>>>> make[2]: *** >>>>>> [src/CMakeFiles/XrdFileCache.dir/XrdFileCache/XrdFileCacheFactory.cc.o] >>>>>> >>>>>> >>>>>> Error 1 >>>>>> make[2]: *** Waiting for unfinished jobs.... >>>>>> >>>>>> The tag we are using is: 4.0.0rc3-qsClient2.lsst1 , which is 24 >>>>>> characters. XrdFileCacheFactory.cc:49 has a line that uses the >>>>>> XrdVERSIONINFO macro, which apparently joins strings together based >>>>>> on a discovered git tag. It's interesting that the length limit was >>>>>> only hit when compiling XrdFileCacheFactory.cc -- I'm sure the macro >>>>>> was referenced in many parts of code that successfully compiled. >>>>>> >>>>>> Ideally, I think the code should be robust enough to handle >>>>>> arbitrarily-long tags. But realistically, I think a warning and some >>>>>> creative tag shortening: "SomebodysReallyReallyLongTag" --> >>>>>> "SomebodysRe...gTag" would suffice, and be simpler to implement. >>>>>> >>>>>> I'm not positive that the issue exists on the mainline xrootd--if >>>>>> there have been updates to the tag/version handling, I should >>>>>> certainly pull a new version. The version I'm using is in my >>>>>> repository on github: wangd/xrootd, tag: qsClient2 (but re-tagged to >>>>>> the long string above). >>>>>> >>>>>> Have a nice day, >>>>>> >>>>>> -Daniel >>>>>> >>>>>> ######################################################################## >>>>>> >>>>>> >>>>>> Use REPLY-ALL to reply to list >>>>>> >>>>>> To unsubscribe from the XROOTD-DEV list, click the following link: >>>>>> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1 >>>>>> >>>> >>>> ######################################################################## >>>> >>>> Use REPLY-ALL to reply to list >>>> >>>> To unsubscribe from the XROOTD-DEV list, click the following link: >>>> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1 >>> >>> ######################################################################## >>> >>> Use REPLY-ALL to reply to list >>> >>> To unsubscribe from the XROOTD-DEV list, click the following link: >>> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1 >>> > ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-DEV list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1