Bug 200236 - [maintainer][patch] games/wesnoth: fix for some FreeBSD 10.1 builds
Summary: [maintainer][patch] games/wesnoth: fix for some FreeBSD 10.1 builds
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: John Marino
URL:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2015-05-16 09:39 UTC by Torsten Zühlsdorff
Modified: 2015-05-27 09:30 UTC (History)
5 users (show)

See Also:


Attachments
patch to fix build bug (603 bytes, patch)
2015-05-16 09:39 UTC, Torsten Zühlsdorff
no flags Details | Diff
patch to revert wesnoth to 1.12.2 (2.50 KB, patch)
2015-05-26 10:43 UTC, Torsten Zühlsdorff
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Torsten Zühlsdorff 2015-05-16 09:39:03 UTC
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?
Comment 1 Dmitry Marakasov freebsd_committer 2015-05-17 13:40:45 UTC
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.
Comment 2 Torsten Zühlsdorff 2015-05-18 12:50:10 UTC
(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.
Comment 3 John Marino freebsd_committer 2015-05-25 14:50:29 UTC
"I've also got the suggestion to stay at the wesnoth-stable line and create a wesnoth-devel"

who is suggesting that?
Comment 4 John Marino freebsd_committer 2015-05-25 14:55:14 UTC
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?
Comment 5 Torsten Zühlsdorff 2015-05-25 15:46:42 UTC
(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.
Comment 6 John Marino freebsd_committer 2015-05-25 16:03:21 UTC
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.
Comment 7 Torsten Zühlsdorff 2015-05-25 18:21:25 UTC
(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.
Comment 8 John Marino freebsd_committer 2015-05-25 19:26:12 UTC
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?
Comment 9 Torsten Zühlsdorff 2015-05-26 10:43:07 UTC
Created attachment 157156 [details]
patch to revert wesnoth to 1.12.2
Comment 10 Torsten Zühlsdorff 2015-05-26 10:45:05 UTC
(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.
Comment 11 John Marino freebsd_committer 2015-05-26 10:51:34 UTC
okay.

by the way, the existing ".if ${COMPILER_TYPE} == gcc && ${COMPILER_VERSION} <= 42" lines look bogus.  It's good this is reverting those too.
Comment 12 commit-hook freebsd_committer 2015-05-26 12:39:56 UTC
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
Comment 13 John Marino freebsd_committer 2015-05-26 12:45:48 UTC
Okay, the port is back to 1.12.  I check that it still builds, it took a while to download 400Mb. :(
Comment 14 Dmitry Marakasov freebsd_committer 2015-05-26 15:40:16 UTC
(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.
Comment 15 John Marino freebsd_committer 2015-05-26 15:45:38 UTC
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.
Comment 16 John Marino freebsd_committer 2015-05-26 15:46:46 UTC
i mean USE_GCC=yes
Comment 17 Dmitry Marakasov freebsd_committer 2015-05-26 16:14:45 UTC
(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.
Comment 18 John Marino freebsd_committer 2015-05-26 16:22:58 UTC
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.
Comment 19 Dmitry Marakasov freebsd_committer 2015-05-26 16:33:30 UTC
(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.
Comment 20 John Marino freebsd_committer 2015-05-26 16:38:02 UTC
"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.
Comment 21 mvharding 2015-05-26 16:42:07 UTC
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.
Comment 22 John Marino freebsd_committer 2015-05-26 16:44:15 UTC
I tested this in poudriere amd64/10, it built fine.

I do not believe this is not a boost issue.

Please use poudriere perhaps?
Comment 23 mvharding 2015-05-26 16:52:48 UTC
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.
Comment 24 Dmitry Marakasov freebsd_committer 2015-05-26 17:00:09 UTC
(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.
Comment 25 John Marino freebsd_committer 2015-05-26 17:07:48 UTC
"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.
Comment 26 John Marino freebsd_committer 2015-05-26 17:09:36 UTC
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.
Comment 27 Dmitry Marakasov freebsd_committer 2015-05-26 17:59:18 UTC
(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.
Comment 28 John Marino freebsd_committer 2015-05-26 18:04:08 UTC
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 ?
Comment 29 mvharding 2015-05-26 18:21:34 UTC
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...
Comment 30 Don Lewis freebsd_committer 2015-05-27 09:30:15 UTC
(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.