 |
 |
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