Bug 217539 - devel/libsearpc: Move python to PYTHONPATH
Summary: devel/libsearpc: Move python to PYTHONPATH
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Nikolai Lifanov
Keywords: easy, patch-ready
Depends on:
Reported: 2017-03-04 16:54 UTC by Ultima
Modified: 2017-03-07 17:23 UTC (History)
2 users (show)

See Also:

libsearpc.diff (2.53 KB, patch)
2017-03-04 16:54 UTC, Ultima
Ultima1252: maintainer-approval+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ultima 2017-03-04 16:54:09 UTC
Created attachment 180500 [details]

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
Comment 1 Nikolai Lifanov freebsd_committer 2017-03-04 17:48:24 UTC

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.
Comment 2 Ultima 2017-03-04 17:57:39 UTC
(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
Comment 3 Nikolai Lifanov freebsd_committer 2017-03-06 16:39:05 UTC
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]
Comment 4 Nikolai Lifanov freebsd_committer 2017-03-06 16:42:17 UTC
Hold on. I'm using LLD. Let me eliminate this variable real quick...
Comment 5 Nikolai Lifanov freebsd_committer 2017-03-06 18:27:38 UTC
OK, it's LLD vs BFD difference. LLD doesn't link it correctly.
Comment 6 commit-hook freebsd_committer 2017-03-06 18:31:06 UTC
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

  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

Comment 7 Nikolai Lifanov freebsd_committer 2017-03-06 18:31:27 UTC
Committed, thanks!
Comment 8 Nikolai Lifanov freebsd_committer 2017-03-07 17:23:47 UTC
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.