Le jeudi 07 septembre 2017 à 11:17 +0200, Niels de Vos a écrit : > On Wed, Sep 06, 2017 at 12:39:42PM +0200, Michael Scherer wrote: > > Hi, > > > > so I have been trying to make the internal freebsd builder usable, > > sinc > > eit was freshly installed and not building anything. > > > > Over the course of the day, I found a few missing deps, found a ton > > of > > warnings (I started to fix the easy one, not sure what to do for > > the > > more complicated one around gf_log formating), but yesterday, I > > stumbled on a more puzzling issue: > > > > CCLD glusterfsd > > ../../contrib/argp-standalone/libargp.a(argp-help.o): In function > > `_help': > > /tmp/glusterfs/contrib/argp-standalone/argp-help.c:1608: undefined > > reference to `argp_fmtstream_set_wmargin' > > /tmp/glusterfs/contrib/argp-standalone/argp-help.c:1622: undefined > > reference to `argp_fmtstream_set_lmargin' > > FreeBSD seems to provide argp-standalone as a port. It would be > better > to use that instead of our bundled version. > https://www.freebsd.org/ports/devel.html#argp-standalone-1.3_2 Yeah, I tried, it wasn't picked up. And I am not keen on digging in configure.ac to make it work :) Let's see if my last change on build.sh are fixing it: https://github.com/gluster/glusterfs-patch-acceptance-tests/pull/89 > > > I also see message like this: > > libtool: warning: relinking 'libgfapi.la' > > *** Warning: Linking the shared library libgfapi.la against the > > *** static library ../../contrib/argp-standalone/libargp.a is not > > portable! > > libgfapi should not need to link with libargp. This probably is an > error > in LDFLAGS or something. > > > After looking at the old builder, I found a few differences: > > - old one is FreeBSD 10.1, new one is 10.3 > > - old one is using gcc 4.8, new one was on clang. > > > > So I did install gcc, turn out that this was the version 5 by > > default > > on FreeBSD and it still do not work with it. > > > > Then I forced gcc4.8 and now it build fine. > > Even better, once I forced the version, it also build (but I > > suspect > > that's just some bad cleanup on my side, more tests are needed) > > > > Any reason on why this would fail on gcc 5, and not 4.8, and what > > we > > should do for that ? > > I don't know of any reason, but we should fix it somehow. Yup, but si, it seems it wasn't related to gcc version exactly. But this also bring the question of what should we use on freebsd for testing, since default is clang, and there is 5 versions of gcc. We might also need to clean flags passed to the compiler, since for example -rdynamic is not supported by clang (even if I discovered that flag yesterday) And another question is wether we should push -Werror as well on that platform, since there is a certain amount of warnings that would be hard to fix (most notably the whole issue of pthread_t being a opaque type in POSIX, and that we try to print somehow) both on gcc and clang. But they are technically bugs (and a standard violation too, even if it seems the standard is missing a proper function for that) > > I also found that what fail is to build only in Jenkins, most > > likely > > due to the setup where we build with a out of source tree directory > > for > > binary. It work fine if doing ./configure ; make ; make install > > Yeah, this is one of the things that people want to see supported > (although I don't remember the reason). It breaks every now and then > :-/ It shouldn't, since we test it. But as my 2nd mail show, my debugging lead me to wrong conclusions. > HTH, > Niels -- Michael Scherer Sysadmin, Community Infrastructure and Platform, OSAS
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-devel
