LISTSERV 16.5 - XROOTD-DEV Archives

   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