Re: Linking problem with ncurses on rawhide, not f37
* Miroslav Lichvar: > On Mon, Jan 02, 2023 at 06:07:25PM +0100, Florian Weimer wrote: >> * Miroslav Lichvar: >> > /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to >> > `wmove@NCURSES6_5.0.19991023' >> > /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to >> > `derwin@NCURSES6_5.0.19991023' >> > /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to >> > `wenclose@NCURSES6_5.0.19991023' >> > /usr/bin/ld: /usr/lib64/libpanel.so.6: undefined reference to >> > `_nc_panelhook_sp@NCURSES6_5.8.20110226' >> > /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to >> > `wcursyncup@NCURSES6_5.0.19991023' >> > /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to >> > `copywin@NCURSES6_5.0.19991023' >> > /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to >> > `newpad@NCURSES6_5.0.19991023' >> > /usr/bin/ld: /usr/lib64/libpanel.so.6: undefined reference to >> > `wnoutrefresh@NCURSES6_5.0.19991023' >> > ... >> > >> > libform and libpanel depend on libncurses. >> >> Could you give them a similar treatment, with more linker scripts? > > It doesn't work if I add AS_NEEDED(libpanel libform) to libncurses. It > works if I add it to libtinfo. I guess that comes from the order of > NEEDED in liblldb.so.13git, which is included in the linker command. > > NEEDED libtinfo.so.6 > NEEDED libncurses.so.6 > NEEDED libform.so.6 > NEEDED libpanel.so.6 > > Would every ncurses library need to have all other libraries in > AS_NEEDED? Yeah, I think so. I was worried about that. Unfortunately, it doesn't seem to be possible to set -rpath-link from a linker script. > In any case, I don't like much the fact that with this approach it > would be possible to link ncurses/panel/form applications using just > -lncurses or -ltinfo. An application developed on Fedora might fail to > build on other systems. Yes, I think we need to wait until we have stub objects. They avoid this issue because they won't depend on anything. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Linking problem with ncurses on rawhide, not f37
On Mon, Jan 02, 2023 at 06:07:25PM +0100, Florian Weimer wrote: > * Miroslav Lichvar: > > /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to > > `wmove@NCURSES6_5.0.19991023' > > /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to > > `derwin@NCURSES6_5.0.19991023' > > /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to > > `wenclose@NCURSES6_5.0.19991023' > > /usr/bin/ld: /usr/lib64/libpanel.so.6: undefined reference to > > `_nc_panelhook_sp@NCURSES6_5.8.20110226' > > /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to > > `wcursyncup@NCURSES6_5.0.19991023' > > /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to > > `copywin@NCURSES6_5.0.19991023' > > /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to > > `newpad@NCURSES6_5.0.19991023' > > /usr/bin/ld: /usr/lib64/libpanel.so.6: undefined reference to > > `wnoutrefresh@NCURSES6_5.0.19991023' > > ... > > > > libform and libpanel depend on libncurses. > > Could you give them a similar treatment, with more linker scripts? It doesn't work if I add AS_NEEDED(libpanel libform) to libncurses. It works if I add it to libtinfo. I guess that comes from the order of NEEDED in liblldb.so.13git, which is included in the linker command. NEEDED libtinfo.so.6 NEEDED libncurses.so.6 NEEDED libform.so.6 NEEDED libpanel.so.6 Would every ncurses library need to have all other libraries in AS_NEEDED? In any case, I don't like much the fact that with this approach it would be possible to link ncurses/panel/form applications using just -lncurses or -ltinfo. An application developed on Fedora might fail to build on other systems. -- Miroslav Lichvar ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Linking problem with ncurses on rawhide, not f37
* Miroslav Lichvar: > On Fri, Dec 16, 2022 at 09:55:11AM +0100, Florian Weimer wrote: >> It may work to use this for libtinfo.so: >> >> GROUP (/usr/lib64/ncurses-novs/libtinfo.so.6 AS_NEEDED >> (/usr/lib64/ncurses-novs/libncurses.so.6)) > > FWIW, I tried this and the error messages from the swift-lang build > changed from: > > /usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to > `tparm@NCURSES6_TINFO_5.0.19991023' > /usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to > `_nc_safe_strcpy@NCURSES6_TINFO_5.2.20001021' > /usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to > `_nc_name_match@NCURSES6_TINFO_5.0.19991023' > /usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to > `wtimeout@NCURSES6_TINFO_5.0.19991023' > /usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to > `_nc_doalloc@NCURSES6_TINFO_5.0.19991023' > /usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to > `_nc_safe_strcat@NCURSES6_TINFO_5.2.20001021' > /usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to > `baudrate_sp@NCURSES6_TINFO_5.8.20110226' > /usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to > `_nc_update_screensize@NCURSES6_TINFO_5.0.19991023' > ... > > to > > /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to > `wmove@NCURSES6_5.0.19991023' > /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to > `derwin@NCURSES6_5.0.19991023' > /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to > `wenclose@NCURSES6_5.0.19991023' > /usr/bin/ld: /usr/lib64/libpanel.so.6: undefined reference to > `_nc_panelhook_sp@NCURSES6_5.8.20110226' > /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to > `wcursyncup@NCURSES6_5.0.19991023' > /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to > `copywin@NCURSES6_5.0.19991023' > /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to > `newpad@NCURSES6_5.0.19991023' > /usr/bin/ld: /usr/lib64/libpanel.so.6: undefined reference to > `wnoutrefresh@NCURSES6_5.0.19991023' > ... > > libform and libpanel depend on libncurses. Could you give them a similar treatment, with more linker scripts? Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Linking problem with ncurses on rawhide, not f37
On Fri, Dec 16, 2022 at 09:55:11AM +0100, Florian Weimer wrote: > It may work to use this for libtinfo.so: > > GROUP (/usr/lib64/ncurses-novs/libtinfo.so.6 AS_NEEDED > (/usr/lib64/ncurses-novs/libncurses.so.6)) FWIW, I tried this and the error messages from the swift-lang build changed from: /usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to `tparm@NCURSES6_TINFO_5.0.19991023' /usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to `_nc_safe_strcpy@NCURSES6_TINFO_5.2.20001021' /usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to `_nc_name_match@NCURSES6_TINFO_5.0.19991023' /usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to `wtimeout@NCURSES6_TINFO_5.0.19991023' /usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to `_nc_doalloc@NCURSES6_TINFO_5.0.19991023' /usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to `_nc_safe_strcat@NCURSES6_TINFO_5.2.20001021' /usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to `baudrate_sp@NCURSES6_TINFO_5.8.20110226' /usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to `_nc_update_screensize@NCURSES6_TINFO_5.0.19991023' ... to /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to `wmove@NCURSES6_5.0.19991023' /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to `derwin@NCURSES6_5.0.19991023' /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to `wenclose@NCURSES6_5.0.19991023' /usr/bin/ld: /usr/lib64/libpanel.so.6: undefined reference to `_nc_panelhook_sp@NCURSES6_5.8.20110226' /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to `wcursyncup@NCURSES6_5.0.19991023' /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to `copywin@NCURSES6_5.0.19991023' /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to `newpad@NCURSES6_5.0.19991023' /usr/bin/ld: /usr/lib64/libpanel.so.6: undefined reference to `wnoutrefresh@NCURSES6_5.0.19991023' ... libform and libpanel depend on libncurses. -- Miroslav Lichvar ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Linking problem with ncurses on rawhide, not f37
Thanks for doing that, Swift builds correctly on Rawhide now: https://koji.fedoraproject.org/koji/taskinfo?taskID=95546843 On 16 Dec 2022, at 5:24, Miroslav Lichvar wrote: > On Fri, Dec 16, 2022 at 09:55:11AM +0100, Florian Weimer wrote: >> Miroslav, we may have to revert the versioning change if the AS_NEEDED >> approach does not work. > > Ok, I reverted that change, at least until I have more time for > testing the possible fixes. > >> Linking versioned libncurses against >> unversioned libtinfo etc. would solve this, but I don't know how it >> would to get to this point. > > I don't know much about ELF. Is it possible to remove versions from > specific symbols in the symbol table after the libraries are built, > maybe with some tool like chrpath? > > -- > Miroslav Lichvar ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Linking problem with ncurses on rawhide, not f37
* Miroslav Lichvar: > On Fri, Dec 16, 2022 at 09:55:11AM +0100, Florian Weimer wrote: >> Linking versioned libncurses against >> unversioned libtinfo etc. would solve this, but I don't know how it >> would to get to this point. > > I don't know much about ELF. Is it possible to remove versions from > specific symbols in the symbol table after the libraries are built, > maybe with some tool like chrpath? It's an allocated section, and patching those is always a bit tricky. In this case, we'd remove data from it, so it might work. I'm still on the fence whether we should have some form of proper link editor support for that, or if it's too obscure to matter. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Linking problem with ncurses on rawhide, not f37
If you’re interested in testing any changes/fixes with Swift, you can use my Swift-for-Fedora repo (https://github.com/tachoknight/swift-lang-packaging-fedora). `setup-container.sh` does what you think it does in case you’re using podman or docker, and `justbuild.sh` actually does all the work to actually create the artifacts. Hope that helps! Ron On 16 Dec 2022, at 5:24, Miroslav Lichvar wrote: On Fri, Dec 16, 2022 at 09:55:11AM +0100, Florian Weimer wrote: Miroslav, we may have to revert the versioning change if the AS_NEEDED approach does not work. Ok, I reverted that change, at least until I have more time for testing the possible fixes. Linking versioned libncurses against unversioned libtinfo etc. would solve this, but I don't know how it would to get to this point. I don't know much about ELF. Is it possible to remove versions from specific symbols in the symbol table after the libraries are built, maybe with some tool like chrpath? -- Miroslav Lichvar___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Linking problem with ncurses on rawhide, not f37
On Fri, Dec 16, 2022 at 09:55:11AM +0100, Florian Weimer wrote: > Miroslav, we may have to revert the versioning change if the AS_NEEDED > approach does not work. Ok, I reverted that change, at least until I have more time for testing the possible fixes. > Linking versioned libncurses against > unversioned libtinfo etc. would solve this, but I don't know how it > would to get to this point. I don't know much about ELF. Is it possible to remove versions from specific symbols in the symbol table after the libraries are built, maybe with some tool like chrpath? -- Miroslav Lichvar ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Linking problem with ncurses on rawhide, not f37
* Ron Olson: > In Rawhide the ncurses libs are at 6.3-4.20221126, while f37 is > 6.3-3.20220501. I recall seeing some messages go by related to ncurses > on the list here regarding the -compat library, but I’m not sure if > that’s related to my issue. It seems weird that some of the functions > it’s unable to find are part of the library (e.g. wtimeout is a valid > function, according to the man pages). > > Could there be something weird with rawhide’s copy of ncurses or was > there some big update that removed all these functions? Recently, ncurses introduced symbol versioning at run time, but not at link time (bug 1875587). I missed that ncurses constitutes of multiple shared objects that depend on each other. What seems to happen here is that some other object in that link depends on libncurses, which results in linker using the versioned libncurses (the run-time version). The versioned libncurses depends on the versioned libtinfo because it uses versioned symbol references. But -ltinfo uses a linker script to link against the unversioned libtinfo, so that the application sticks to the Fedora ncurses ABI, and that is not suitable for resolving the symbol references in the versioned libncurses. It may work to use this for libtinfo.so: GROUP (/usr/lib64/ncurses-novs/libtinfo.so.6 AS_NEEDED (/usr/lib64/ncurses-novs/libncurses.so.6)) But the AS_NEEDED might come too late to have an effect, after the versioned libncurses has been loaded. It's also possible that the build system for this particular package has an explicit reference to /usr/lib64/libncurses.so.6 somewhere that we cannot easily get rid of from the outside. In the latter case, even a special directory for unversioned, link-time search objects, a directory that is injected into the build using -rpath-link (via the default linker flags in redhat-rpm-config) would fail to hide the versioned libncurses variant. Miroslav, we may have to revert the versioning change if the AS_NEEDED approach does not work. This is also not something that would have been solved by a stub generator. Linking versioned libncurses against unversioned libtinfo etc. would solve this, but I don't know how it would to get to this point. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Linking problem with ncurses on rawhide, not f37
On Thu, Dec 15, 2022 at 2:02 PM Ron Olson wrote: > Hey all- > > I got linking errors on rawhide that I did not get on F37 when building Swift > related to curses support > (https://kojipkgs.fedoraproject.org//work/tasks/7462/95367462/build.log), > like: > > /usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to > tparm@NCURSES6_TINFO_5.0.19991023' /usr/bin/ld: /usr/lib64/libncurses.so.6: > undefined reference to _nc_safe_strcpy@NCURSES6_TINFO_5.2.20001021' > /usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to > _nc_name_match@NCURSES6_TINFO_5.0.19991023' /usr/bin/ld: > /usr/lib64/libncurses.so.6: undefined reference to > wtimeout@NCURSES6_TINFO_5.0.19991023' > /usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to > `_nc_doalloc@NCURSES6_TINFO_5.0.19991023' > > In Rawhide the ncurses libs are at 6.3-4.20221126, while f37 is > 6.3-3.20220501. I recall seeing some messages go by related to ncurses on the > list here regarding the -compat library, but I’m not sure if that’s related > to my issue. It seems weird that some of the functions it’s unable to find > are part of the library (e.g. wtimeout is a valid function, according to the > man pages). > > Could there be something weird with rawhide’s copy of ncurses or was there > some big update that removed all these functions? > > Thanks! > > Ron I think the error message is misleading. Notice that there is no -lncurses in that link command. I think it is telling you that there are references to symbols in libncurses that haven't been resolved. Indeed, manually adding -lncurses to the link line dramatically shrinks the number of errors and makes it complain about libform and libpanel instead. Adding this: -lncurses -lform -lpanel just before -ltinfo results in a successful link. I don't know why you suddenly need to link against libncurses, libform, and libpanel when libtinfo was enough previously. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Linking problem with ncurses on rawhide, not f37
Hey all- I got linking errors on rawhide that I did not get on F37 when building Swift related to curses support (https://kojipkgs.fedoraproject.org//work/tasks/7462/95367462/build.log), like: /usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to `tparm@NCURSES6_TINFO_5.0.19991023' /usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to `_nc_safe_strcpy@NCURSES6_TINFO_5.2.20001021' /usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to `_nc_name_match@NCURSES6_TINFO_5.0.19991023' /usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to `wtimeout@NCURSES6_TINFO_5.0.19991023' /usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to `_nc_doalloc@NCURSES6_TINFO_5.0.19991023' In Rawhide the ncurses libs are at 6.3-4.20221126, while f37 is 6.3-3.20220501. I recall seeing some messages go by related to ncurses on the list here regarding the -compat library, but I’m not sure if that’s related to my issue. It seems weird that some of the functions it’s unable to find are part of the library (e.g. wtimeout is a valid function, according to the man pages). Could there be something weird with rawhide’s copy of ncurses or was there some big update that removed all these functions? Thanks! Ron___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
