Created attachment 180500 [details] libsearpc.diff This patch is to move libsearpc to PYTHONPATH instead of residing in the seafile directory. This was overlooked when moving the client seafile ports which require it for the cli. * Moved python code to PYTHONPATH portlint -AC: WARN: Makefile: Consider adding support for a NLS knob to conditionally disable gettext support. WARN: Makefile: for new port, make $FreeBSD$ tag in comment section empty, to make SVN happy. WARN: Makefile: new ports should not set PORTREVISION. WARN: /usr/local/poudriere/ports/test/devel/libsearpc/distinfo: [1]: TIMESTAMP is over 30 days old 0 fatal errors and 4 warnings found. poudriere bulk -tC: 12amd64: success https://poudriere.ultimasbox.com/data/12amd64-test/2017-03-04_11h28m57s/logs/libsearpc-3.1.0_1.log 12i386: success https://poudriere.ultimasbox.com/data/12i386-test/2017-03-04_11h28m58s/logs/libsearpc-3.1.0_1.log 110amd64: success https://poudriere.ultimasbox.com/data/110amd64-test/2017-03-04_11h28m55s/logs/libsearpc-3.1.0_1.log 110i386: success https://poudriere.ultimasbox.com/data/110i386-test/2017-03-04_11h28m56s/logs/libsearpc-3.1.0_1.log 103amd64: success https://poudriere.ultimasbox.com/data/103amd64-test/2017-03-04_11h28m52s/logs/libsearpc-3.1.0_1.log 103i386: success https://poudriere.ultimasbox.com/data/103i386-test/2017-03-04_11h28m53s/logs/libsearpc-3.1.0_1.log
Hi! Can you take a look at and address SONAME warning? ====> Running Q/A tests (stage-qa) Warning: /usr/home/lifanov/src/svn/freebsd/ports/head/devel/libsearpc/work/stage/usr/local/lib/libsearpc.so.1.0.2 doesn't have a SONAME. Warning: pkg(8) will not register it as being provided by the port. Warning: If another port depend on it, pkg will not be able to know where it comes from. Warning: It is directly in /usr/local/lib, it is probably used by other ports.
(In reply to Nikolai Lifanov from comment #1) Odd I don't know why those warning is showing. The logs I provided aren't showing them. What exactly does it mean? XD
The test checks for SONAME in a produced library using "readelf -d". You can compare this library (no SONAME): Dynamic section at offset 0xb028 contains 26 entries: Tag Type Name/Value 0x0000000000000001 NEEDED Shared library: [libgobject-2.0.so.0] 0x0000000000000001 NEEDED Shared library: [libglib-2.0.so.0] 0x0000000000000001 NEEDED Shared library: [libintl.so.8] 0x0000000000000001 NEEDED Shared library: [libjansson.so.4] 0x0000000000000001 NEEDED Shared library: [libthr.so.3] 0x0000000000000001 NEEDED Shared library: [libc.so.7] 0x0000000000000007 RELA 0x3258 0x0000000000000008 RELASZ 168 (bytes) 0x0000000000000009 RELAENT 24 (bytes) 0x000000006ffffff9 RELACOUNT 2 0x0000000000000017 JMPREL 0x3300 0x0000000000000002 PLTRELSZ 2952 (bytes) 0x0000000000000003 PLTGOT 0xa018 0x0000000000000014 PLTREL RELA 0x0000000000000006 SYMTAB 0xa20 0x000000000000000b SYMENT 24 (bytes) 0x0000000000000005 STRTAB 0x2638 0x000000000000000a STRSZ 3102 (bytes) 0x000000006ffffef5 GNU_HASH 0x1b58 0x0000000000000004 HASH 0x20f8 0x000000000000000c INIT 0x8e18 0x000000000000000d FINI 0x8e2c 0x000000006ffffff0 VERSYM 0x19c8 0x000000006ffffffe VERNEED 0x1b18 0x000000006fffffff VERNEEDNUM 2 0x0000000000000000 NULL 0x0 To a working one: Dynamic section at offset 0x23930 contains 22 entries: Tag Type Name/Value 0x0000000000000001 NEEDED Shared library: [libc.so.7] 0x000000000000000e SONAME Library soname: [libnghttp2.so.14] 0x000000000000000c INIT 0x4d70 0x000000000000000d FINI 0x18fe8 0x0000000000000004 HASH 0x158 0x000000006ffffef5 GNU_HASH 0x610 0x0000000000000005 STRTAB 0x1ac8 0x0000000000000006 SYMTAB 0xb08 0x000000000000000a STRSZ 5346 (bytes) 0x000000000000000b SYMENT 24 (bytes) 0x0000000000000003 PLTGOT 0x223af8 0x0000000000000002 PLTRELSZ 744 (bytes) 0x0000000000000014 PLTREL RELA 0x0000000000000017 JMPREL 0x4a88 0x0000000000000007 RELA 0x3120 0x0000000000000008 RELASZ 6504 (bytes) 0x0000000000000009 RELAENT 24 (bytes) 0x000000006ffffffe VERNEED 0x3100 0x000000006fffffff VERNEEDNUM 1 0x000000006ffffff0 VERSYM 0x2faa 0x000000006ffffff9 RELACOUNT 268 0x0000000000000000 NULL 0x0 The SONAME section is necessary for "pkg" to register a dependency and also it's typically necessary for stuff to actually link to a library. Also, the *old* libsearpc does include a SONAME section: 0x000000000000000e SONAME Library soname: [libsearpc.so.1]
Hold on. I'm using LLD. Let me eliminate this variable real quick...
OK, it's LLD vs BFD difference. LLD doesn't link it correctly. Committing...
A commit references this bug: Author: lifanov Date: Mon Mar 6 18:30:11 UTC 2017 New revision: 435563 URL: https://svnweb.freebsd.org/changeset/ports/435563 Log: devel/libsearpc - move python to PYTHONPATH This patch is to move libsearpc to PYTHONPATH instead of residing in the seafile directory. This was overlooked when moving the client seafile ports which require it for the cli. PR: 217539 Submitted by: ultima1252@gmail.com Changes: head/devel/libsearpc/Makefile head/devel/libsearpc/pkg-plist
Committed, thanks!
TL;DR: LLD is young and has bugs GNU binutils comes with two linkers: BFD (the one you think of when you think /usr/bin/ld) and optionally Gold. The BFD one was around for a while and is called that because it uses libbfd. Since GNU toolchain was relicensed to GPLv3 some time 2007-ish, FreeBSD couldn't move forward with updating the toolchain to the latest upstream version and was stuck on GCC 4.2.1 and binutils 2.17.50. This worked for a while, since FreeBSD could still obtain patches for it from OpenBSD, OS X, and Android (which also couldn't switch) and just asking upstream developers nicely to release a specific change under GPLv2. This is not sustainable long-term since support for new toolchain features (like LTO) and architectures (like AArch64) could not be implemented. Meanwhile, in GCC world, LLVM came along as a proposed middle-end to GCC at the time when GCC needed one and before GPLv2 -> GPLv3 transition. There was a desire to protect intermediate representation of the compiler from proprietary tools, so it had to be obfuscated before GPLv3 and LLVM was not accepted. Meanwhile, LLVM grew a set of tools to work on the bitcode, including an experimental C language frontend (Clang). Since then, FreeBSD (among others) was trying to migrate to LLVM-based toolchain in order to move forward. The Tier 1 architectures are already using Clang by default for "cc". There is an ELF Tool Chain project, which started in FreeBSD but moved externally to attract more contributors, which aims to create permissive replacements for the rest of tools provided by GNU binutils. The most complex component of this is the linker, which never reached a usable status. Meanwhile, LLVM project started working on a linker, called LLD. FreeBSD (emaste, others) have been trying to integrate it as the default system linker for FreeBSD. When LLVM 4.0 was merged in HEAD, LLD linker was suitable to compile kernel and world on amd64 and aarch64, so it's installed by default as "ld.lld" with "ld" being a symlink to either "ld.bfd" or "ld.lld" if a build-time variable WITH_LLD_IS_LD is set during buildworld. https://lld.llvm.org/ https://bugs.llvm.org/show_bug.cgi?id=23214 https://docs.google.com/document/d/1GcTY7kDKmvSYFAkJdUjLbHwoMHZlpbGG49wdWuaEnrg https://wiki.freebsd.org/GPLinBase