Created attachment 156819 [details] patch to fix build bug Mike reported, that the new wesnoth 1.13.0 is not building at his 10.1 FreeBSD. I remember the error message; its exactly the same i could only reproduce at my 5 year old laptop. All other machines build wesnoth just fine. I've added a patch which builds wesnoth at FreeBSD 8.4, 9.3, 10.1 and 10.1 at my Laptop. This should fix the bug. But the approval of Mike would be very helpful, because he reported the bug. ;) Does it work with the patch, Mike?
This fix is not correct. This is not problem in wesnoth but boost - it build unusable library in presence of libiconv. Boost should be fixed instead.
(In reply to Dmitry Marakasov from comment #1) Until fix of boost this will render wesnoth at some machines not compilable. Also i'm not feeling able to fix boost. I've also got the suggestion to stay at the wesnoth-stable line and create a wesnoth-devel port instead of updating it to 1.13 development. I think this is a very good suggestion. Currently i'm in vacation and have no time for the wesnoth-devel port. But i would appreciate it, if someone can revert the update to 1.13.0. When back next week i will create a wesnoth-devel port and i will have a look at the boost problem. Maybe i'm able to help in some way.
"I've also got the suggestion to stay at the wesnoth-stable line and create a wesnoth-devel" who is suggesting that?
i just pulled this log from beef6: http://beefy6.nyi.freebsd.org/data/101amd64-default/387185/logs/wesnoth-1.13.0.log wesnoth is building right now. Can someone produce a poudriere log for freebsd 10.1 where wesnoth is not building?
(In reply to John Marino from comment #3) > "I've also got the suggestion to stay at the wesnoth-stable line and create a > wesnoth-devel" > who is suggesting that? This was Greg Lewis. And i think he is right. I've clearly overlooked, that wesnoth 1.13.0 is a development release. Therefore its better to stay with the 1.12.x line, which is the official stable release line. I will create another PR for this change. The fix of 1.13.0 should be done also.
well, we had a big PR about wesnoth and potential -devel, which I was against. I thought you were on that PR. Are you saying wesnoth releases are even ? e.g. 1.10, 1.12, 1.14? I was surprised that 1.13 came out so fast after 1.12 which took like a year. Personally, I was looking for a single port (only stable). Going back to 1.12 (with portepoch) is fine, but then I don't get why a -devel version is really needed.
(In reply to John Marino from comment #6) > well, we had a big PR about wesnoth and potential -devel, which I was against. > I thought you were on that PR. Sadly not. Maybe before i was the maintainer of the port? > Are you saying wesnoth releases are even ? e.g. 1.10, 1.12, 1.14? Until now: yes > I was surprised that 1.13 came out so fast after 1.12 which took like a year. > Personally, I was looking for a single port (only stable). Going back to 1.12 > (with portepoch) is fine, but then I don't get why a -devel version is really > needed. Personally i'm fine with just the stable port.
yes, it was before you were maintainer but I was under the impression you knew about it. So all we need to do is revert the last commit and bump the port epoch?
Created attachment 157156 [details] patch to revert wesnoth to 1.12.2
(In reply to John Marino from comment #8) > yes, it was before you were maintainer but I was under the impression you knew > about it. Sadly not. When i become the maintainer of this port, there was no update for 1.5 years. Therefore i did not expect some discussion about a -devel branch. > So all we need to do is revert the last commit and bump the port epoch? Yes. I've wrote a patch and added it. This is my first use of PORTEPOCH, so please have a closer look if everything is right.
okay. by the way, the existing ".if ${COMPILER_TYPE} == gcc && ${COMPILER_VERSION} <= 42" lines look bogus. It's good this is reverting those too.
A commit references this bug: Author: marino Date: Tue May 26 12:39:39 UTC 2015 New revision: 387468 URL: https://svnweb.freebsd.org/changeset/ports/387468 Log: games/wesnoth: Revert version 1.13 => 1.12 This port is supposed to track stable releases. Those end in even numbers, e.g. 1.10, 1.12, 1.14. The odd numbers are development releases. The upgrade to 1.13 was due to a misunderstanding about the version numbering scheme. PR: 200236 Submitted by: maintainer (Torsten Zuehlsdorff) Changes: head/games/wesnoth/Makefile head/games/wesnoth/distinfo head/games/wesnoth/pkg-plist
Okay, the port is back to 1.12. I check that it still builds, it took a while to download 400Mb. :(
(In reply to John Marino from comment #11) > by the way, the existing ".if ${COMPILER_TYPE} == gcc && ${COMPILER_VERSION} <= 42" lines look bogus. It's good this is reverting those too. They were not. If it's built with gcc, it needs recent version.
amdmi3, what supported release has a gcc has a version < 42 ? and the whole construct looks hacky. Better to set "USE_GCC=all" if OSREL:R == 8 rather than check if version == 42. In 4 weeks it won't even matter. It looked terrible.
i mean USE_GCC=yes
(In reply to John Marino from comment #15) > what supported release has a gcc has a version < 42 ? That's <= 42. And that's 8.* and 9.*. > and the whole construct looks hacky. Better to set "USE_GCC=all" if OSREL:R == 8 rather than check if version == 42. In 4 weeks it won't even matter. First, we depend on compiler version and not a system release, so we should check for compiler version. Next, 9.x won't go anywhere in 4 weeks.
I know "<=" was the symbol, but why "<"? It serves no purpose. That means it's really "== 42" FreeBSD 9 has clang installed in base. Is it not used over gcc? Basically the premise you are advocating using different compilers really based on release (a ports compiler for 8, and apparently 9). the compiler version is lockstep with the release.
(In reply to John Marino from comment #18) > I know "<=" was the symbol, but why "<"? It serves no purpose. That means it's really "== 42" For consistency. If it doesn't work with 42 it obviously doesn't work with < 42. > FreeBSD 9 has clang installed in base. Is it not used over gcc? It is not. > Basically the premise you are advocating using different compilers really based on release (a ports compiler for 8, and apparently 9). the compiler version is lockstep with the release. A compiler version has nothing to do with release.
"A compiler version has nothing to do with release." Well, I say I disagree. For any supported version of FreeBSD 8 will this not be true? "${COMPILER_TYPE} == gcc && ${COMPILER_VERSION} <= 42" about about FreeBSD 9? If those are always true in 100% of the cases, then use the less complex OPSYS and OSREL which do _not_ require USES+= compiler:features That was unnecessarily complex for academic releases. Let's be practical.
Wesnoth does not build from ports, still - it appears that if I install boost-libs via 'pkg install boost-libs', nm -D /usr/local/lib/libboost_locale.so | grep iconv | grep close outputs __bsd_iconv_close (sorry for the formatting, I don't have cut/paste against the VM where I did this) but if I run that against a ports build, it outputs U libiconv_close ...so the status of boost-libs package build vs. port build is suspect, and if you close this as 'fixed' then there is less pressure to fix boost_libs, and a ports build is still broken.
I tested this in poudriere amd64/10, it built fine. I do not believe this is not a boost issue. Please use poudriere perhaps?
It's the ports build that is broken, poudriere is supposed to do the same thing, right? Also, I doubt that boost-libs is supposed to link against the system iconv library for the pkg, but not for the build from ports... This is entirely a boost-libs issue FWIW, I will try to bring it up with the port maintainer.
(In reply to John Marino from comment #20) You just forget about all combinations of CC=/CXX=, compilers from base system and ports and updates of these, current and stable branches, "ports compiler" we had in plans afaik, freebsd and dragonfly differences etc. Compiler version is always objective. Release versions have nothing to do with this at all. > That was unnecessarily complex for academic releases. Let's be practical. Being practical, OPSYS/OSVERSION checks are _always_ more complex and less correct than compiler check. > I do not believe this is not a boost issue. It really is a boost issue, see comment #1. You won't catch this with poudriere.
"Being practical, OPSYS/OSVERSION checks are _always_ more complex and less correct than compiler check." It's equally correct. It also doesn't require changing USES so I don't get its considered more complex. The outliers are FreeBSD 8 and 9. In reality there should be a standard macro / USES for this, it's a fairly common issue. "It really is a boost issue, see comment #1. You won't catch this with poudriere. (his fix is not correct. This is not problem in wesnoth but boost - it build unusable library in presence of libiconv. Boost should be fixed instead.)" What changed? Boost has been the same forever. Wesnoth just reverted to what it was. the bsd_iconv thing is FreeBSD 11 only isn't it? Are you saying when you build it in ports, there is a good chance that libiconv is already installed for another reason and boost builds wrong outside of poudriere? I think that's what you must mean. I would think that would also be limited to a -CURRENT.
by the way, good luck getting boost updated. I tried pushing that a few times. Not even a response. Somebody should probably just update it and break openoffice / libreoffice in the process to get some attention.
(In reply to John Marino from comment #25) > It's equally correct. It also doesn't require changing USES so I don't get its considered more complex. The outliers are FreeBSD 8 and 9. Absolutely not, because OSVERSION checks do not take anything I've mentioned into account, and are not future-proof, as compiler.mk can be easily tweaked to e.g. support newer compiler versions. > In reality there should be a standard macro / USES for this, it's a fairly common issue. Pretty much yes, though it can be quite complex. Something along these lines: USES=compiler:4.6+,clang:3.6+ USES=compiler:gcc:any,clang:no,c++11-lib > Are you saying when you build it in ports, there is a good chance that libiconv is already installed for another reason and boost builds wrong outside of poudriere? > > I think that's what you must mean. I would think that would also be limited to a -CURRENT. Yes, that's what I mean. And it's not limited to -CURRENT - it affects all versions which have libiconv in base. That's 10.x for sure, not so sure for 9.x.
Why is this (iconv) apparently a new problem then? Boost hasn't changed in forever, wesnoth is now what it was. Lots of things use boost. Why am I only hearing about this issue now? if it's been ongoing, wouldn't it have been fixed a year ago ?
This is also affected by changes seen here: https://svnweb.freebsd.org/ports/head/Mk/Uses/iconv.mk?view=log, and there has definitely been some activity...
(In reply to John Marino from comment #18) There is no guarantee that clang is present on 9, 10, and 11. This is true by default on some of the tier 2 platforms according to src.conf(5), and on i386 or amd64 the end user might have added WITHOUT_CLANG to his /etc/src.conf. If using the base version of clang if present is OK then the cleanest solution might be to add USES=compiler:cwhatever to the Makefile. Since boost is used by this port, and boost is built with the default c++ compiler from base, it gets tricky. On FreeBSD 9, many of the USES=compiler options will use clang as the compiler and result in fatal libstdc++ vs. libc++ conflicts. USES=compiler:c++11-lib will generally do the right thing here because it will use the ports version of gcc if COMPILER_TYPE != clang. BTW, the COMPILER_VERSION check in ".if ${COMPILER_TYPE} == gcc && ${COMPILER_VERSION} <= 42" is pretty useless because it is always true when COMPILER_TYPE is gcc.