loading libunitsync.so will break for gcc 5.x executables
Moderator: Moderators
loading libunitsync.so will break for gcc 5.x executables
currently a gcc 5.x executable loading libunitsync.so will crash with some weird errors. the linux static builds are (afaik) compiled with gcc 4.8.
sadly there is no easy solution: to keep the existing way unitsync is used, the program which loads unitsync needs to be compiled with the same compiler version. maybe see https://github.com/springlobby/springlobby/issues/624
afaik flobby / springlobby / weblobby are or will be affected.
possible (IMHO) realistic solutions:
1. create some executable which is shipped with spring static builds which exposes api via tcp
2. use a lobby client only for online playing / download required stuff from webserver (as zk afaik does) and use "inengine" stuff for singleplayer / offline stuff. this very likely would break hosting without the help of an autohost.
... ?
1. has the benefit that it could be used by all lobbies and all online services. also some prototype exists, but atm it only writes stuff to disk: https://github.com/springlobby/lsl/issues/4
also they don't exclude each other, both could be done.
anyone with a better idea / did i miss something?
sadly there is no easy solution: to keep the existing way unitsync is used, the program which loads unitsync needs to be compiled with the same compiler version. maybe see https://github.com/springlobby/springlobby/issues/624
afaik flobby / springlobby / weblobby are or will be affected.
possible (IMHO) realistic solutions:
1. create some executable which is shipped with spring static builds which exposes api via tcp
2. use a lobby client only for online playing / download required stuff from webserver (as zk afaik does) and use "inengine" stuff for singleplayer / offline stuff. this very likely would break hosting without the help of an autohost.
... ?
1. has the benefit that it could be used by all lobbies and all online services. also some prototype exists, but atm it only writes stuff to disk: https://github.com/springlobby/lsl/issues/4
also they don't exclude each other, both could be done.
anyone with a better idea / did i miss something?
Re: loading libunitsync.so will break for gcc 5.x executables
Ehm, all the unitsync API functions have plain C linkage... did gcc5 break that too or is this a deeper issue?
-
- Posts: 823
- Joined: 21 Oct 2008, 02:54
Re: loading libunitsync.so will break for gcc 5.x executables
Did you contact the gcc developers about this?
Re: loading libunitsync.so will break for gcc 5.x executables
Both seem like very drastic steps that will break a lot of applications.
I'd much rather investigate it a bit more to see if a better solution can be found that would offer backward compatibility. If not, just require GCC 4.x for now.
PS: Nothing stopping you from trying both of your ideas, just don't drop libunitsync.
I'd much rather investigate it a bit more to see if a better solution can be found that would offer backward compatibility. If not, just require GCC 4.x for now.
PS: Nothing stopping you from trying both of your ideas, just don't drop libunitsync.
Re: loading libunitsync.so will break for gcc 5.x executables
yes, it seems. i still can hope a bit that i'm wrong, but it seems so. unitsync crashes somewhere when freeing sth. in boost::path.Kloot wrote:did gcc5 break that too or is this a deeper issue?
without addresssanitizer:
*** Error in `./springlobby': free(): invalid pointer: 0x00007fce3402b4a8 ***
address sanitizer:
http://paste.springfiles.com/view/raw/67c8cc44
i'll try with a simple test-app, but cleanrock stepped with flobby into a very similar problem, too. see viewtopic.php?f=64&t=28000&start=20#p574915
hmm, with some more sleep, maybe there is a 3.:
3. static link libc into unitsync
(sorry for the wild guesses, atm i still don't fully understand the problem.)
edit:
it crashes in __cxa_finalize:
"call destructors of global (or local static) C++ objects and exit functions registered with atexit"
https://refspecs.linuxbase.org/LSB_3.2. ... alize.html
this leads to an other possible solution:
4. get rid of all static non-basic data types (i.e. std::string / std::vector / ...)
not sure if thats trivial, unitsync needs to dynamic allocate the memory when loading and free it when unloading:
i.e.
Code: Select all
static std::string lastError;
Code: Select all
class CVars {
std::string lastError
};
EXPORT(int) Init(bool isServer, int id)
...
vars = new CVars();
...
EXPORT(void) UnInit()
...
SafeDelete(vars);
...
- Silentwings
- Posts: 3720
- Joined: 25 Oct 2008, 00:23
Re: loading libunitsync.so will break for gcc 5.x executables
It would seem very odd to me if gcc had broke basic C linkage compatibility and not put a big hairy warning somewhere in the release notes (and I don't see one). There is http://developerblog.redhat.com/2015/02 ... e-c11-abi/, but the errors that claims too produce don't obviously match these ones.
Re: loading libunitsync.so will break for gcc 5.x executables
ah, seems like the old "memory that is allocated in the lib should be freed in the lib" requirement isn't satisfied then (meaning it was only not exposed as a problem sooner because of compatible ABI's)abma wrote: it crashes in __cxa_finalize:
"call destructors of global (or local static) C++ objects and exit functions registered with atexit"
yup, no more non-POD globals or local statics (in *any* code compiled into unitsync, so e.g. FileSystem needs to be checked too)abma wrote:not sure if thats trivial, unitsync needs to dynamic allocate the memory when loading and free it when unloading
note: this will also affect AI's
Re: loading libunitsync.so will break for gcc 5.x executables
Unitsync should be a cli program not a library, and its output should be json/xml/standard format data that can be loaded by whatever program or processing mechanism desired. It would make development of tools significantly easier, make unitsync a lot more testable, and completely sidestep issues such as this
Re: loading libunitsync.so will break for gcc 5.x executables
Nothing's stopping you from making a JSON/whatever wrapper, but C libraries are a standard and very useful to have.AF wrote:Unitsync should be a cli program not a library, and its output should be json/xml/standard format data that can be loaded by whatever program or processing mechanism desired. It would make development of tools significantly easier, make unitsync a lot more testable, and completely sidestep issues such as this
Re: loading libunitsync.so will break for gcc 5.x executables
small update:
it seems that it doesn't crash when springlobby doesn't use boost/filesystem. not sure why it works without it. needs a bit more testing.
flobby which suffers from this problem also uses boost/filesystem, so... needs testing :)
it seems that it doesn't crash when springlobby doesn't use boost/filesystem. not sure why it works without it. needs a bit more testing.
flobby which suffers from this problem also uses boost/filesystem, so... needs testing :)
Re: loading libunitsync.so will break for gcc 5.x executables
gajop wrote:Nothing's stopping you from making a JSON/whatever wrapper, but C libraries are a standard and very useful to have.
My recommendation is a "unitsync.exe", I believe any efforts would be better spent building this rather than a complex work around such as a TCP back-channel, as it provides the same information, but in a more flexible format, with additional options ( such as a basic interface for shell scripting, completely decoupled wrapper tools etc ). We already have a cache file which means half the work has already been done
Re: loading libunitsync.so will break for gcc 5.x executables
without ipc it can't be used in a lot of services, its not worth the effort. also such an executable basicly already exists in lsl, see my first post.AF wrote:My recommendation is a "unitsync.exe", I believe any efforts would be better spent building this rather than a complex work around such as a TCP back-channel, as it provides the same information, but in a more flexible format, with additional options ( such as a basic interface for shell scripting, completely decoupled wrapper tools etc ). We already have a cache file which means half the work has already been done