lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] LLVM libc++


From: Greg Chicares
Subject: Re: [lmi] LLVM libc++
Date: Tue, 4 Oct 2022 15:02:26 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.0

On 9/8/22 15:01, Vadim Zeitlin wrote:
> On Tue, 12 Jul 2022 01:34:36 +0200 I wrote:
> 
> Me> On Mon, 11 Jul 2022 23:01:57 +0000 Greg Chicares 
> <gchicares@sbcglobal.net> wrote:
> Me> 
> Me> GC> On 7/11/22 22:02, Vadim Zeitlin wrote:
> Me> GC> > On Mon, 11 Jul 2022 19:03:25 +0000 Greg Chicares 
> <gchicares@sbcglobal.net> wrote:
> Me> GC> > 
> Me> GC> > GC> On 7/11/22 16:22, Greg Chicares wrote:
> Me> GC> [...]
> Me> GC> > GC> Should I hope for better clang diagnostics if I use its
> Me> GC> > GC>   https://libcxx.llvm.org/
> Me> GC> > GC> standard library?
> Me> GC> > 
> Me> GC> >  Yes [...]
> Me> GC> 
> Me> GC> Do you happen already to know exactly how to do that? I tried:
> Me> GC> 
> Me> GC>   /root[0]#apt-get install libc++-dev
> Me> GC>   The following additional packages will be installed:
> Me> GC>     libc++-13-dev libc++1-13 libc++abi1-13 libunwind-13 
> libunwind-13-dev
> Me> GC>   The following packages will be REMOVED:
> Me> GC>     libunwind-dev
> Me> GC> 
> Me> GC> and said "No" because I'm afraid it might break gcc unwinding.
> Me> 
> Me>  There is indeed a problem, since quite some time, in testing/unstable,
> Me> with libc++ and libunwind-dev being incompatible with each other.
> [...]
> Me>  I keep hoping that sooner or later this problem will get resolved
> 
>  Hello,
> 
>  I think there is not going to be any other resolution and the old (HP)
> libunwind-dev will just be removed and replaced with the newer (LLVM)
> libunwind-NN-dev, which seems to supersede it, but not in a perfectly
> backwards-compatible way.
> 
>  To be more precise, there are at least 2 incompatibilities, resulting in 2
> problems when building lmi with the LLVM libunwind:

[...snip patch...]

I'm doing something equivalent to your patch, but I've run into two
linker problems. The first is this:

clang++ -o skeleton.so -shared about_dialog.o alert_wx.o census_document.o 
census_view.o database_document.o database_view.o database_view_editor.o 
default_view.o docmanager_ex.o file_command_wx.o gpt_document.o gpt_view.o 
group_quote_pdf_gen_wx.o icon_monger.o illustration_document.o 
illustration_view.o input_sequence_entry.o main_common.o mec_document.o 
mec_view.o msw_workarounds.o multidimgrid_any.o multidimgrid_tools.o 
mvc_controller.o mvc_view.o pdf_command_wx.o pdf_writer_wx.o policy_document.o 
policy_view.o preferences_view.o previewframe_ex.o product_editor.o 
progress_meter_wx.o rounding_document.o rounding_view.o rounding_view_editor.o 
single_choice_popup_menu.o skeleton.o system_command_wx.o text_doc.o 
text_view.o tier_document.o tier_view.o tier_view_editor.o transferor.o 
view_ex.o wx_checks.o wx_table_generator.o wx_utility.o liblmi.so wx_new.so 
-fuse-ld=lld -stdlib=libc++ -Wl,-Map,skeleton.so.map -ggdb  -fPIC -L . -L 
/opt/lmi/local/clang_x86_64-pc-linux-gnu/lib -L 
/opt/lmi/local/clang_x86_64-pc-linux-gnu/bin -lwxcode_gtk3u_pdfdoc-3.2  -L 
/opt/lmi/local/gcc_x86_64-pc-linux-gnu/lib  -lwx_gtk3u-3.2   
-L/opt/lmi/local/gcc_x86_64-pc-linux-gnu/lib -lxsltwrapp 
-L/opt/lmi/local/gcc_x86_64-pc-linux-gnu/lib -lexslt -lxslt -lxml2 
-L/opt/lmi/local/gcc_x86_64-pc-linux-gnu/lib -lxslt -lxml2 -lxmlwrapp 
-L/opt/lmi/local/gcc_x86_64-pc-linux-gnu/lib -lxml2 -lexslt 
-L/opt/lmi/local/gcc_x86_64-pc-linux-gnu/lib -lxslt -lxml2 -lm 
-L/opt/lmi/local/gcc_x86_64-pc-linux-gnu/lib -lxml2 -lm  -ldw -lunwind -ldl  
-Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -Wl,-z,separate-code  
ld.lld: error: liblmi.so: undefined reference to xml::error_messages::print() 
const [--no-allow-shlib-undefined]
ld.lld: error: liblmi.so: undefined reference to 
xml::document::save_to_string(std::__1::basic_string<char, 
std::__1::char_traits<char>, std::__1::allocator<char> >&, xml::error_handler&) 
const [--no-allow-shlib-undefined]
ld.lld: error: liblmi.so: undefined reference to 
xml::operator<<(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, 
xml::document const&) [--no-allow-shlib-undefined]

