[log in to unmask]" type="cite">Hi Fabrice,The fix works on SL6.2 (which is RedHat-based) and make Qserv compliant with Fedora19 (which provides gcc 4.8.3), could we add it please? It would be much more comfortable for testing Qserv packaging on multiple distros.
On 08/26/2014 10:06 AM, Fabrice Jammes wrote:
Build problem of Qserv master branch :I can't reproduce this easily, because I don't have a gcc 4.8 machine handy. Does the fix cause any problems for on RHEL6/Centos6 systems?
I have next problem while building last Qserv version with g++ (GCC) 4.8.3 20140624 (Red Hat 4.8.3-1)
Next fix at line 23 of core/modules/xrdfs/SConscript.test solves the problem :
p = env.Program('testMySqlFs_1.cc', LIBS=["XrdXrootd", *"XrdUtils"*])
This problem doesn't seems to happen with : g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4)
Do you think we can apply this patch to Qserv master branch ?
For now, perhaps it's better to comment it out rather than fix it--the xrdfs is likely to go away as soon as the dust settles on the xrootd port and the result protocol.
[log in to unmask]" type="cite">Sorry, I made a mistake in my explainations, in fact tip of Qserv master branch use new xroot version.
Qserv dependencies versions management in eups :I don't know how to solve this. I don't think it's a problem for new installations, because I think buildbot builds everything from scratch and it seems to build and test qserv without error. Perhaps your local eups stack doesn't know about the new xrootd package? Maybe there is something you can do with your installation to refresh package versions.
Furthermore, i see that Qserv master branch doesn't use a new xrootd version.
For now I don't know the right procedure to force a given Qserv version to use a given version of its dependencies.
It seems it is possible to do this with the rebuild command of lsstsw, but how ?
Please note that this problem seems to be the same than the one described in qserv-l mail named : "Redundant(?) installation of doxygen"
[log in to unmask]" type="cite">
-Daniel
Use REPLY-ALL to reply to list
To unsubscribe from the QSERV-L list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1