is added to the list of compiler's warning-flags. This triggers a
warning like:
/usr/include/c++/4.2/bits/basic_ios.h:156: warning: empty body in an if-statement
in g++42. When this compiler is used, where NO_WERROR is set, the port
fails to build, as warnings are treated as errors. This, pretty much,
means, that NO C++ code can currently be compiled with WARNS set to
anything on FreeBSD.
Work-around the deficiency for now by removing the ``-Wsystem-headers''
from CXXFLAGS after including bsd.lib.mk. This fixes graphics/libfpx on
8.x as well as allows the port to be built by gcc-4.2 on 6.x and 5.x.
Continuously reminded of by: pav
even i386 before, and does not anymore, as its numerous original bugs
were exposed by the evolving compiler. It never worked on a 64-bit
platform, as the original authors assumed sizeof(long) to be 4.
With this patch it compiles cleanly (WARNS=3) on both i386 and amd64
and should have no problems on other 64-bit systems.
A corrupt input-file may still result in a crash, but, at least, it
works correctly with correct input files. Tested on camera-generated
originals kindly provided by the originator of the PR below.
Bump PORTREVISION.
Approved by: portmgr (pav, after some deliberations)
Portmgr advised against bumping the SHLIB_MAJOR. They did not /insist/
so I chose to bump it -- the old version is too broken to have been
usable to anybody for years, and the dependant ports (such as Graphics
and ImageMagicks) need an easy way to insist on the new version (via
LIB_DEPENDS).
Was required to fix: 67815
the ImageMagick team, where Bob Friesenhahn made it work with IM.
Since then, Bob and other developers forked GraphicsMagick. libfpx
remained unchanged until January 2005, when ImageMagick released an
updated tar-ball with a patch applied. The release was botched (missing
a subdirectory) and I changed the port to use the old tar-ball on
GraphicsMagick's site and apply the same patch.
Since then, GraphicsMagick replaced the old 1.2.0.9 tarball with the new
1.2.0.10, where the patch is applied. On the same date, ImageMagick,
not to be outdone, "released" 1.2.0.11, WHICH IS NO DIFFERENT from
GraphicsMagick's version, except for libtool/configure soup.
I'm now switching the port to ImageMagick's mirrors again, simply
because they seem to have better bandwidth.
I must add, for the record, that ImageMagick team's behavior appears
rather dubious and unscrupulous in this incident. There was no need to
"release" their own tarball, especially considering, that some sources
are marked as "GraphicsMagick" (an embarassing oversight). I also
found, that those of my postings on ImageMagick's support forum, which
mentioned GraphicsMagick, were misteriously removed from the board
shortly after posting...
This update is made neccessary by there being no MASTER_SITES for the
original 1.2.0.9 tarball left. While at it, however, I also remove the
jpeg-dependency -- libfpx does not, actually, use it.
Prompted by: pointyhat (kris)
the missing .cxx extensions to two other source files listed in
files/Makefile.bsd. The previous commit to that file was trying to solve
the same problem, but now I have an up-to-date -current myself and could
easily reproduce it -- an test the solution.
It used to work up until up until -- apparently -- a recent change to
bsd.lib.mk. Let's see, if this fixes a problem spotted by Bento while
building on amd64.
package by explicitly appending -Wno-error to CXXFLAGS. This assumes,
the compiler is from the gcc family, but the assumption was already
there -- in the explicit -Werror appended to CFLAGS.
Reported by: Dirk Meyer
headers. While here, change PERL to RE_INPLACE and lock things down with
-Werror (in CFLAGS only, the C++ files generate some warnings, fixing
which is in the domain of the authors).
Submitted by: Naoya Nishimura
${LOCALBASE}/include. The old behaviour was working almost
always, because the package's own header files are well-named,
except for the common.h, which caused build failure for at least
one person.
PR: ports/32247
