2023-02-02 08:53 CET

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0006454Spring engineGeneralpublic2023-01-28 16:02
ReporterCommanderSpice 
Assigned Toabma 
PrioritynormalSeveritymajorReproducibilityalways
StatusassignedResolutionopen 
Product Version 
Target VersionFixed in Version 
Summary0006454: spring-dedicated does not start
DescriptionThe spring-dedcated of builds 174 and later refuse to start.
Build 169 works for me.

I failed to find anything suspicios in the diff between the versions.

I was unable to reproduce the issue when building from source.
Steps To Reproduce1. Start ./spring-dedicated.

Observed behavior:
./spring-dedicated: /lib64/libpthread.so.0: version `GLIBC_PRIVATE' not found (required by ./spring-dedicated)

Expected behavior:
spring-dedicated should print its help.
Additional InformationObjdump shows broken spring-dedicated importing GLIBC_PRIVATE:

objdump --all spring-dedicated | grep GLIBC_PRIVATE -C1
  required from libpthread.so.0:
    0x0963cf85 0x00 06 GLIBC_PRIVATE
    0x09691a75 0x00 07 GLIBC_2.2.5

I don't think it should import the symbol, no idea why it does it.
Tagsdevelop
Checked infolog.txt for ErrorsIrrelevant
Attached Files

-Relationships
+Relationships

-Notes

~0020617

abma (administrator)

https://buildbot.springrts.com/#/builders/6/builds/154

../../rts/System/Platform/Misc.cpp:117: warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
../../rts/lib/asio/include/asio/detail/impl/socket_ops.ipp:3343: warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

~0020618

abma (administrator)

should be fixed by

https://github.com/spring/spring/commit/6e0ea59a859abbc130945838dfb0fa75062c5c59

currently waiting for a full rebuild: i guess cmake cached the wrong lib to link to.

~0020619

abma (administrator)

hm, i've wasted already several hours with getting static compiles work again: its fixable but is it worth the trouble?


IMHO we should target to ship spring as flatpak: what do you think?

springlobby already is and it works mostly nice, so this shouldn't be an issue for spring. spads + springlobby + pr-downloader needs to be adjusted for this, but it shouldn't break this easy as static builds.

linux is made for shared libs :-|

~0020620

CommanderSpice (reporter)

I am not a fan of flatpak and would prefer fixing the static build.

I'll have a look at it.

The build machine just builds with PREFER_STATIC_LIBS and spring, spring-headless and spring-dedicated should be linked statically, except for unitsync?

~0020621

abma (administrator)

no, its much more complicated:

it compiles with these self-compiled libs:

https://github.com/spring/spring-lxc/blob/master/install/make_static_libs.sh

i guess one of the libs has a missing / wrong parameter.

my flatpak is working:

https://github.com/spring/com.springrts.Spring

~0020622

CommanderSpice (reporter)

After playing around with it for some time, I agree: static linking is no fun, at least not with glibc.
I tried the flatpak and it works for me with a small fix: https://github.com/spring/com.springrts.Spring/pull/1

Do you want me to do anything for SPADS/springlobby/pr-downloader?

They probably need to be aware of a possible flatpak installation, and in case of SPADS, install/update it.
I think it would be useful to still allow a non-flatpak engine.

~0020623

CommanderSpice (reporter)

For the record, I was able to build pr-downloader using this:
set(CMAKE_CXX_LINK_EXECUTABLE ${CMAKE_CXX_COMPILER} <FLAGS> <CMAKE_CXX_LINK_FLAGS> <LINK_FLAGS> <OBJECTS> -o <TARGET> -Wl,-Bstatic <LINK_LIBRARIES> -Wl,-Bshared -lc)

This can use the libs as pkg-config returns them (-lfoo) and it fails if one of the static libraries is missing.
The resulting binary is only linked dynamically to glibc and the GCC runtime, which might be enough to run it on decently current systems.
If I am not mistaken, the engine is supposed to use dynamic linking for the hardware access libs (SDL, OpenGL, OpenAL) anyway.

But I don't really like it.
Flatpak looks like a better alternative, despite the complexity it adds.

~0020624

abma (administrator)

yeah, i guess the flatpak is the way to go. but this makes unitsync problematic as the data is required by springlobby.

i'll try to fix https://github.com/springlobby/springlobby/issues/48 and basicly get rid of unitsync and then to make all work again.
+Notes

-Issue History
Date Modified Username Field Change
2023-01-12 15:00 CommanderSpice New Issue
2023-01-12 15:00 CommanderSpice Tag Attached: develop
2023-01-13 10:48 abma Assigned To => abma
2023-01-13 10:48 abma Status new => assigned
2023-01-13 10:49 abma Note Added: 0020617
2023-01-13 10:52 abma Note Added: 0020618
2023-01-14 20:34 abma Note Added: 0020619
2023-01-15 13:34 CommanderSpice Note Added: 0020620
2023-01-17 00:31 abma Note Added: 0020621
2023-01-17 17:01 CommanderSpice Note Added: 0020622
2023-01-18 18:07 CommanderSpice Note Added: 0020623
2023-01-28 16:02 abma Note Added: 0020624
+Issue History