FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ games/searchandrescue-data | 1.3.0 | 1.7.0 +-+ multimedia/libbluray| 1.0.2 | 1.1.1 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Thanks. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
portupgrade + FLAVORS
For any portupgrade users still out there wishing for FLAVOR support,
I have patches to add it. I've been running them here locally for a
few weeks without incident (apart from an extra upgrade or two
actually working without manual intervention/resort to portmaster,
that is). Dropping the attached patch into
$PORTS/ports-mgmt/portupgrade/files/patch-flavors and rebuilding it is
a simple shortcut to getting it in place.
I haven't done any testing of using portupgrade with pre-built
packages (is there even any reason to post-pkg?), or using portinstall
(never saw the point), but it seems to handle the upgrading path just
fine.
Also sitting in a PR upstream at
https://github.com/freebsd/portupgrade/pull/72
--
Matthew Fuller (MF4839) | fulle...@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
--- bin/portupgrade.orig2018-03-09 18:59:29 UTC
+++ bin/portupgrade
@@ -1147,6 +1147,11 @@ def get_make_args(origin, pkgname = nil)
else
args = $make_args.split(' ')
end
+
+ if flavor = origin[/@(.+)$/, 1]
+args << 'FLAVOR=' + flavor
+ end
+
quoted = 0
n = 0
is_quoted = false
--- lib/pkgtools/pkgdb.rb.orig 2018-03-09 18:59:29 UTC
+++ lib/pkgtools/pkgdb.rb
@@ -425,10 +425,20 @@ class PkgDB
@installed_pkgs = []
@installed_ports = []
@db = {}
+
+ flavors = {}
+ pkg_flavors = xbackquote(PkgDB::command(:pkg), 'annotate', '-Sa',
+ 'flavor').split("\n")
+ pkg_flavors.each do |line|
+pkg, flavor = line.sub(/: Tag: flavor Value: /, ':').split(':')
+flavors[pkg] = flavor
+ end
+
pkg_origins = xbackquote(PkgDB::command(:pkg), 'query', '%n-%v
%o').split("\n")
pkg_origins.each do |line|
pkg, origin = line.split(' ')
@installed_pkgs << pkg
+origin << '@' + flavors[pkg] if flavors[pkg]
add_origin(pkg, origin)
end
@installed_pkgs.freeze
--- lib/pkgtools/portsdb.rb.orig2018-03-09 18:59:29 UTC
+++ lib/pkgtools/portsdb.rb
@@ -325,6 +325,7 @@ class PortsDB
end
def portdir(port)
+port = port.sub(/@.*$/, '')
File.join(ports_dir, port)
end
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
libgcc_s.so.1, Fortran, and the world (was: FreeCAD 0.17 && /lib//libgcc_s.so.1)
Hmm, I received zero feedback on this proposal, when it appeared
important for a number of users.
What's your take, Andreas, Tijl (your patch essentially with a bit
of an updated description), and toolchain?
Gerald
On Wed, 27 Feb 2019, Gerald Pfeifer wrote:
> Hi Tijl, hi everyone,
>
> and let me add Andreas who has been helping on the GCC side (both
> ports, viz. his work on arm and powerpc, and upstream) and toolchain@!
:
> On Sun, 24 Feb 2019, Tijl Coosemans wrote:
>> GCC_4.3.0 instead of GCC_3.3.0. The gcc commit that changed this
>> doesn't explain why this was done, but we'll have to make the same
>> change in FreeBSD ARM libgcc_s to be ABI compatible (since _Unwind* is
>> part of the ABI). This isn't a blocker for the patch.
>>
>> I emailed the patch to gerald on 2017-02-21. He responded in the usual
>> way that he prefers patches submitted upstream and because I thought the
>> patch would not be accepted upstream he proposed an alternative solution
>> where gcc would always add -rpath on FreeBSD so you didn't have to
>> specify it on the command line. I responded this wouldn't fix the case
>> where clang was used as a linker (e.g. to combine fortran and c++ code
>> in one program) and that the FAQ on the gcc website said it was a bad
>> idea for other reasons. I also said upstream might accept my patch if
>> it was a configure option but that the gcc configure scripts are
>> complicated and I didn't know where to add it exactly. Then silence.
>
> To move this forward, let me include an updated version of the patch
> Tijl shared on 2017-02-21 (which still was in my inbox/todo list) for
> consideration for our ports collection, initially for lang/gcc8 given
> that this is the default in the ports collection.
>
>
> (The lang/gcc* ports actually do carry local patches, e.g. for arm or
> powerpc or -fuse-ld=lld, but you are right that I usually try to get
> things upstream first, fixing things upstream myself when I can, or
> asking for help. The problem in this specific case was/is that I'm
> quite not enough into this area so cannot really assess and clearly
> stalling over that was not good.)
>
>
> Find patch-gfortran-libgcc attached which should simply plug into
> lang/gcc8/files and lang/gcc8-devel/files.
>
> Feedback very welcome!
>
> GeraldGCC has two runtime libraries: The static library libgcc.a (-lgcc) and
the shared library libgcc_s.so (-lgcc_s). Both implement many of the
same functions but they also each have their unique functions. When
gcc links programs and libraries there are three possibilities:
1. gcc -static-libgcc or gcc -static: -lgcc
=> Just use libgcc.a.
2. gcc -shared-libgcc: -lgcc_s -lgcc
=> Link with libgcc_s first, so libgcc.a is only used for its unique
functions.
3. gcc: -lgcc -Wl,--as-needed -lgcc_s -Wl,--no-as-needed
=> Link with libgcc.a first so libgcc_s is only used for its unique
functions (_Unwind_* functions).
Approach 3 is the default for gcc and it's also what clang and clang++ use;
approach 2 is the default for gfortran, g++ and probably other front ends.
This patch make 3 the default for gfortran. It significantly reduces
the use of libgcc_s. The _Unwind_* functions are also available in the
old base system libgcc_s which means this reduces the need for
-rpath /usr/local/lib/gccN in ports that depend on libraries built with
gfortran. Consider a dependency tree like this:
prog -> libA -> libgcc_s (old base system libgcc_s is fine)
-> libB -> libgcc_s (libB built with gfortran, needs new libgcc_s)
Here prog needs to be linked with -rpath /usr/local/lib/gccN even if it's
a normal C program compiled with clang. Without -rpath it will fail to
start because it loads old libgcc_s first as a dependency of libA and then
it fails to load libB. With this patch libB works with old base system
libgcc_s or may not need libgcc_s at all, so prog does not need to be
linked with -rpath.
Upstream is unlikely accept a patch like this because libgfortran calls
some _Unwind_* functions and so always needs libgcc_s. Also because
every Fortran program and library links to libgfortran it makes sense
that option 2 above is the default. On FreeBSD where clang and GCC
compiled code can be mixed and where multiple libgcc_s may be installed,
option 3 is just a lot easier to deal with.
The bug that sparked this is PR 208120 (but note there's a lot of
misleading information in that bug. CMake is not actually doing
anything wrong.)
--- UTC
--- gcc/fortran/gfortranspec.c.orig 2015-06-26 17:47:23 UTC
+++ gcc/fortran/gfortranspec.c
@@ -404,7 +404,7 @@ For more information about these matters
}
}
-#ifdef ENABLE_SHARED_LIBGCC
+#if 0
if (library)
{
unsigned int i;
--- libgfortran/Makefile.in.orig2019-02-22 14:22:13.0 +
+++ libgfortran/Makefile.in 2019-02-27 16:27:08.856408000 +
@@ -625,7 +625,7 @@
$(LTLDFLAGS) $(LIBQUADLIB) ../libbacktrace/libbacktrace.la
Re: portupgrade + FLAVORS
On Sun, 7 Apr 2019, the wise Matthew D. Fuller wrote: For any portupgrade users still out there wishing for FLAVOR support, I have patches to add it. I've been running them here locally for a few weeks without incident (apart from an extra upgrade or two actually working without manual intervention/resort to portmaster, that is). Dropping the attached patch into $PORTS/ports-mgmt/portupgrade/files/patch-flavors and rebuilding it is a simple shortcut to getting it in place. I haven't done any testing of using portupgrade with pre-built packages (is there even any reason to post-pkg?), or using portinstall (never saw the point), but it seems to handle the upgrading path just fine. Also sitting in a PR upstream at https://github.com/freebsd/portupgrade/pull/72 Thanks! Portupgrade is still my favorite so I'll definitely try the patch. Any reason why not just submit it in Bugzilla? Regards, Marco -- President Thieu says he'll quit if he doesn't get more than 50% of the vote. In a democracy, that's not called quitting. -- The Washington Post ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: libgcc_s.so.1, Fortran, and the world (was: FreeCAD 0.17 && /lib//libgcc_s.so.1)
On 2019-Apr-7, at 22:16, Gerald Pfeifer wrote: > Hmm, I received zero feedback on this proposal, when it appeared > important for a number of users. > > What's your take, Andreas, Tijl (your patch essentially with a bit > of an updated description), and toolchain? > > Gerald > > On Wed, 27 Feb 2019, Gerald Pfeifer wrote: >> Hi Tijl, hi everyone, >> >> and let me add Andreas who has been helping on the GCC side (both >> ports, viz. his work on arm and powerpc, and upstream) and toolchain@! > : >> On Sun, 24 Feb 2019, Tijl Coosemans wrote: >>> GCC_4.3.0 instead of GCC_3.3.0. The gcc commit that changed this >>> doesn't explain why this was done, but we'll have to make the same >>> change in FreeBSD ARM libgcc_s to be ABI compatible (since _Unwind* is >>> part of the ABI). This isn't a blocker for the patch. >>> >>> I emailed the patch to gerald on 2017-02-21. He responded in the usual >>> way that he prefers patches submitted upstream and because I thought the >>> patch would not be accepted upstream he proposed an alternative solution >>> where gcc would always add -rpath on FreeBSD so you didn't have to >>> specify it on the command line. I responded this wouldn't fix the case >>> where clang was used as a linker (e.g. to combine fortran and c++ code >>> in one program) and that the FAQ on the gcc website said it was a bad >>> idea for other reasons. I also said upstream might accept my patch if >>> it was a configure option but that the gcc configure scripts are >>> complicated and I didn't know where to add it exactly. Then silence. >> >> To move this forward, let me include an updated version of the patch >> Tijl shared on 2017-02-21 (which still was in my inbox/todo list) for >> consideration for our ports collection, initially for lang/gcc8 given >> that this is the default in the ports collection. >> >> >> (The lang/gcc* ports actually do carry local patches, e.g. for arm or >> powerpc or -fuse-ld=lld, but you are right that I usually try to get >> things upstream first, fixing things upstream myself when I can, or >> asking for help. The problem in this specific case was/is that I'm >> quite not enough into this area so cannot really assess and clearly >> stalling over that was not good.) >> >> >> Find patch-gfortran-libgcc attached which should simply plug into >> lang/gcc8/files and lang/gcc8-devel/files. >> >> Feedback very welcome! >> > I'm not sure the following will be considered important for the above, but I'll note it in case. A problem of sorts for WITHOUT_LLVM_LIBUNWIND= contexts: For contexts using WITHOUT_LLVM_LIBUNWIND= that might not use gcc 4.2.1 , use of the system libgcc_s is problematical: the old libunwind code does not correctly (not completely) implement DW_CFA_remember_state and DW_CFA_restore_state . It happens that g++ 4.2.1 (mostly?) avoids generating code that needs them. But modern clang++ and g++ do generate code frequently that needs DW_CFA_remember_state and DW_CFA_restore_state to work. Because I experiment with clang/clang++ and devel/powerpc64-gcc for buildworld buildkernel for powerpc64 (and powerpc), I use a patched libgcc_s when I try WITHOUT_LLVM_LIBUNWIND= . John Baldwin and others have expressed wanting to jump to WITH_LLLVM_LIBUNWIND= use (not with gcc 4.2.1), without fixing the old code first. Out of the mess described later: powerpc64 and powerpc are not yet ready for general, non-experimental WITH_LLVM_LIBUNWIND= use. I do not know the status of any potential blocking issues for switching for other architectures officially still using gcc/g++ 4.2.1 . powerpc64 and powerpc details: WITH_LLVM_LIBUNWIND= has https://reviews.llvm.org/D59694 by Leandro Lupori in process for powerpc64 ( for using WITHOUT_LIB32= ). It should allow use of WITH_LLVM_LIBUNWIND= WITHOUT_LIB32= . [As stands llvm's libunwind mungs up handling r2 (the powerpc64 TOC register).] https://reviews.llvm.org/D59694 is associated with https://bugs.llvm.org//show_bug.cgi?id=41050 . (That last has a messy comment history from my figuring out information as I went.) Handling thrown C++ exceptions need not be the only issue blocking system-clang use for one or both powerpc family branches. For 32-bit powerpc it is known to not be the only issue. powerpc64 via clang/clang++ ends up with a WITH_LIB32= issue from some of the 32-bit powerpc related issues. But even without that, clang/clang++ for buildworld does not support the implicit Dwarf-like EH generation that the old code requires for its use of __builtin_eh_return . This leads to any thrown c++ exdpetion crashing the program invovled. There is https://bugs.llvm.org//show_bug.cgi?id=26844 for this issue. (It has been around a while.) devel/powerpc644-gcc does the right thing for this when used for buildworld --but has its own issues that make WITH_LIB32= still useless last I checked. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
