Problems linking again stdc++ and estdc++
Hi ports@,
i'm currently porting the game engine for jagged alliance 2 [1]
to openbsd. If i clone the repository and do
# pkg_add sdl gmake gcc g++
$ CC=egcc CXX=eg++ gmake
the program builds and runs fine. It also ships with unittests,
which all pass. However, i now tried to build a port (see
attachment). It also builds, but when i run the unittests, the
following line is printed:
ja2:/usr/lib/libstdc++.so.57.0: /usr/local/lib/libestdc++.so.16.0 :
WARNING: symbol(_ZN11__gnu_debug17_S_debug_messagesE) size mismatch, relink
your program
What can i do to link against estdc++?
Please note that this port is a WIP, the license doesn't allow
commercial use, so i'm unsure if the package would be allowed on
cd or only on ftp.
Here is the Makefile for convenience:
-
# $OpenBSD: Makefile.template,v 1.68 2013/10/02 07:34:45 ajacoutot Exp $
COMMENT = Jagged Alliance 2 engine with bugfixes
DISTNAME = 9f7f461f0a2d
PKGNAME = ja2-stracciatella-${DISTNAME}
REVISION = 3
CATEGORIES =games
HOMEPAGE = https://bitbucket.org/gennady/ja2-stracciatella/overview
# SFI-SCLA / public domain
#PERMIT_PACKAGE_CDROM = No #is publishing the package a commercial use?
PERMIT_PACKAGE_CDROM = Yes
# make port-lib-depends-check can help
WANTLIB += boost_filesystem boost_system c m pthread SDL stdc++ # gtest
gtest_main
MASTER_SITES = https://bitbucket.org/gennady/ja2-stracciatella/get/
# some source files contain a BOM which gcc 4.2.1 can't handle
MODULES = gcc4
MODGCC4_LANGS = c c++
MODGCC4_ARCHS = *
BUILD_DEPENDS = devel/sdl \
devel/boost
#devel/gtest
LIB_DEPENDS = devel/sdl \
devel/boost
# devel/gtest
USE_GMAKE = Yes
WRKDIST = ${WRKDIR}/gennady-ja2-stracciatella-${DISTNAME}/
NO_TEST = Yes
.include bsd.port.mk
-
Thanks for help,
Nils
[1]: https://bitbucket.org/gennady/ja2-stracciatella/
ja2-stracciatella.tgz
Description: GNU Zip compressed data
Re: Problems linking again stdc++ and estdc++
On Mon, May 19, 2014 at 3:22 PM, Nils R m...@hxgn.net wrote: Hi ports@, i'm currently porting the game engine for jagged alliance 2 [1] to openbsd. If i clone the repository and do # pkg_add sdl gmake gcc g++ $ CC=egcc CXX=eg++ gmake the program builds and runs fine. It also ships with unittests, which all pass. However, i now tried to build a port (see attachment). It also builds, but when i run the unittests, the following line is printed: ja2:/usr/lib/libstdc++.so.57.0: /usr/local/lib/libestdc++.so.16.0 : WARNING: symbol(_ZN11__gnu_debug17_S_debug_messagesE) size mismatch, relink your program What can i do to link against estdc++? Not a real problem, it's just a warning.
Re: Problems linking again stdc++ and estdc++
On 2014/05/19 15:22, Nils R wrote:
Hi ports@,
i'm currently porting the game engine for jagged alliance 2 [1]
to openbsd. If i clone the repository and do
# pkg_add sdl gmake gcc g++
$ CC=egcc CXX=eg++ gmake
the program builds and runs fine. It also ships with unittests,
which all pass. However, i now tried to build a port (see
attachment). It also builds, but when i run the unittests, the
following line is printed:
ja2:/usr/lib/libstdc++.so.57.0: /usr/local/lib/libestdc++.so.16.0 :
WARNING: symbol(_ZN11__gnu_debug17_S_debug_messagesE) size mismatch, relink
your program
What can i do to link against estdc++?
This program *is* linking against estdc++, but a library it depends on
links against stdc++, hence the warning as the two conflicting libraries
are loaded into the same address space, so you can't be sure which one
is used for function calls and they don't have a fully compatible ABI.
(Note that this may work OK for some programs but this doesn't mean
it will work for every program).
This is an increasing problem again as we run into more and more
programs using features from newer language specifications not supported
by old compilers..
Please note that this port is a WIP, the license doesn't allow
commercial use, so i'm unsure if the package would be allowed on
cd or only on ftp.
The CD is commercial, so PERMIT_PACKAGE_CDROM cannot be set to yes.
(generally games need fairly careful checking, especially with
artwork/audio etc, even for ftp).
DISTNAME = 9f7f461f0a2d
this isn't an acceptable distname for the ports tree, this would probably
want something like this:
DISTNAME= ja2-stracciatella-[something]
DISTFILES= ${DISTNAME}{9f7f461f0a2d}${EXTRACT_SUFX}
the [something] would usually be based on the date (e.g. 0.20140519) if
you cannot persuade upstream to make a real release.
# some source files contain a BOM which gcc 4.2.1 can't handle
If that's the only reason for using a gplv3 GCC, can these files just
be patched instead? Alternatively, how does clang handle them?
Re: Problems linking again stdc++ and estdc++
Stuart Henderson schrieb am 19.05.2014 15:57:
On 2014/05/19 15:22, Nils R wrote:
Hi ports@,
i'm currently porting the game engine for jagged alliance 2 [1]
to openbsd. If i clone the repository and do
# pkg_add sdl gmake gcc g++
$ CC=egcc CXX=eg++ gmake
the program builds and runs fine. It also ships with unittests,
which all pass. However, i now tried to build a port (see
attachment). It also builds, but when i run the unittests, the
following line is printed:
ja2:/usr/lib/libstdc++.so.57.0: /usr/local/lib/libestdc++.so.16.0 :
WARNING: symbol(_ZN11__gnu_debug17_S_debug_messagesE) size mismatch,
relink your program
What can i do to link against estdc++?
This program *is* linking against estdc++, but a library it depends on
links against stdc++, hence the warning as the two conflicting libraries
are loaded into the same address space, so you can't be sure which one
is used for function calls and they don't have a fully compatible ABI.
(Note that this may work OK for some programs but this doesn't mean
it will work for every program).
This is an increasing problem again as we run into more and more
programs using features from newer language specifications not supported
by old compilers..
The funny thing is that if i compile it directly from git in my home folder,
the warning doesn't show up and all tests pass. With the ports version, the
warning shows and some tests fail.
Please note that this port is a WIP, the license doesn't allow
commercial use, so i'm unsure if the package would be allowed on
cd or only on ftp.
The CD is commercial, so PERMIT_PACKAGE_CDROM cannot be set to yes.
(generally games need fairly careful checking, especially with
artwork/audio etc, even for ftp).
Yes, that's what i thought. This port is only for the engine though, to
play the game, one needs the official game data which does not come with
the port, so ftp distribution should be allowed.
DISTNAME = 9f7f461f0a2d
this isn't an acceptable distname for the ports tree, this would probably
want something like this:
DISTNAME= ja2-stracciatella-[something]
DISTFILES= ${DISTNAME}{9f7f461f0a2d}${EXTRACT_SUFX}
the [something] would usually be based on the date (e.g. 0.20140519) if
you cannot persuade upstream to make a real release.
Upstream offers releases, but i wanted to test the latest git to see if a
problem was fixed. For the real port, i will stick to releases of course.
# some source files contain a BOM which gcc 4.2.1 can't handle
If that's the only reason for using a gplv3 GCC, can these files just
be patched instead? Alternatively, how does clang handle them?
clang fails to build because of some problems with gtest, but i had no time
to look into it. Might not be a big issue though. Should i conclude from
this that clang is favoured over a gpl3 licensed gcc? If so, is there a
reason to favor non-gpl3 compilers for ports?
Nils
Re: Problems linking again stdc++ and estdc++
On Mon, May 19, 2014 at 06:07:27PM +0200, Nils R wrote:
Stuart Henderson schrieb am 19.05.2014 15:57:
On 2014/05/19 15:22, Nils R wrote:
Hi ports@,
i'm currently porting the game engine for jagged alliance 2 [1]
to openbsd. If i clone the repository and do
# pkg_add sdl gmake gcc g++
$ CC=egcc CXX=eg++ gmake
the program builds and runs fine. It also ships with unittests,
which all pass. However, i now tried to build a port (see
attachment). It also builds, but when i run the unittests, the
following line is printed:
ja2:/usr/lib/libstdc++.so.57.0: /usr/local/lib/libestdc++.so.16.0 :
WARNING: symbol(_ZN11__gnu_debug17_S_debug_messagesE) size mismatch,
relink your program
What can i do to link against estdc++?
This program *is* linking against estdc++, but a library it depends on
links against stdc++, hence the warning as the two conflicting libraries
are loaded into the same address space, so you can't be sure which one
is used for function calls and they don't have a fully compatible ABI.
(Note that this may work OK for some programs but this doesn't mean
it will work for every program).
This is an increasing problem again as we run into more and more
programs using features from newer language specifications not supported
by old compilers..
The funny thing is that if i compile it directly from git in my home folder,
the warning doesn't show up and all tests pass. With the ports version, the
warning shows and some tests fail.
The port is using egcc (gcc 4.8) because the port includes the gcc4
module. The code in your home uses gcc, i.e. gcc 4.2.
Please note that this port is a WIP, the license doesn't allow
commercial use, so i'm unsure if the package would be allowed on
cd or only on ftp.
The CD is commercial, so PERMIT_PACKAGE_CDROM cannot be set to yes.
(generally games need fairly careful checking, especially with
artwork/audio etc, even for ftp).
Yes, that's what i thought. This port is only for the engine though, to
play the game, one needs the official game data which does not come with
the port, so ftp distribution should be allowed.
DISTNAME = 9f7f461f0a2d
this isn't an acceptable distname for the ports tree, this would probably
want something like this:
DISTNAME= ja2-stracciatella-[something]
DISTFILES= ${DISTNAME}{9f7f461f0a2d}${EXTRACT_SUFX}
the [something] would usually be based on the date (e.g. 0.20140519) if
you cannot persuade upstream to make a real release.
Upstream offers releases, but i wanted to test the latest git to see if a
problem was fixed. For the real port, i will stick to releases of course.
# some source files contain a BOM which gcc 4.2.1 can't handle
If that's the only reason for using a gplv3 GCC, can these files just
be patched instead? Alternatively, how does clang handle them?
clang fails to build because of some problems with gtest, but i had no time
to look into it. Might not be a big issue though. Should i conclude from
this that clang is favoured over a gpl3 licensed gcc? If so, is there a
reason to favor non-gpl3 compilers for ports?
No. You can use whatever you want.
Both gcc 4.2 and 4.8 use the system binutils (a pretty old version). If
you need support for CPU instructions not supported by binutils 2.15,
try with clang.
Re: Problems linking again stdc++ and estdc++
On 2014/05/19 18:07, Nils R wrote:
# some source files contain a BOM which gcc 4.2.1 can't handle
If that's the only reason for using a gplv3 GCC, can these files just
be patched instead? Alternatively, how does clang handle them?
clang fails to build because of some problems with gtest, but i had no time
to look into it. Might not be a big issue though. Should i conclude from
this that clang is favoured over a gpl3 licensed gcc? If so, is there a
reason to favor non-gpl3 compilers for ports?
My preferences in order (*if* things work properly with that compiler) :-
1. default compiler from the base os
2. ports clang
3. ports gcc
If it's just a small fix to be able to use 1) then do that, don't stack
things in a bulk build behind a (slow) build of an additional C compiler
if that isn't needed.
1) and 2) currently use libstdc++ from base, avoiding conflicts.
Some specific points about this port; please add this:
MAKE_FLAGS= Q= CXX=${CXX} CC=${CC}
Q= disables hiding command lines in upstream's Makefile, the others
honour user choices of compiler.
As for the BOM it can just be stripped
# strip BOM, gcc 4.2.1 doesn't understand it
post-extract:
perl -pi -e 's,\xef\xbb\xbf,,' ${WRKSRC}/Build/Utils/_*Text.cc
it runs into various gtest-related problems e.g.
_build/lib-gtest/src/gtest-internal-inl.h:86: error: expected constructor,
destructor, or type conversion before 'extern'
_build/lib-gtest/src/gtest-internal-inl.h:109: error: expected constructor,
destructor, or type conversion before 'extern'
_build/lib-gtest/src/gtest-internal-inl.h:112: error: 'GTEST_API_' does not
name a type
[...]
do we need the tests anyway though? adding WITH_UNITTESTS=0 to MAKE_FLAGS
skips them and then it builds with base gcc.
Re: Problems linking again stdc++ and estdc++
Stuart Henderson schrieb am 19.05.2014 23:23:
On 2014/05/19 18:07, Nils R wrote:
# some source files contain a BOM which gcc 4.2.1 can't handle
If that's the only reason for using a gplv3 GCC, can these files just
be patched instead? Alternatively, how does clang handle them?
clang fails to build because of some problems with gtest, but i had no time
to look into it. Might not be a big issue though. Should i conclude from
this that clang is favoured over a gpl3 licensed gcc? If so, is there a
reason to favor non-gpl3 compilers for ports?
My preferences in order (*if* things work properly with that compiler) :-
1. default compiler from the base os
2. ports clang
3. ports gcc
If it's just a small fix to be able to use 1) then do that, don't stack
things in a bulk build behind a (slow) build of an additional C compiler
if that isn't needed.
1) and 2) currently use libstdc++ from base, avoiding conflicts.
Ok, makes sense. Thank you for the explanation.
Some specific points about this port; please add this:
MAKE_FLAGS= Q= CXX=${CXX} CC=${CC}
Q= disables hiding command lines in upstream's Makefile, the others
honour user choices of compiler.
done
As for the BOM it can just be stripped
# strip BOM, gcc 4.2.1 doesn't understand it
post-extract:
perl -pi -e 's,\xef\xbb\xbf,,' ${WRKSRC}/Build/Utils/_*Text.cc
Thanks, this won't be fixed upstream because Visual Studio adds a BOM every
time the file is saved, but this line is a quick and easy fix.
it runs into various gtest-related problems e.g.
_build/lib-gtest/src/gtest-internal-inl.h:86: error: expected constructor,
destructor, or type conversion before 'extern'
_build/lib-gtest/src/gtest-internal-inl.h:109: error: expected constructor,
destructor, or type conversion before 'extern'
_build/lib-gtest/src/gtest-internal-inl.h:112: error: 'GTEST_API_' does not
name a type
[...]
do we need the tests anyway though? adding WITH_UNITTESTS=0 to MAKE_FLAGS
skips them and then it builds with base gcc.
We don't need the tests, but there still is this weird thing i still don't get:
when i compile the source code directly (with a new gcc/g++), there are no gtest
problems, and all tests pass (without the stdc++ confusion). However, when
compiling it with the ports Makefile, these problems show up. I'll try to
find the reason for this tomorrow.
Nils
