questions about packaging libunicode for Fedora
topazus opened this issue · 26 comments
I did a trial to build libunicode from latest commit tag on Fedora, and install the built libunicode rpm package and the file conflicted with libicu-devel. Maybe install header files to another directory will solve it?
libunicode/src/unicode/CMakeLists.txt
Lines 119 to 134 in 5987666
[ruby@fedora x86_64]$ rpm -qlp ./libunicode-static-20230219.5987666-1.fc38.x86_64.rpm
/usr/include/unicode/capi.h
/usr/include/unicode/codepoint_properties.h
/usr/include/unicode/convert.h
/usr/include/unicode/emoji_segmenter.h
/usr/include/unicode/grapheme_segmenter.h
/usr/include/unicode/intrinsics.h
/usr/include/unicode/run_segmenter.h
/usr/include/unicode/scan.h
/usr/include/unicode/script_segmenter.h
/usr/include/unicode/ucd.h
/usr/include/unicode/ucd_enums.h
/usr/include/unicode/ucd_fmt.h
/usr/include/unicode/ucd_ostream.h
/usr/include/unicode/utf8.h
/usr/include/unicode/utf8_grapheme_segmenter.h
/usr/include/unicode/width.h
/usr/include/unicode/word_segmenter.h
/usr/lib64/cmake/libunicode/libunicode-config-version.cmake
/usr/lib64/cmake/libunicode/libunicode-config.cmake
/usr/lib64/cmake/libunicode/unicode-targets-noconfig.cmake
/usr/lib64/cmake/libunicode/unicode-targets.cmake
/usr/lib64/libunicode.a
/usr/lib64/libunicode_loader.a
/usr/lib64/libunicode_ucd.a
[ruby@fedora x86_64]$ sudo dnf in ./libunicode-static-20230219.5987666-1.fc38.x86_64.rpm ./libunicode-20230219.5987666-1.fc38.x86_64.rpm
Last metadata expiration check: 3:10:44 ago on Wed 22 Feb 2023 07:57:54 AM CST.
Dependencies resolved.
==============================================================================================================
Package Architecture Version Repository Size
==============================================================================================================
Installing:
libunicode x86_64 20230219.5987666-1.fc38 @commandline 1.1 M
libunicode-static x86_64 20230219.5987666-1.fc38 @commandline 506 k
Transaction Summary
==============================================================================================================
Install 2 Packages
Total size: 1.6 M
Installed size: 8.5 M
Is this ok [y/N]: y
Downloading Packages:
Running transaction check
Transaction check succeeded.
Running transaction test
Error: Transaction test error:
file /usr/include/unicode/utf8.h from install of libunicode-static-20230219.5987666-1.fc38.x86_64 conflicts with file from package libicu-devel-72.1-2.fc38.x86_64
Hey, oh yes. I will do that asap. Thanks. :)
Okay, so the include path is now prefixed with libunicode to not conflict with ICU devel headers.
I have built Contour always with libunicode being embedded. I'll make sure that out-of-tree built works for Contour too before I'm going to tag a new release of libunicode. :)
Alright. With the second PR here, we should be good to go on Contour. Almost, I'll need to make sure over there, that Contour can be successfully compiled with libunicode as system dep as well as embedded. I have some local tweaks that I need to generalize/cleanup a bit. I think we're done with this by tomorrow. I hope it wasn't too long exhausting, the wait, sorry for the delay. I was sick past days. :)
@christianparpart Take your time. Hope you are better now and take care. I have another question, which is we need to make the termbench-pro package as the compile dependency library of contour terminal?
termbench-pro is a library and binary (optionally) that is used simply for perf testing Contour's backend (as library) or any TE through its binary. I think it should be possible to build Contour without termbench-pro as a dependency. if not, i'll make it possible tonight.
Thanks for your clarifying. When you finish the progress and tag the new release of libunicode and contour, I will start the Fedora new package process for libunicode and contour.
@christianparpart It seemed that the official Fedora packaging guidelines tell us packagers should avoid the static library with the best possible, . The current default option with cmake for libunicode is to build static library *.a, which should provide the build shared library option. Tested packaging libunicode on my Fedora machine.
[ruby@fedora copr]$ rpm -qlp ~/rpmbuild/RPMS/x86_64/libunicode-devel-20230225.5987666-1.fc39.x86_64.rpm
/usr/include/libunicode
/usr/include/libunicode/capi.h
/usr/include/libunicode/codepoint_properties.h
/usr/include/libunicode/convert.h
/usr/include/libunicode/emoji_segmenter.h
/usr/include/libunicode/grapheme_segmenter.h
/usr/include/libunicode/intrinsics.h
/usr/include/libunicode/multistage_table_generator.h
/usr/include/libunicode/multistage_table_view.h
/usr/include/libunicode/run_segmenter.h
/usr/include/libunicode/scan.h
/usr/include/libunicode/scoped_timer.h
/usr/include/libunicode/script_segmenter.h
/usr/include/libunicode/support.h
/usr/include/libunicode/ucd.h
/usr/include/libunicode/ucd_enums.h
/usr/include/libunicode/ucd_fmt.h
/usr/include/libunicode/ucd_ostream.h
/usr/include/libunicode/utf8.h
/usr/include/libunicode/utf8_grapheme_segmenter.h
/usr/include/libunicode/width.h
/usr/include/libunicode/word_segmenter.h
/usr/lib64/cmake/libunicode
/usr/lib64/cmake/libunicode/libunicode-config-version.cmake
/usr/lib64/cmake/libunicode/libunicode-config.cmake
/usr/lib64/cmake/libunicode/unicode-targets-noconfig.cmake
/usr/lib64/cmake/libunicode/unicode-targets.cmake
/usr/lib64/libunicode.a
/usr/lib64/libunicode_loader.a
/usr/lib64/libunicode_ucd.a
ref:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#packaging-static-libraries
https://fedoraproject.org/wiki/C_and_C%2B%2B_v2#Static_Linking
I noticed that, I will be adding dynamic linking + static linking support in a moment. thanks for pushing me :)
@topazus One question. is it okay to build static plus dynamic version and have both installed in one go, or do you prefer it to be a cmake configure time option to decide whether or not to build it statically.
What do you think is best from a package maintainers point of view?
I prefer the dynamic library version, which conforms to the Fedora packaging guidelines.
I prefer the dynamic library version, which conforms to the Fedora packaging guidelines.
now builds dynamic version by default if build standalone and not on windows platform.
@topazus btw, libunicode comes with a very handy CLI tool, named unicode-query, will you ship this, too? That's basically a Unicode codepoint query tool like we have on the internet in form of websites already, except that this one works on the CLI completely offline. :)
Maybe there is another small fix needs to be addressed for libunicode. The shared library needs to set with cmake in order to generate the versioned lib files that put into the base lib package and unversioned files that go into -devel packages for Fedora packaging.
ref:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_devel_packages
https://docs.fedoraproject.org/en-US/packaging-guidelines/C_and_C++/#_libraries
https://cmake.org/cmake/help/latest/prop_tgt/SOVERSION.html, https://cmake.org/cmake/help/latest/command/set_target_properties.html
https://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
I think I will not package unicode-query into the final package, since the libunicode is a library.
I think I will not package unicode-query into the final package, since the libunicode is a library.
this makes absolutely sense. I meant more as a package on its own with the same name as the executable. With Deb at least it's possible to create multiple .deb files during a single build. I'm not a master in RPM though :)
The shared library needs to set with cmake in order to generate the versioned lib files that put into the base lib package and unversioned files that go into -devel packages for Fedora packaging.
Uff, trying to clearly undestand what I can do to "fix". 🤔
For the shared library versioning in cmake, it seemed that it can be got by setting the set_target_properties().
looking at google/re2/issues/304 will be helpful, commit: google/re2/13ebb377c6ad763ca61d12dd6f88b1126bd0b911
other c++ library also set this. https://github.com/jbeder/yaml-cpp/blob/1b50109f7bea60bd382d8ea7befce3d2bd67da5f/CMakeLists.txt#L144-L146
Okay, I'm doing it the way yaml-cpp is doing it, now.
this makes absolutely sense. I meant more as a package on its own with the same name as the executable. With Deb at least it's possible to create multiple .deb files during a single build. I'm not a master in RPM though :)
For RPM packaging in Fedora, it can also create multiple rpm subpackages. Seeing there are some binary files in /usr/bin for libpng-devel and libpng-tools package of libpng library in Fedora, we can also put unicode-query into -devel or -tools subpackage.
ref: https://src.fedoraproject.org/rpms/libpng/blob/rawhide/f/libpng.spec#_94
I think -tools suffix would make most sense then, because I have users actually appreciating that tool but they don't need the header files :)
@topazus is there anything on current master still not playing nice with Fedora packaging policies? Otherwise I'd tag a release in libunicode and would be about to prepare one for Contour as well.
Sorry for the late reply because I was very busy and distracted by lots of other stuff these days. I make an attempt to build libunicode on Fedora koji (Fedora RPM buildsystem), Here are the build results URL, succeeded in aarch64 and x86_64:
https://koji.fedoraproject.org/koji/taskinfo?taskID=98065639
the corresponding SPEC file for libunicode, which is used to build RPM: https://gist.githubusercontent.com/topazus/618132c7a61b816cbcb236a89cc545bc/raw/b265b6f81868696c19d6a7ff3ebc9b78b2c71cd3/libunicode.spec
so looks like I can move forward (tonight). many thanks :)
@christianparpart However, when I use the built libunicode RPM package to build contour, it showed error. detailed info:
contour-terminal/contour/issues/1054
[ 10%] Built target text_shaper
/usr/bin/ld: /tmp/ccEiUyrt.ltrans0.ltrans.o: warning: relocation against `_ZGVZN8logstore4Sink7consoleEvE8instance' in read-only section `.text.startup'
/usr/bin/ld: /tmp/ccEiUyrt.ltrans0.ltrans.o: relocation R_X86_64_PC32 against symbol `_ZTIZN8logstore4SinkC4EbRSoEUlSt17basic_string_viewIcSt11char_traitsIcEEE_' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
oh interesting. let me try to repro that (this evening).
Alright, sorry, not yet 100% back up I am. But I tried to look into this error message above now (I sadly can't use the your produced .rpm files yet, my Fedora isn't new enough :) ). Seems to me like a bug in GCC, tbh:
Looking at the source code of logstore::console(), it's a header-only library, and maybe GCC can't handle that (actually trivial code) in logstore.h, what I can try, is, to put the impl into a .cpp file. Let me try that, but since I'm not getting this error, I would sadly need you to confirm (or deny) if that worked. :)
I think we can close this one here now. Again, many thanks for your interest and especially the feedback you gave us. :-)