Bug 1279966
Summary: | pkgconfig/-specs=/usr/lib/rpm/redhat/redhat-hardened-ld doesn't work on clang | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Dr. David Alan Gilbert <dgilbert> |
Component: | libssh2 | Assignee: | Paul Howarth <paul> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 23 | CC: | djuran, kdudka, paul |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | libssh2-1.6.0-3.fc23 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2015-11-15 00:23:00 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Dr. David Alan Gilbert
2015-11-10 15:38:03 UTC
Related Fesco ticket (the cause of this bug): https://fedorahosted.org/fesco/ticket/1384 I think it's safe to patch the libssh2.spec.in file to remove the libdir and LDFLAGS references as the libdir reference is to a standard library directory in Fedora (/usr/lib{64)), and the LDFLAGS bit pulls in flags for the libssh2 build (-specs=...) itself that aren't necessarily wanted by downstream users of the library, which can decide for themselves whether to be hardened or not (see also Bug #1204646). Any comments Kamil? Indeed. Dropping @LDFLAGS@ from libssh2.pc.in sounds like a good idea! I am not sure about -L${libdir} though. Output of the following command tells me it is pretty common among other packages in Fedora: grep libdir /usr/lib64/pkgconfig/*.pc I think -L${libdir} is common because it's useful from an upstream perspective where users might want to install the library in a non-system path, and hence it gets generated by default in most projects. However, in Fedora, where we're installing into the system library path, it's just (harmless) noise. Yes, it will have no effect in most of the cases. The question is whether there is any reason to diverge from upstream in this. @LDFLAGS@ could be removed from libssh2.pc.in also in upstream libssh2. I see a similar commit in libcurl six years ago: https://github.com/bagder/curl/commit/4c8adc8f libssh2-1.6.0-3.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-5c08769475 libssh2-1.6.0-3.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'dnf --enablerepo=updates-testing update libssh2' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-5c08769475 libssh2-1.6.0-3.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report. Paul, are you going to send the patch upstream? I believe it would be useful for upstream libssh2, too. (In reply to Kamil Dudka from comment #9) > Paul, are you going to send the patch upstream? I believe it would be > useful for upstream libssh2, too. I was going to do this but it slipped my mind. Thanks for following up. No problem. Thank you for getting it fixed! Upstream commit: https://github.com/libssh2/libssh2/commit/9bf32da6 |