Hi Daniel,
On 26/08/2014 23:55, Daniel L. Wang
wrote:
[log in to unmask]"
type="cite">Hi Fabrice,
On 08/26/2014 10:06 AM, Fabrice Jammes wrote:
Build problem of Qserv master branch :
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 ?
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?
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.
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.
[log in to unmask]"
type="cite">
Qserv dependencies versions management in
eups :
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"
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.
Sorry, I made a mistake in my explainations, in fact tip of Qserv
master branch use new xroot version.
The problem I'd like to solve is :
I think that lsstsw build tool uses by default the tip of each
master branch of a given product dependencies. This may be wrong is
the tip a of dependency is broken, or if you want to re-package a
previous Qserv version (which may be only compliant with previous
versions of the dependencies and not the current ones).
=> That's why i'm interesting in learning how to describe in
lsstsw/eups the dependencies versions set for a given Qserv version.
I'm very interested about having informations about buildbot, but
for now it seems that even if Mario succeeded in integrating Qserv
with official LSST distribution server, only one Qserv version is
currently distributed
(see http://sw.lsstcorp.org/eupspkg/products/ which only contains
qserv-master-g6c2884f158.eupspkg) and furthermore the last xrootd
version isn't distributed. That's why I think buildbot integration
has not yet been performed, and for now distribution of new
Qserv/dependencies version still have to be done by hand (on my side
I'm only able to publish this under my user account, in
http://lsst-web.ncsa.illinois.edu/~fjammes/qserv-dev/). It would be
fine to be able to publish multiples Qserv releases/version in
official LSST distribution server, in preference with buildbot, or
even by hand with lsstsw.
Hope I'm clear enough.
[log in to unmask]"
type="cite">
-Daniel