Latest dwarfs mainline update refers to a version of folly that cannot be linked statically

[maxirmx]

The last version of folly picked by dwarfs mainline
tamatebako/dwarfs@21b474a
cannot be used as static library since it conflicts with libstdc++

[maxirmx]

I propose we postpone this issue. The update does not create any specific value.
We will stay at the latest working version
tamatebako/dwarfs@78fd324

[ronaldtse]

@maxirmx while you have fixed metanorma/dwarfs, can you rebase the changes on top of upstream master? Thanks!

[maxirmx]

@ronaldtse I did not correct the issue. I fetched upstream from mhn:dwarfs and it broke static linking.
So I pinned the integration script to use the last working commit.

The issue is relates to facebook code and I propose to postpone it so that we can move ahead with the packager.

[ronaldtse]

Ok. Is there anything in upstream that we need to contribute or everything has been sent in?

[maxirmx]

I plan to fix this issue later and place a pull request

[maxirmx]

Since static build is not a requirement anymore (per tamatebako/tebako#42) this is not a requirement either and can be discarded.

[maxirmx]

I am reopening it because I have realized that it is not related to 'full' static build.
This issue arises when I attempt to use folly itself as a static library since it conflicts with libstdc++ in such configuration.

/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/libstdc++.a(eh_ptr.o): in function `std::rethrow_exception(std::__exception_ptr::exception_ptr)':
(.text._ZSt17rethrow_exceptionNSt15__exception_ptr13exception_ptrE+0x0): multiple definition of `std::rethrow_exception(std::__exception_ptr::exception_ptr)'; folly/libfolly.a(ExceptionTracerLib.cpp.o):/home/runner/work/dwarfs/dwarfs/folly/folly/experimental/exception_tracer/ExceptionTracerLib.cpp:143: first defined here
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/libstdc++.a(eh_throw.o): in function `__cxa_throw':
(.text.__cxa_throw+0x0): multiple definition of `__cxa_throw'; folly/libfolly.a(ExceptionTracerLib.cpp.o):/home/runner/work/dwarfs/dwarfs/folly/folly/experimental/exception_tracer/ExceptionTracerLib.cpp:102: first defined here
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/libstdc++.a(eh_throw.o): in function `__cxa_rethrow':
(.text.__cxa_rethrow+0x0): multiple definition of `__cxa_rethrow'; folly/libfolly.a(ExceptionTracerLib.cpp.o):/home/runner/work/dwarfs/dwarfs/folly/folly/experimental/exception_tracer/ExceptionTracerLib.cpp:110: first defined here
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/libstdc++.a(eh_catch.o): in function `__cxa_begin_catch':
(.text.__cxa_begin_catch+0x0): multiple definition of `__cxa_begin_catch'; folly/libfolly.a(ExceptionTracerLib.cpp.o):/home/runner/work/dwarfs/dwarfs/folly/folly/experimental/exception_tracer/ExceptionTracerLib.cpp:123: first defined here
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/libstdc++.a(eh_catch.o): in function `__cxa_end_catch':
(.text.__cxa_end_catch+0x0): multiple definition of `__cxa_end_catch'; folly/libfolly.a(ExceptionTracerLib.cpp.o):/home/runner/work/dwarfs/dwarfs/folly/folly/experimental/exception_tracer/ExceptionTracerLib.cpp:132: first defined here
collect2: error: ld returned 1 exit status

[maxirmx]

Practically we can take several approaches:

1. Do nothing and pin the versions of dwarfs (and folly) that worked for us. This will be good enough since dwarfs is not under active development and it is highly unlikely that new folly features will have any significant impact on tebako.
2. See if we can play with linker flags so that this issue disappear. Since static linking is poorely documented so this approach is 'magic' or extensive research.
3. Add some conditional compilation to dwarfs in order to be able to build a version without references to folly exception tracing module. This will be reasonable approach because dwarfs (and ours) usage of folly is not very advanced and we can rely on basic exception handling. I am not sure though if it would be possible to reduce references to folly library as needed.
4. Research folly, see if we can open an issue/suggest a fix.

For now I think no 1 is the best for the reasons explained above.

[ronaldtse]

@maxirmx agree, let's take 1 for now.

[maxirmx]

It looks like it is not possible to use folly with statically linked application:
giters.com/facebook/folly/issues/1623

However, we are not creating statically linked application and folly/dwarfs do support required linkage model that we use as described here:
tamatebako/tebako#42

So, I am closing this issue as irrelevant for tebako.