New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fails to build with boost 1.61 #887

Closed
Voker57 opened this Issue Aug 19, 2016 · 24 comments

Comments

Projects
None yet
6 participants
@Voker57
Contributor

Voker57 commented Aug 19, 2016

Latest git, debian unstable

Build log: http://dump.bitcheese.net/files/lutaryw/build.log.gz

@geoffthemedio

This comment has been minimized.

Show comment
Hide comment
@geoffthemedio

geoffthemedio Aug 19, 2016

Member

Probably duplicates #777

Member

geoffthemedio commented Aug 19, 2016

Probably duplicates #777

@Vezzra Vezzra added the category:bug label Aug 20, 2016

@Vezzra

This comment has been minimized.

Show comment
Hide comment
@Vezzra

Vezzra Aug 20, 2016

Member

I'd say yes, that's a duplicate, but just to be sure I'd like another opinion - @adrianbroher, you're on Linux, can you confirm the problem reported here is the same as in #777?

Member

Vezzra commented Aug 20, 2016

I'd say yes, that's a duplicate, but just to be sure I'd like another opinion - @adrianbroher, you're on Linux, can you confirm the problem reported here is the same as in #777?

@adrianbroher

This comment has been minimized.

Show comment
Hide comment
@adrianbroher

adrianbroher Aug 20, 2016

Contributor

Only the second part is the same.

Contributor

adrianbroher commented Aug 20, 2016

Only the second part is the same.

@Vezzra

This comment has been minimized.

Show comment
Hide comment
@Vezzra

Vezzra Aug 20, 2016

Member

Ok, in this case we need to keep this open as a separate issue.

Member

Vezzra commented Aug 20, 2016

Ok, in this case we need to keep this open as a separate issue.

@Vezzra

This comment has been minimized.

Show comment
Hide comment
@Vezzra

Vezzra Aug 21, 2016

Member

As decided in the discussion of #851 (see these comments), setting milestone to "Release v0.4.6" again for now.

Member

Vezzra commented Aug 21, 2016

As decided in the discussion of #851 (see these comments), setting milestone to "Release v0.4.6" again for now.

@Vezzra Vezzra added this to the Release v0.4.6 milestone Aug 21, 2016

@adrianbroher

This comment has been minimized.

Show comment
Hide comment
@adrianbroher

adrianbroher Aug 21, 2016

Contributor

Note:

Reverting boostorg/serialization@69ecae6 in the debian test chroot makes the issue go away. It's not a viable solution for us however.

Contributor

adrianbroher commented Aug 21, 2016

Note:

Reverting boostorg/serialization@69ecae6 in the debian test chroot makes the issue go away. It's not a viable solution for us however.

@LGM-Doyle

This comment has been minimized.

Show comment
Hide comment
@LGM-Doyle

LGM-Doyle Aug 21, 2016

Contributor

@adrianbroher I have some guesses.

The commit that you referenced (2 hours ago), suggests that adding delete operators to the serialized classes may fix the problem.

The log file linked above suggests a simpler solution may be to make the destructors public.

If you are not already on it (I assume that you are), I could try posting PRs with those solutions implemented.

Contributor

LGM-Doyle commented Aug 21, 2016

@adrianbroher I have some guesses.

The commit that you referenced (2 hours ago), suggests that adding delete operators to the serialized classes may fix the problem.

The log file linked above suggests a simpler solution may be to make the destructors public.

If you are not already on it (I assume that you are), I could try posting PRs with those solutions implemented.

@adrianbroher adrianbroher changed the title from [Bug] Fails to build with boost 1.61 to Fails to build with boost 1.61 Aug 21, 2016

@adrianbroher

This comment has been minimized.

Show comment
Hide comment
@adrianbroher

adrianbroher Aug 21, 2016

Contributor

@LGM-Doyle

The commit that you referenced (2 hours ago), suggests that adding delete operators to the serialized classes may fix the problem.

Well, I don't have much experience with overwriting new/delete and making the destructors public is just a cheap workaround as it doesn't convey the fact that UniverseObjects are not supposed to be managed by the Universe instance itself.

What do you think would be the best way to fix this?

Contributor

adrianbroher commented Aug 21, 2016

@LGM-Doyle

The commit that you referenced (2 hours ago), suggests that adding delete operators to the serialized classes may fix the problem.

Well, I don't have much experience with overwriting new/delete and making the destructors public is just a cheap workaround as it doesn't convey the fact that UniverseObjects are not supposed to be managed by the Universe instance itself.

What do you think would be the best way to fix this?

@LGM-Doyle

This comment has been minimized.

Show comment
Hide comment
@LGM-Doyle

LGM-Doyle Aug 21, 2016

Contributor

@adrianbroher I think the better fix is to make the destructors public, for the following reasons:

  • UniverseObject implies it is associated with Universe
  • the only place that UniverseObject can get a valid ID is from the Universe
  • overwriting delete will probably lead to complicated bugs.
Contributor

LGM-Doyle commented Aug 21, 2016

@adrianbroher I think the better fix is to make the destructors public, for the following reasons:

  • UniverseObject implies it is associated with Universe
  • the only place that UniverseObject can get a valid ID is from the Universe
  • overwriting delete will probably lead to complicated bugs.
@l29ah

This comment has been minimized.

Show comment
Hide comment
@l29ah

l29ah Oct 18, 2016

Contributor

Still an issue for 1.62.0, correct the ifdefs plz.

Contributor

l29ah commented Oct 18, 2016

Still an issue for 1.62.0, correct the ifdefs plz.

@Vezzra

This comment has been minimized.

Show comment
Hide comment
@Vezzra

Vezzra Oct 19, 2016

Member

I thought 5a3c309 fixed the issue... so did it turn up with 1.62 again so we need another fix, or didn't 5a3c309 fix the issue for you in the first place?

Member

Vezzra commented Oct 19, 2016

I thought 5a3c309 fixed the issue... so did it turn up with 1.62 again so we need another fix, or didn't 5a3c309 fix the issue for you in the first place?

@geoffthemedio

This comment has been minimized.

Show comment
Hide comment
@geoffthemedio

geoffthemedio Oct 19, 2016

Member

5a3c309 makes a change specifically for Boost 1.61, and would have no effect with any other boost version.

Member

geoffthemedio commented Oct 19, 2016

5a3c309 makes a change specifically for Boost 1.61, and would have no effect with any other boost version.

@Vezzra

This comment has been minimized.

Show comment
Hide comment
@Vezzra

Vezzra Oct 19, 2016

Member

Uh, stupid me, should have looked at the commit 😳

Well, looks like the fix needs to be extended to apply to 1.62 too... rename and reopen this issue, or open a separate one?

Member

Vezzra commented Oct 19, 2016

Uh, stupid me, should have looked at the commit 😳

Well, looks like the fix needs to be extended to apply to 1.62 too... rename and reopen this issue, or open a separate one?

@geoffthemedio

This comment has been minimized.

Show comment
Hide comment
@geoffthemedio

geoffthemedio Oct 20, 2016

Member

I made the version number checks >= instead of ==

6b971f6

Member

geoffthemedio commented Oct 20, 2016

I made the version number checks >= instead of ==

6b971f6

@Vezzra

This comment has been minimized.

Show comment
Hide comment
@Vezzra

Vezzra Oct 28, 2016

Member

@l29ah, just to be sure, everything now works for you?

Member

Vezzra commented Oct 28, 2016

@l29ah, just to be sure, everything now works for you?

@l29ah

This comment has been minimized.

Show comment
Hide comment
@l29ah

l29ah Oct 28, 2016

Contributor

On Fri, Oct 28, 2016 at 03:17:29AM -0700, Vezzra wrote:

@l29ah, just to be sure, everything now works for you?

