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
