Date: Thu, 15 Jan 2015 20:35:37 -0700 From: "Russell L. Carter" <rcarter@pinyon.org> To: freebsd-ports@freebsd.org Subject: libfxp fails with poudriere but not as a port Message-ID: <54B88709.3010604@pinyon.org>
next in thread | raw e-mail | index | archive | help
Greetings,
amd64 stable/10, updated across the failure.
I've been watching a poudriere build failure with graphics/libfpx for
several days now and investigated, and it is a curious failure. Some
advice solicited on the fix.
With an updated poudriere world, and an updated outside r277194
stable/10 world, graphics/libfxp fails with:
(wrapped, of course)
/wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-4/oless/h/fat.hxx:368:63:
error: explicitly assigning a variable of type 'SCODE' (aka 'int')
to itself [-Werror,-Wself-assign] do if (((HRESULT)(sc =
(FindMaxSect(&_sectMax)))<0)) { sc = sc; goto Err;} while(0);
which a little bit of grepping finds this line in fat.hxx:
msfChk(FindMaxSect(&_sectMax));
where msfChk is defined in msf.hxx:
#define msfErr(l, e) ErrJmp(msf, l, e, sc)
#define msfChkTo(l, e) do if (FAILED(sc = (e))) msfErr(l, sc) while(0)
#define msfChk(e) msfChkTo(Err, e)
and ErrJmp is defined in error.hxx:
#define ErrJmp(comp, label, errval, var) \
{\
var = errval;\
goto label;\
}
so that clearly, sc = sc, just like the compiler complained about.
Now normally I'd experiment with the macros a bit to see if I could
fix it but I am hesitant because if I update a ports tree on the same
system as the poudriere build system and make reinstall, everything
builds installs and works great (including wdm and emacs, the reason
that I've dug down this far). If I cd /usr/ports/graphics/build &&
make build, the compiler is /usr/bin/c++, while poudriere's log says
it used c++. Any ideas on what the difference might be would awesome.
Once I understand this I would be delighted to provide a patch.
Thanks,
Russell
Late thought: I elided a debug branch on the ErrJmp macro, is there
a reason why the ports tree might by default have debugging on while
poudriere would not? I don't see anything obvious in a /usr/ports
compiler command:
/usr/bin/c++ -O2 -pipe -DHAVE_WCHAR_H -DHAVE_DLFCN_H -DHAVE_SYS_TIME_H
-DHAVE_SYS_PARAM_H -DHAVE_SYS_MOUNT_H -Qunused-arguments
-fstack-protector -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter
-Wpointer-arith -Wno-uninitialized -Wno-empty-body -Wno-string-plus-int
-Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value
-Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion
-fno-rtti -fno-exceptions -fno-strict-aliasing -DHAVE_WCHAR_H
-DHAVE_DLFCN_H -DHAVE_SYS_TIME_H -DHAVE_SYS_PARAM_H -DHAVE_SYS_MOUNT_H
-I/usr/ports/graphics/libfpx/work/libfpx-1.3.1-4/oless/h
-I/usr/ports/graphics/libfpx/work/libfpx-1.3.1-4/jpeg
-I/usr/ports/graphics/libfpx/work/libfpx-1.3.1-4/ole
-I/usr/ports/graphics/libfpx/work/libfpx-1.3.1-4/basics
-I/usr/ports/graphics/libfpx/work/libfpx-1.3.1-4/ri_image
-I/usr/ports/graphics/libfpx/work/libfpx-1.3.1-4/oless
-I/usr/ports/graphics/libfpx/work/libfpx-1.3.1-4/fpx
-I/usr/ports/graphics/libfpx/work/libfpx-1.3.1-4/. -I/usr/local/include
-D_UNIX -Wno-c++11-extensions -c
/usr/ports/graphics/libfpx/work/libfpx-1.3.1-4/ole/oleprops.cpp -o
oleprops.o
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54B88709.3010604>