/usr/include/boost/spirit/home/qi/detail/alternative_function.hpp:30:46: error: no type named ‘types’ in ‘boost::spirit::qi::detail::find_substituteboost::optional<boost::variant<boost::fusion::vector2<boost::optional<EmpireAffiliationType, ValueRef::ValueRefBase>, EmpireAffiliationType, boost::detail::variant::void, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_> >, EmpireAffiliationType>::variant_type {aka class boost::optionalboost::variant<boost::fusion::vector2<boost::optional<EmpireAffiliationType, ValueRef::ValueRefBase>, EmpireAffiliationType, boost::detail::variant::void, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_> >}’
typedef typename variant_type::types types;
^

() ascii ribbon campaign - against html mail
/\ http://arc.pasp.de/ - against proprietary attachments

Contributor

l29ah commented Oct 28, 2016

On Fri, Oct 28, 2016 at 03:17:29AM -0700, Vezzra wrote:

@l29ah, just to be sure, everything now works for you?

/usr/include/boost/spirit/home/qi/detail/alternative_function.hpp:30:46: error: no type named ‘types’ in ‘boost::spirit::qi::detail::find_substituteboost::optional<boost::variant<boost::fusion::vector2<boost::optional<EmpireAffiliationType, ValueRef::ValueRefBase>, EmpireAffiliationType, boost::detail::variant::void, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_> >, EmpireAffiliationType>::variant_type {aka class boost::optionalboost::variant<boost::fusion::vector2<boost::optional<EmpireAffiliationType, ValueRef::ValueRefBase>, EmpireAffiliationType, boost::detail::variant::void, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_> >}’
typedef typename variant_type::types types;
^

() ascii ribbon campaign - against html mail
/\ http://arc.pasp.de/ - against proprietary attachments

@Vezzra

This comment has been minimized.

Show comment
Hide comment
@Vezzra

Vezzra Oct 28, 2016

Member

Can you build with boost 1.61? If yes, that's probably a new issue specifically with 1.62, for which a separate issue should be opened.

Member

Vezzra commented Oct 28, 2016

Can you build with boost 1.61? If yes, that's probably a new issue specifically with 1.62, for which a separate issue should be opened.

@l29ah

This comment has been minimized.

Show comment
Hide comment
@l29ah

l29ah Oct 28, 2016

Contributor

On Fri, Oct 28, 2016 at 04:56:36AM -0700, Vezzra wrote:

Can you build with boost 1.61? If yes, that's probably a new issue specifically with 1.62, for which a separate issue should be opened.

#777

() ascii ribbon campaign - against html mail
/\ http://arc.pasp.de/ - against proprietary attachments

Contributor

l29ah commented Oct 28, 2016

On Fri, Oct 28, 2016 at 04:56:36AM -0700, Vezzra wrote:

Can you build with boost 1.61? If yes, that's probably a new issue specifically with 1.62, for which a separate issue should be opened.

#777

() ascii ribbon campaign - against html mail
/\ http://arc.pasp.de/ - against proprietary attachments

@Vezzra

This comment has been minimized.

Show comment
Hide comment
@Vezzra

Vezzra Oct 28, 2016

Member

Ok, I'm a bit confused... #777 has been closed because, if I understand correctly, solutions had been found to deal with the issues introduced by boost 1.61. So, assuming I read your response correctly, you can build with boost 1.61, but when using 1.62 the issues of #777 turn up again (as do the compile errors you posted above).