which I can "solve" with '-Wl,--allow-shlib-undefined', although I'd
like to know if there's a better way.

The second, which persists even with '-Wl,--allow-shlib-undefined',
and even if I specify '-stdlib=libc++' after '-lwx_gtk3u-3.2', is:

clang++ -o wx_test main_wx_test.o wx_test_about_version.o 
wx_test_benchmark_census.o wx_test_calculation_summary.o 
wx_test_config_settings.o wx_test_create_open.o wx_test_default_input.o 
wx_test_default_update.o wx_test_expiry_dates.o wx_test_input_sequences.o 
wx_test_input_validation.o wx_test_log_errors.o wx_test_paste_census.o 
wx_test_pdf_create.o wx_test_validate_output.o skeleton.so liblmi.so 
-fuse-ld=lld -Wl,-Map,wx_test.map -ggdb  -fPIC -L . -L 
/opt/lmi/local/clang_x86_64-pc-linux-gnu/lib -L 
/opt/lmi/local/clang_x86_64-pc-linux-gnu/bin  -L 
/opt/lmi/local/gcc_x86_64-pc-linux-gnu/lib  -lwx_gtk3u-3.2   -ldw -lunwind -ldl 
-stdlib=libc++ -Wl,--allow-shlib-undefined  -Wl,-z,relro -Wl,-z,now 
-Wl,-z,noexecstack -Wl,-z,separate-code  
make[1]: Nothing to be done for 'check_physical_closure'.
ld.lld: error: undefined symbol: operator<<(std::__1::basic_ostream<char, 
std::__1::char_traits<char> >&, wxString const&)
>>> referenced by wx_test_about_version.cpp:181 
>>> (/opt/lmi/src/lmi/wx_test_about_version.cpp:181)
>>>               
>>> wx_test_about_version.o:(wx_test_case_about_dialog_version::run()::expect_about_dialog::OnInvoked(wxDialog*)
>>>  const)
>>> referenced by wx_test_about_version.cpp:185 
>>> (/opt/lmi/src/lmi/wx_test_about_version.cpp:185)
>>>               
>>> wx_test_about_version.o:(wx_test_case_about_dialog_version::run()::expect_about_dialog::OnInvoked(wxDialog*)
>>>  const)
>>> referenced by wx_test_benchmark_census.cpp:86 
>>> (/opt/lmi/src/lmi/wx_test_benchmark_census.cpp:86)
>>>               wx_test_benchmark_census.o:((anonymous 
>>> namespace)::census_benchmark::time_operation(char const*, char, int))
>>> referenced 15 more times

Am I supposed to define my own ostream inserter for wxString?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]