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?

Reply via email to