Which is confusing, because if these are still the same issues as with 1.61, why don't the fixes work anymore? Unless we're dealing with almost identical, but still new issues here introduced by 1.62 - in which case a separate issue should be opened (where of course #777 and this issue here should be referenced).

Member

Vezzra commented Oct 28, 2016

Ok, I'm a bit confused... #777 has been closed because, if I understand correctly, solutions had been found to deal with the issues introduced by boost 1.61. So, assuming I read your response correctly, you can build with boost 1.61, but when using 1.62 the issues of #777 turn up again (as do the compile errors you posted above).

Which is confusing, because if these are still the same issues as with 1.61, why don't the fixes work anymore? Unless we're dealing with almost identical, but still new issues here introduced by 1.62 - in which case a separate issue should be opened (where of course #777 and this issue here should be referenced).

@l29ah

This comment has been minimized.

Show comment
Hide comment
@l29ah

l29ah Oct 28, 2016

Contributor

On Fri, Oct 28, 2016 at 05:17:06AM -0700, Vezzra wrote:

Ok, I'm a bit confused... #777 has been closed because, if I understand correctly, solutions had been found to deal with the issues introduced by boost 1.61. So, assuming I read your response correctly, you can build with boost 1.61, but when using 1.62 the issues of #777 turn up again (as do the compile errors you posted above).

Which is confusing, because if these are still the same issues as with 1.61, why don't the fixes work anymore? Unless we're dealing with almost identical, but still new issues here introduced by 1.62 - in which case a separate issue should be opened (where of course #777 and this issue here should be referenced).

Because they check for exact version match, i suppose.

() ascii ribbon campaign - against html mail
/\ http://arc.pasp.de/ - against proprietary attachments

Contributor

l29ah commented Oct 28, 2016

On Fri, Oct 28, 2016 at 05:17:06AM -0700, Vezzra wrote:

Ok, I'm a bit confused... #777 has been closed because, if I understand correctly, solutions had been found to deal with the issues introduced by boost 1.61. So, assuming I read your response correctly, you can build with boost 1.61, but when using 1.62 the issues of #777 turn up again (as do the compile errors you posted above).

Which is confusing, because if these are still the same issues as with 1.61, why don't the fixes work anymore? Unless we're dealing with almost identical, but still new issues here introduced by 1.62 - in which case a separate issue should be opened (where of course #777 and this issue here should be referenced).

Because they check for exact version match, i suppose.

() ascii ribbon campaign - against html mail
/\ http://arc.pasp.de/ - against proprietary attachments

@geoffthemedio

This comment has been minimized.

Show comment
Hide comment
@geoffthemedio

geoffthemedio Oct 28, 2016

Member

Because they check for exact version match, i suppose.

Not anymore...

6b971f6

Member

geoffthemedio commented Oct 28, 2016

Because they check for exact version match, i suppose.

Not anymore...

6b971f6

@l29ah

This comment has been minimized.

Show comment
Hide comment
@l29ah

l29ah Oct 28, 2016

Contributor

On Fri, Oct 28, 2016 at 06:01:09AM -0700, Geoff wrote:

Because they check for exact version match, i suppose.

Not anymore...

6b971f6

You can't into context (#777).

CMakeLists.txt:if(${Boost_VERSION} EQUAL "106100")

() ascii ribbon campaign - against html mail
/\ http://arc.pasp.de/ - against proprietary attachments

Contributor

l29ah commented Oct 28, 2016

On Fri, Oct 28, 2016 at 06:01:09AM -0700, Geoff wrote:

Because they check for exact version match, i suppose.

Not anymore...

6b971f6

You can't into context (#777).

CMakeLists.txt:if(${Boost_VERSION} EQUAL "106100")

() ascii ribbon campaign - against html mail
/\ http://arc.pasp.de/ - against proprietary attachments

@geoffthemedio

This comment has been minimized.

Show comment
Hide comment
@geoffthemedio

geoffthemedio Oct 28, 2016

Member

If there are more places that need adjusting, can you make a pull request?

Member

geoffthemedio commented Oct 28, 2016

If there are more places that need adjusting, can you make a pull request?

@Vezzra

This comment has been minimized.

Show comment
Hide comment
@Vezzra

Vezzra Oct 28, 2016

Member

You can't into context (#777).

CMakeLists.txt:if(${Boost_VERSION} EQUAL "106100")

Ah, here is the culprit. I knew @geoffthemedio had adjusted a fix to apply not only for 1.61, but also for later versions, which is why I've been confused - I thought the fixes weren't for 1.61 only anymore.

Well, that of course needs to be fixed.

Member

Vezzra commented Oct 28, 2016

You can't into context (#777).

CMakeLists.txt:if(${Boost_VERSION} EQUAL "106100")

Ah, here is the culprit. I knew @geoffthemedio had adjusted a fix to apply not only for 1.61, but also for later versions, which is why I've been confused - I thought the fixes weren't for 1.61 only anymore.

Well, that of course needs to be fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment