building with --so fails #467
Comments
|
If I recall correctly we don't support building seastar as a shared library. That option is deprecated and should be removed. |
|
That's too bad, my app must be a pluggable module (.so). |
|
On 2018-06-19 15:20, shadeware wrote:
That's too bad, my app must be a pluggable module (.so).
By the way, I learned about this flag in [README-OSv.md](https://github.com/scylladb/seastar/blob/master/README-OSv.md) (not that I'm targeting OSv, I just tried to gather as much info as possible).
I might be wrong but you can still build a shared library app and link
libseastar.a into it.
I think README-OSv.md is outdates as a whole but I'm not sure about
that, @nyh can tell you more about that.
|
|
On Tue, Jun 19, 2018 at 3:23 PM, Botond Dénes <notifications@github.com>
wrote:
On 2018-06-19 15:20, shadeware wrote:
> That's too bad, my app must be a pluggable module (.so).
> By the way, I learned about this flag in [README-OSv.md](https://
github.com/scylladb/seastar/blob/master/README-OSv.md) (not that I'm
targeting OSv, I just tried to gather as much info as possible).
>
I might be wrong but you can still build a shared library app and link
libseastar.a into it.
I think README-OSv.md is outdates as a whole but I'm not sure about
that, @nyh can tell you more about that.
Yes, README-OSv.md is outdated (OSv support in Seastar was removed piece by
piece, and
now only small pieces actually remain). But it does explain what "--so" is
trying to do:
It doesn't only compile Seastar itself as a shared object libseastar.so
instead of libseastar.a. Rather
it compiles also the example applications as shared objects, and this is
where you saw the problem.
I think this mode of compilation fit exactly what you're trying to do
(building a shared object which
includes both Seastar and your application), and it exposes real bugs in
our build scripts which are
not only crazy-complex, but now we even have two of them, and I can no
longer keep track which
one has which bugs :-( I think we need to fix those bugs.
Finally, one comment:
I don't know why you're trying to build a Seastar application as .so, but
if it's because you want
to run it alongside "normal" (non-Seastar) code, you'll have various
problems. One is that
Seastar will try, by default, to fill all the memory and CPU. Another is
that Seastar redefines
malloc() in a way which may break the non-Seastar code. The README-OSv.md
suggests
to use -DSEASTAR_DEFAULT_ALLOCATOR.
|
|
Thank you for responses! Linking libseastar.a to my .so doesn't seem to work. I can't tell exact linking flags since I'm using CMake and apparently there's nothing like compile_commands.json for linker, but when I try to add and when I supply these flags to (Apparently this is thread-local variable).
Yep, I'm planning to use seastar alongside normal code (so that seastar will handle I/O and other async/performance-sensitive stuff and pass results to normal code), and I intend to use |
|
Please also look at You'll need to adjust the c-ares configuration to have it produce relocatable code (-fpic). Alternatively, teach ./configure.y to use the system libcares.so instead of the bundled sources, if your system carries a new-enough version of c-ares. |
|
It actually worked! I did the following steps:
So, my problem is resolved, but |
|
On 2018-06-19 19:57, shadeware wrote:
It actually worked! I did the following steps:
1) add `set (CMAKE_POSITION_INDEPENDENT_CODE TRUE)` at the start of `c-ares/CMakeLists.txt`
2) configure seastar with `-fPIC` (e.g. `./configure.py --disable-hwloc --cflags="-DSEASTAR_DEFAULT_ALLOCATOR -fPIC"`)
3) ninja
4) copy pkg-config's compile flags to CMAKE_CXX_FLAGS
5) copy libs from pkg-config's linker flags to CMake's `TARGET_LINK_LIBRARIES` arguments (not `${CMAKE_EXE_LINKER_FLAGS}`)
So, my problem is resolved, but `--so` still remains in code and docs. Should I close this issue?
The issue is still valid, to close it we should either:
1) Make --so work properly.
2) Remove it from configure.py and the docs.
As it looks like there is interest in this (1) would be preferred.
|
|
so support was added in #1484. |
Building seastar on ubuntu 18.04 with default gcc-7.3 fails with configure flag
--so(and succeeds without it).Error message:
I tried adding
set (CMAKE_POSITION_INDEPENDENT_CODE TRUE)at the start offmt/CMakeLists.txt, and the building went further. It stopped at this next error:I added
set (CMAKE_POSITION_INDEPENDENT_CODE TRUE)at the start ofc-ares/CMakeLists.txtas well, building finished without any more errors, but when I tried to compile and run simple apps they just kept crashing in random places, e.g. infmt::internal::WidthHandler::report_unhandled_arg(). Looks like I violated ODR somehow with my naive hacking.The text was updated successfully, but these errors were encountered: