Re: might need to bump version of python ports after recent openssl changes

[Konstantin Belousov]

On Tue, May 26, 2020 at 11:31:32PM -0700, Kevin Oberman wrote:
> On Tue, May 26, 2020 at 11:09 PM Stefan Eßer  wrote:
> 
> > Am 27.05.20 um 04:24 schrieb Jan Beich:
> > > Pete Wright  writes:
> > >
> > >> hello - on current i found myself in a situation where python37 was
> > >> unable to import ssl:
> > >>
> > >> $ python3.7
> > >> Python 3.7.7 (default, May  9 2020, 01:37:42)
> > >> [Clang 10.0.0 (g...@github.com:llvm/llvm-project.git
> > >> llvmorg-10.0.0-0-gd32170dbd on freebsd13
> > >> Type "help", "copyright", "credits" or "license" for more information.
> > > import ssl
> > >> Traceback (most recent call last):
> > >>   File "", line 1, in 
> > >>   File "/usr/local/lib/python3.7/ssl.py", line 98, in 
> > >> import _ssl # if we can't import it, let the error
> > >> propagate
> > >> ImportError: /usr/local/lib/python3.7/lib-dynload/_ssl.so: Undefined
> > >> symbol "SSLv3_method@OPENSSL_1_1_0"
> > >
> > >>
> > >>
> > >> after a little digging it looks like we recently disabled SSLv3 on
> > >> CURRENT (huzzah!):
> > >> https://reviews.freebsd.org/D24945
> > >>
> > >> After forcing a re-install of python37 things are working again as it
> > >> looked like the pbuilder did rebuild python after this commit. But pkg
> > >> upgrade didn't detect a new version, so I think it might be helpful to
> > >> bump the python version's so that people on CURRENT don't end up in
> > >> the same situation I was in?  Not sure what the usual process is for
> > >> stuff like this...
> > >
> > > OSVERSION was already bumped in base r361410, so poudriere will
> > > force-rebuild all packages. Those who hack .jailversion to avoid
> > > rebuilds can only blame themselves.
> >
> > OSVERSION bumps will be observed by poudriere, but not by other port
> > building tools.
> >
> > Did I miss an announcement that all other methods to keep your system
> > in a workable state are now considered obsolete and unsupported?
> >
> > A port version bump would have enabled rebuilding just the affected
> > ports, while a rebuild of all my ports based on OSVERSION will take
> > days to complete on my local build server.
> 
> Even if the packages are updated in the repository, does pkg know it?
> It looks to me like pkg upgrade will simply not upgrade the port unless
> PORT_REVISION is bumped.
What this change needed, and missed, is the dso version bump for libssl.so.111.
___
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: Retiring GNU objdump 2.17.50

[Konstantin Belousov]

On Thu, Jan 09, 2020 at 10:31:55AM -0500, Ed Maste wrote:
> We currently install and use at most three tools from GNU binutils
> 2.17.50, depending on target architecture:
> 
> 1. as - assembler
> 2. ld - linker
> 3. objdump - diagnostic / information tool
> 
> I hope to retire all use of these obsolete binutils before FreeBSD 13.
> Here I'd like to discuss objdump. It is a diagnostic tool that
> provides information about object files, binaries and libraries. It's
> not required as a bootstrap tool (i.e., not needed to build FreeBSD
> world or kernel). It is required to build a limited number of ports,
> and is used by some developers.
> 
> I have a tracking PR for GNU objdump's retirement open in PR 229046.
> https://bugs.freebsd.org/229046.
> 
> There are two ways we can proceed with its retirement:
> 
> 1. Remove it without replacement. Ports that need objdump to build
> will have to depend on the binutils package/port, and users who wish
> to use it will have to install it.
> 
> Related links for this path:
> Ports exp-run: https://bugs.freebsd.org/212319
> Patch review: https://reviews.freebsd.org/D7338
> 
> 2. Install llvm-objdump in its place (perhaps via a symlink).
> llvm-objdump is broadly compatible in both command-line argument
> parsing and output format, but there are many small differences and
> it's not a full drop-in replacement.
> 
> Related links for this path:
> Patch review: https://reviews.freebsd.org/D18307
> 
> I am interested in feedback on the preferred approach. Installing
> llvm's objdump has the advantage that for most use cases everything
> will "just work", but may also introduce subtle failures.

IMO no. 1 is preferrable because we do not need to track differences, nor
we need to explain them.  Having to install binutils port is not a high cost,
and if somebody needs details about binary at the level provided by objdump,
including disassembler, she would need binutils port anyway.
___
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: Samba dump (useless) core

[Konstantin Belousov]

On Wed, May 08, 2019 at 12:03:34PM +0200, Andrea Venturoli wrote:
> Hello.
> 
> I've got a few servers where I run Samba 4.8 in a jail as an AD DC.
> 
> Lately, on a couple of them, it started dumping core: on one server, 
> apparently everything works fine after that; on another one I have 
> intermittent DNS issues, but I'm not sure they are related to this core.
> 
> I tried examining the core, but this is what I get:
> 
> > # gdb /usr/local/sbin/samba samba.core
> > GNU gdb 6.1.1 [FreeBSD]
> > Copyright 2004 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License, and you are
> > welcome to change it and/or distribute copies of it under certain 
> > conditions.
> > Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB.  Type "show warranty" for details.
> > This GDB was configured as "amd64-marcel-freebsd"...
> > Core was generated by `samba: conn[rpc] c[ipv4:192.168.xxx.4:31803] 
> > s[ipv4:192.168.134.3:49153] server_'.
> > Program terminated with signal 6, Aborted.
> > #0  0x000803e0d98a in ?? ()
> > (gdb) info thr
> > * 1 process 101460  0x000803e0d98a in ?? ()
> > (gdb) bt
> > #0  0x000803e0d98a in ?? ()
> > #1  0x000803e0d940 in ?? ()
> > #2  0xffdf in ?? ()
> > #3  0x in ?? ()
> > #4  0x in ?? ()
> > (gdb) 
> 
> The only relevant line, unfortunately is "Core was generated by...", but 
> it doesn't help much.
> 
> Samba is compiled (via Pudriere) with DEBUG, so I thought the above 
> would be more useful.
> 
> Any hint?
Signal 6 is SIGABRT, which means most likely that some assert was triggered.
You should look into your logs.  Also it is possible that DEBUG turns on
asserts.
___
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: Clang Import Breakage

[Konstantin Belousov]

On Sun, Mar 24, 2019 at 07:03:11AM +0100, Jan Beich wrote:
> Sean Bruno  writes:
> 
> > On 3/23/19 5:57 PM, Dimitry Andric wrote:
> >> This is fallout of ,
> >> which enabled --no-allow-shlib-undefined by default.  See also
> >> .  Executive summary: lots of programs
> >> do not specify all their required libraries, a.k.a. "under-linking".
> >> 
> >> I haven't yet reverted lld's new default, since it seems that a lot of
> >> under-linking fixes are now being made.  These problems will also occur
> >> when linking with gold, for instance, so it is quite useful to solve
> >> them once and for all.
> >> 
> >> -Dimitry
> >
> > Oh, hrm.  Ok.
> >
> > So, before the changes, my port succeeds in adding libogg to its LD list
> > when doing its link.
> 
> LLD before and BFD linker didn't complain that your port bootlegged
> libogg via libvorbis. For one, libvorbis may stop depending on libogg,
> may bundle libogg as a static library or import libogg symbols with
> LOCAL visibility.
But in this case, you get the breakage even with the ld.bfd, and if
you get over the static linking stage, with runtime linker as well.
This is exactly the issue that disabling of underlinking uncovers:
if you use a symbol provided by a library, the library must appear in
DT_NEEDED.

> 
> Ditto for libssl bootlegging libcrypto.
> ___
> 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"
___
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: FreeCAD 0.17 && /lib//libgcc_s.so.1

[Konstantin Belousov]

On Fri, Feb 22, 2019 at 10:27:30AM -0800, Steve Kargl wrote:
> Then the assertion that nothing in base needs libgcc_s.so is wrong?
> 
> And, yes, if an application is currently using /lib/libgcc_s.so,
> then it would need to be recompiled.  When it is recompiled, it
> can use libcompiler_rt or, if need be, it can use the libgcc_s.so
> provided by a gcc port.
This is the other name for 'breaking the ABI'.
___
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: FreeCAD 0.17 && /lib//libgcc_s.so.1

[Konstantin Belousov]

On Fri, Feb 22, 2019 at 05:09:59PM +0100, Tijl Coosemans wrote:
> On Fri, 22 Feb 2019 15:39:17 +0200 Konstantin Belousov
>  wrote:
> > Yes, we absolutely must avoid situation where two similar libraries
> > (i.e. providing some subset of symbols from other) are linked into the
> > same executing process.
> > 
> > I think your patches would be a definitive improvement, esp. the part
> > which makes libgfortran linking only as needed.
> > 
> > For the other part, which makes the ports dso a priority over the base
> > dso, I would exercise some more causion. For ports we know only about
> > libgcc_s.so.1 which has the same name in base and in ports, other
> > libraries in base should have libprivate suffix to not conflict, right ?
> > What about openssl libraries ?
> 
> As long as libraries have a different name the search order in the
> ldconfig cache doesn't matter.  So libfoo.so.x and libprivatefoo.so.x
> don't conflict but neither do libfoo.so.x and libfoo.so.y.  Some
> libraries in base have the libprivate prefix and they are not meant to
> be used by ports at all.  The openssl libraries in base have a different
> version suffix than security/openssl* and are allowed to be used by
> ports.
> 
> > I think such setup makes it easier for user to accidentaly break the system.
> > She could install something manually (not from ports), or copy some file
> > into /usr/local/lib, which conflicts with base and cause troubles.
> 
> Or they could copy something in /lib or /usr/lib and break their system.
> 
> The idea behind the ldconfig patch is that the runtime search order
> should be as close as possible to a typical compile time order.
> Typically compilers and linkers search /usr/local before /usr, so
> ldconfig should search /usr/local before /usr.  Anyone that wants a
> different order needs to provide a good explanation for that and I don't
> think protecting users from shooting themselves in the foot is a good
> enough reason.
> 
> Similarly, I think our default PATH is also backwards.  Major Linux
> distros and MacOS all put /usr/local/bin before /usr/bin.
> 
> # User can override sysadmin who can override OS:
> PATH=$HOME/bin:/usr/local/bin:/usr/bin:/bin
> 
> > Do you agree that the ultimate and proper solution is to add missed symbols
> > and versions to the base libgcc_s.so.1 ?  IMO it is, and this thread started
> > to show some work which might finally solve that.
> > (But about as-needed for libgfortran see above).
> 
> Not really no:
> 
> 1) GCC can add new symbols or new versions of them with every release
> which means the problem can reappear with every new GCC release and GCC
> releases aren't aligned with FreeBSD releases.
Right, this is known and accepted ABI changes.  We must cope with them
if we intend to run newer gcc and newer gcc' compiled binaries.

> 2) Base system libgcc is essentially libcompilerrt, the LLVM compiler
> runtime.  LLVM doesn't seem to need these symbols, nothing in base needs
> these symbols so why should we implement these third party compiler
> runtime helper functions?
Because we strive to provide a usable system, not locked to one compiler.
IMO we must support both gcc and clang and their compilation results,
each with some version variance, regardless of the compiler used for
the base system.

> 3) With my gfortran patch you don't need to implement anything.  It's an
> apply-once-and-stop-worrying-about-it solution for all versions of FreeBSD.
Because all missed symbols are resolved from the compiler's libgcc.a before
linker insert a reference to libgcc_s.so.1, or due to some other cause ?
___
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: FreeCAD 0.17 && /lib//libgcc_s.so.1

[Konstantin Belousov]

On Fri, Feb 22, 2019 at 08:44:54AM -0800, Steve Kargl wrote:
> On Fri, Feb 22, 2019 at 05:09:59PM +0100, Tijl Coosemans wrote:
> > On Fri, 22 Feb 2019 15:39:17 +0200 Konstantin Belousov
> >  wrote:
> > > Yes, we absolutely must avoid situation where two similar libraries
> > > (i.e. providing some subset of symbols from other) are linked into the
> > > same executing process.
> > > 
> > > I think your patches would be a definitive improvement, esp. the part
> > > which makes libgfortran linking only as needed.
> > > 
> > > For the other part, which makes the ports dso a priority over the base
> > > dso, I would exercise some more causion. For ports we know only about
> > > libgcc_s.so.1 which has the same name in base and in ports, other
> > > libraries in base should have libprivate suffix to not conflict, right ?
> > > What about openssl libraries ?
> > 
> > As long as libraries have a different name the search order in the
> > ldconfig cache doesn't matter.  So libfoo.so.x and libprivatefoo.so.x
> > don't conflict but neither do libfoo.so.x and libfoo.so.y.  Some
> > libraries in base have the libprivate prefix and they are not meant to
> > be used by ports at all.  The openssl libraries in base have a different
> > version suffix than security/openssl* and are allowed to be used by
> > ports.
> > 
> > > I think such setup makes it easier for user to accidentaly break the 
> > > system.
> > > She could install something manually (not from ports), or copy some file
> > > into /usr/local/lib, which conflicts with base and cause troubles.
> > 
> > Or they could copy something in /lib or /usr/lib and break their system.
> > 
> > The idea behind the ldconfig patch is that the runtime search order
> > should be as close as possible to a typical compile time order.
> > Typically compilers and linkers search /usr/local before /usr, so
> > ldconfig should search /usr/local before /usr.  Anyone that wants a
> > different order needs to provide a good explanation for that and I don't
> > think protecting users from shooting themselves in the foot is a good
> > enough reason.
> > 
> > Similarly, I think our default PATH is also backwards.  Major Linux
> > distros and MacOS all put /usr/local/bin before /usr/bin.
> > 
> > # User can override sysadmin who can override OS:
> > PATH=$HOME/bin:/usr/local/bin:/usr/bin:/bin
> > 
> > > Do you agree that the ultimate and proper solution is to add missed 
> > > symbols
> > > and versions to the base libgcc_s.so.1 ?  IMO it is, and this thread 
> > > started
> > > to show some work which might finally solve that.
> > > (But about as-needed for libgfortran see above).
> > 
> > Not really no:
> > 
> > 1) GCC can add new symbols or new versions of them with every release
> > which means the problem can reappear with every new GCC release and GCC
> > releases aren't aligned with FreeBSD releases.
> 
> GCC developers do add new symbols.  Not sure what you mean by
> new versions.  The ABI is stable.  If they change the ABI, then
> they would bump the major number to 2.
They add new symbols and provide new symbol versions where these symbols
are assigned.

> 
> > 2) Base system libgcc is essentially libcompilerrt, the LLVM compiler
> > runtime.  LLVM doesn't seem to need these symbols, nothing in base needs
> > these symbols so why should we implement these third party compiler
> > runtime helper functions?
> 
> Because FreeBSD usurped the name of a well-known library from a
> well-known open source project.  Users might expect that that
> well-known library has the same ABI and functionality of the
> library provided by the well-known project.
Nothing was usurped, you can lower your tone.

Initially libgcc_s.so.1 was provided by gcc and the library was updated
during the regular gcc imports. When gcc changed the license, the
libgcc_s.so.1 become stalled due to the block on the import of the new
gcc versions.

Some parts of gcc-provided libgcc_s.so.1 were replaced with llvm unwinder,
some parts with compiler-rt functions.  The new functions added by gcc
were not imported because nobody who can do that knew about the problem.
Generic hand-waving is not the problem description.

Now, that the list of missing symbols is collected and possible sources
for them are identified, at least some gaps can be filled.

> 
> If nothing in base needs /lib/libgcc_s, then let's remove it.
> If nothing in base needs it, let's rename name it to libfreebsd_s.so.
This cannot be done, because it breaks the base system ABI. In
particular, after

Re: FreeCAD 0.17 && /lib//libgcc_s.so.1

[Konstantin Belousov]

On Fri, Feb 22, 2019 at 02:04:07PM +0100, Tijl Coosemans wrote:
> On Thu, 21 Feb 2019 10:53:00 -0700 "Russell L. Carter"
>  wrote:
> > On 2/21/19 10:05 AM, Tijl Coosemans wrote:
> >> On Sun, 17 Feb 2019 10:16:04 -0500 Diane Bruce  wrote:  
> >>> On Sat, Feb 16, 2019 at 06:35:52PM -0700, Russell L. Carter wrote:  
>  So I must dig deeper.  Perhaps with rpaths interacting with the system
>  paths?  
> >>>
> >>> You got it. ;)
> >>> Except python doesn't have an rpath which is why this keeps coming
> >>> up over and over again.  
> >> 
> >> Maybe we should just add the gcc rpaths to the python ports LDFLAGS
> >> without depending on gcc.  Then python should use gcc libgcc_s when
> >> it exists and fall back to base system libgcc_s when it doesn't.
> >> 
> >> Maybe we should compile *all* ports with gcc rpaths without depending
> >> on gcc, just like we already compile everything with -fstack-protector
> >> in LDFLAGS.
> > 
> > I would like to briefly present the perspective from a user's POV.
> > There is a large world wide population of scientific custom code
> > users/coders who run on linux boxes in a wide variety of
> > configurations.  Almost none of that code will ever have a chance of
> > ending up in /usr/ports, although there is nothing technically
> > challenging about almost any of it (the porting process that is).  So
> > anytime any of those users wants to try running their non-ported
> > scientific code, a large fraction of which contains python and/or
> > gfortan code, they are going to hit the libgcc_s issue.  Only a few of
> > those people understand rpaths as well as I do (and I'm no expert),
> > because it's never been their job.  They probably struggle to figure
> > out what question to ask, because, "libgcc_s?  WTF?, this is python!"
> > In addition, oftentimes people have sometimes big pipelines of
> > different programs executing.  So writing a shell script wrapper
> > around each and every one of those custom programs... not going to
> > happen.  libmap.conf(5)?  Not going to happen.  Linux works out of the
> > box.
> > 
> > People like Steve Kargl and me are... puzzled at why FreeBSD would
> > do this to itself.  Having people writing and running custom
> > opensource software on a performant opensource OS is **good**.  We
> > should be enabling them.
> 
> If I were the lang/gcc maintainer this -rpath problem would be my number
> one priority.  The current maintainer has never proposed any solutions
> and when I submit patches he always resists.  I'm done wasting my time
> fighting him.
> 
> Then threads like this appear every few months.  It's always the same
> people that respond with the same wrong ideas and wrong solutions and
> never providing patches.  I always politely point out what's wrong with
> their ideas and provide patches that do work.  Then they respond with
> the same wrong ideas without even trying my patches.  You can see that
> in this very thread.  Rinse, repeat.
> 
> It's a people problem, not a technical problem.  My patches solve the
> technical problem.  I can't help it if people don't pick up the patches.
Yes, we absolutely must avoid situation where two similar libraries
(i.e. providing some subset of symbols from other) are linked into the
same executing process.

I think your patches would be a definitive improvement, esp. the part
which makes libgfortran linking only as needed.

For the other part, which makes the ports dso a priority over the base
dso, I would exercise some more causion. For ports we know only about
libgcc_s.so.1 which has the same name in base and in ports, other
libraries in base should have libprivate suffix to not conflict, right ?
What about openssl libraries ?

I think such setup makes it easier for user to accidentaly break the system.
She could install something manually (not from ports), or copy some file
into /usr/local/lib, which conflicts with base and cause troubles.

Do you agree that the ultimate and proper solution is to add missed symbols
and versions to the base libgcc_s.so.1 ?  IMO it is, and this thread started
to show some work which might finally solve that.
(But about as-needed for libgfortran see above).

> 
> As for Linux, note that in theory the same problem also exists there.
> It's just that most Linux distribution only provide one version of gcc.
> FreeBSD provides multiple versions of multiple compilers and we allow
> code compiled with different compilers to be linked together.  Still,
> with my patches it should all just work without -rpath.
> 
> I can only recommend that you try the patches.  Your Fortran/Python
> pipeline will just work like it does on Linux.  I've attached them once
> more for your convenience.

> Index: libexec/rc/rc.conf
> ===
> --- libexec/rc/rc.conf(revision 343935)
> +++ libexec/rc/rc.conf(working copy)
> @@ -636,14 +636,14 @@ linux_enable="NO"   # Linux binary compatibility 
> loaded 
>  

Re: FreeBSD Port: krb5-1.17

[Konstantin Belousov]

On Tue, Jan 08, 2019 at 06:56:11PM -0800, Cy Schubert wrote:
> In message <20190109022154.gb26...@kib.kiev.ua>, Konstantin Belousov 
> writes:
> > On Tue, Jan 08, 2019 at 04:47:19PM -0800, Cy Schubert wrote:
> > > Can you provide a complete listing, please. That library didn't build on 
> > > yo
> > ur machine for some reason and we need to find out why. Also, can you also 
> > se
> > nd a copy of config.log?
> > > 
> >
> > https://kib.kiev.ua/poudriere/data/nuc_poudriere_11-head/2019-01-09_04h07m11s
> > /logs/errors/krb5-1.17.log
> 
> Hi Konstantin,
> 
> Can you give this patch a spin please?

This seems to build fine.
https://kib.kiev.ua/poudriere/data/nuc_poudriere_11-head/2019-01-09_05h09m45s/logs/krb5-1.17.log
___
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: portmaster, portupgrade, etc

[Konstantin Belousov]

On Thu, Oct 05, 2017 at 08:25:20AM -0700, Steve Kargl wrote:
> On Thu, Oct 05, 2017 at 05:59:41PM +0300, Konstantin Belousov wrote:
> > On Thu, Oct 05, 2017 at 07:51:16AM -0700, Steve Kargl wrote:
> > > On Thu, Oct 05, 2017 at 11:35:58AM +0300, Konstantin Belousov wrote:
> > > > On Wed, Oct 04, 2017 at 05:27:11PM -0700, Don Lewis wrote:
> > > > > > The system in question is my last i686 laptop, which I 
> > > > > > use for libm development and testing.  Once I cannot use
> > > > > > that laptop (whether hardware failure or inability to 
> > > > > > update the installed ports), I'll stop worrying about a
> > > > > > functional libm on 32-bit hardware.
> > > > > 
> > > > > As an aside, this sort of thing could be done in an i386 VM or maybe 
> > > > > an
> > > > > i386 jail on amd64 hardware.
> > > > 
> > > > You do not need even a jail for this. Base cc -m32 works on amd64 for
> > > > long time, and 32bit binaries can be executed from host environment,
> > > > assuming all third-party libs are provided somewhere in the 32bit
> > > > variant.
> > > > 
> > > > The environment with regard to the hardware configuration should be
> > > > identical to modern i386-arch machine with SSE2.  Incompatibilities are
> > > > considered as bugs and are usually fixed fast when reported.
> > > 
> > > Does this required WITH_LIB32=yes in src.conf?
> > Yes, but this is the default.
> > 
> > > 
> > > More concerning is that the FPU on i686 is set-up in npx to
> > > use 53-bit precision instead of 64-bit.  See x86/fpu.h where
> > > there is a large comment and the settings
> > > 
> > > #define __INITIAL_FPUCW__   0x037F
> > > #define __INITIAL_FPUCW_I386__  0x127F
> > > #define __INITIAL_NPXCW__   __INITIAL_FPUCW_I386__
> > > 
> > > Does cc -m32 on amd64 cause the amd64 fpu to act (exactly?) like
> > > and i387?
> > It is not cc -m32.
> > 
> > Kernel sets up x87 FPU differently for 64 and 32bit processes. See
> > ia32_setregs() where pcb is adjusted for 32bit, and r189423.
> 
> Yes, I know the kernel sets up npx on i686.  If one is testing libm
> changes or new code for libm, then cc -m32 will be insufficient in
> testing the behavior one might get from i387 in 53-bit mode as 
> oppose to 64-bit.  This is the reason the macro LD80C exists in
> math_private.h.
Again, if there is any bug in setting FPU environment for 32bit process,
i.e. an inconsistency between native i386 kernel and compat32 on amd64,
explain it or better, provide the test case.  It will be fixed quickly.

Currently I am not aware of any.

> 
> Which brings me back to my i686 laptop with limited resources.
> If portmgr makes it impractical/impossible to easily install ports
> without a sledge hammer, then testing possible future patches to 
> libm will simply skip i686 class hardware.
> 
> -- 
> Steve
___
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: portmaster, portupgrade, etc

[Konstantin Belousov]

On Thu, Oct 05, 2017 at 07:51:16AM -0700, Steve Kargl wrote:
> On Thu, Oct 05, 2017 at 11:35:58AM +0300, Konstantin Belousov wrote:
> > On Wed, Oct 04, 2017 at 05:27:11PM -0700, Don Lewis wrote:
> > > > The system in question is my last i686 laptop, which I 
> > > > use for libm development and testing.  Once I cannot use
> > > > that laptop (whether hardware failure or inability to 
> > > > update the installed ports), I'll stop worrying about a
> > > > functional libm on 32-bit hardware.
> > > 
> > > As an aside, this sort of thing could be done in an i386 VM or maybe an
> > > i386 jail on amd64 hardware.
> > 
> > You do not need even a jail for this. Base cc -m32 works on amd64 for
> > long time, and 32bit binaries can be executed from host environment,
> > assuming all third-party libs are provided somewhere in the 32bit
> > variant.
> > 
> > The environment with regard to the hardware configuration should be
> > identical to modern i386-arch machine with SSE2.  Incompatibilities are
> > considered as bugs and are usually fixed fast when reported.
> 
> Does this required WITH_LIB32=yes in src.conf?
Yes, but this is the default.

> 
> More concerning is that the FPU on i686 is set-up in npx to
> use 53-bit precision instead of 64-bit.  See x86/fpu.h where
> there is a large comment and the settings
> 
> #define __INITIAL_FPUCW__   0x037F
> #define __INITIAL_FPUCW_I386__  0x127F
> #define __INITIAL_NPXCW__   __INITIAL_FPUCW_I386__
> 
> Does cc -m32 on amd64 cause the amd64 fpu to act (exactly?) like
> and i387?
It is not cc -m32.

Kernel sets up x87 FPU differently for 64 and 32bit processes. See
ia32_setregs() where pcb is adjusted for 32bit, and r189423.
___
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: portmaster, portupgrade, etc

[Konstantin Belousov]

On Wed, Oct 04, 2017 at 05:27:11PM -0700, Don Lewis wrote:
> > The system in question is my last i686 laptop, which I 
> > use for libm development and testing.  Once I cannot use
> > that laptop (whether hardware failure or inability to 
> > update the installed ports), I'll stop worrying about a
> > functional libm on 32-bit hardware.
> 
> As an aside, this sort of thing could be done in an i386 VM or maybe an
> i386 jail on amd64 hardware.

You do not need even a jail for this. Base cc -m32 works on amd64 for
long time, and 32bit binaries can be executed from host environment,
assuming all third-party libs are provided somewhere in the 32bit
variant.

The environment with regard to the hardware configuration should be
identical to modern i386-arch machine with SSE2.  Incompatibilities are
considered as bugs and are usually fixed fast when reported.
___
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: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more)

[Konstantin Belousov]

On Wed, Jul 19, 2017 at 10:06:13PM -0400, Alexander Kabaev wrote:
> On Wed, 19 Jul 2017 22:50:04 +0200 (CEST)
> Gerald Pfeifer  wrote:
> 
> > On Fri, 14 Apr 2017, Alexander Kabaev wrote:
> > > it was suggested multiple times that the whole fixinc step is
> > > ultimately harmful and serves no useful purpose and probably should
> > > be disabled in built packages outright. Is there a reason not to do
> > > it? Even Redhat appears to do the slimming in their rpms:  
> > 
> > For the more current lang/gcc* ports (not the gcc5-aux and gcc6-aux 
> > ports which I do not maintain) I have now removed packaging the
> > headers processed by fixincludes, so any problems in that direction
> > should be gone.
> > 
> > Gerald
> 
> Thank you, Gerald!

This is very good news, thank you.  Gcc should be much more usable now.
___
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: problem about port need /proc to build

[Konstantin Belousov]

On Tue, Jun 13, 2017 at 06:57:40PM +0800, Jov wrote:
> Hi ports hackers,
> 
> I am porting tensorflow to FreeBSD, It uses bazel to manage the
> dependencies and do the build.The port work now is mostly done (see:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219609,I have local patch
> to fix the network need for do-configure) except one problem which I am not
> sure. So I write this mail to ask.
> 
> The problem is bazel use /proc to locate its binary when start,
> see:
> https://github.com/bazelbuild/bazel/blob/255953740813414433eceedc99c2bef3c3f6e307/src/main/cpp/blaze_util_freebsd.cc
> :
> string GetSelfPath() {
> char buffer[PATH_MAX] = {};
> ssize_t bytes = readlink("/proc/curproc/file", buffer, sizeof(buffer));
> if (bytes == sizeof(buffer)) {
> // symlink contents truncated
> bytes = -1;
> errno = ENAMETOOLONG;
> }
> I am not sure this is acceptable for FreeBSD ports.I now set USE_PROCFS=yes
> for poudriere and it can pass the testport.
> 
> If port needs /proc is not acceptable, I will patch devel/bazel to use
> sysctl get its binary path.

It is not a question about being acceptable or not to use /proc, but
about user convenience.  FreeBSD does not automatically configure
procfs mount and base utilities function without procfs.  As result,
users typically do not need it.

If your port adds dependency on procfs, then it also adds requirements on
the machine configuration and some inconvenience to its users.  Some
programs cannot function without procfs, e.g. jvm.  But if it can be
trivially avoided, it is better to avoid.
___
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: firefox/ rust failed to install on FreeBSD 12-CURRENT

[Konstantin Belousov]

On Mon, May 29, 2017 at 01:28:57AM +0800, blubee blubeeme wrote:
> I'm trying to install firefox on FreeBSD
> FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT
> #0 r318998: Sun May 28 04:38:22 CST 2017
> /usr/obj/usr/src/sys/GENERIC  amd64
> 
> ===>   firefox-i18n-53.0.3 depends on file: /usr/local/lib/firefox/firefox
> - not found
> ===>   firefox-53.0.3_1,1 depends on package: nspr>=4.13.1 - found
> ===>   firefox-53.0.3_1,1 depends on package: nss>=3.29.5 - found
> ===>   firefox-53.0.3_1,1 depends on package: libevent>=2.0.21_2 - found
> ===>   firefox-53.0.3_1,1 depends on package: harfbuzz>=1.4.1 - found
> ===>   firefox-53.0.3_1,1 depends on package: graphite2>=1.3.8 - found
> ===>   firefox-53.0.3_1,1 depends on package: png>=1.6.28 - found
> ===>   firefox-53.0.3_1,1 depends on package: libvorbis>=1.3.5,3 - found
> ===>   firefox-53.0.3_1,1 depends on package: libvpx>=1.5.0 - found
> ===>   firefox-53.0.3_1,1 depends on package: sqlite3>=3.17.0 - found
> ===>   firefox-53.0.3_1,1 depends on package: py27-sqlite3>0 - found
> ===>   firefox-53.0.3_1,1 depends on package: v4l_compat>0 - found
> ===>   firefox-53.0.3_1,1 depends on executable: autoconf-2.13 - found
> ===>   firefox-53.0.3_1,1 depends on executable: yasm - found
> ===>   firefox-53.0.3_1,1 depends on executable: zip - found
> ===>   firefox-53.0.3_1,1 depends on package: gtk3>=3.14.6 - found
> ===>   firefox-53.0.3_1,1 depends on package: libnotify>0 - found
> ===>   firefox-53.0.3_1,1 depends on executable: rustc - not found
> ===>  Building for rust-1.17.0
> gmake[7]: Entering directory '/usr/ports/lang/rust/work/rustc-1.17.0-src'
> "/usr/local/bin/python2.7"
> /usr/ports/lang/rust/work/rustc-1.17.0-src/src/bootstrap/bootstrap.py
> build -v
> info: looks like you are running this command under `sudo`
>   and so in order to preserve your $HOME this will now
>   use vendored sources by default. Note that if this
>   does not work you should run a normal build first
>   before running a command like `sudo make install`
Build system already tries to say you what you are doing wrong.

Do not build the rust port under sudo.

> extracting /usr/ports/lang/rust/work/rustc-1.17.0-src/build/cache/
> 2017-03-11/rust-std-1.16.0-x86_64-unknown-freebsd.tar.gz
>   extracting rust-std-1.16.0-x86_64-unknown-freebsd/rust-std-x86_
> 64-unknown-freebsd
>   extracting rust-std-1.16.0-x86_64-unknown-freebsd/rust-std-x86_
> 64-unknown-freebsd/lib
>   extracting rust-std-1.16.0-x86_64-unknown-freebsd/rust-std-x86_
> 64-unknown-freebsd/manifest.in
>   extracting rust-std-1.16.0-x86_64-unknown-freebsd/rust-std-x86_
> 64-unknown-freebsd/lib/rustlib
>   extracting rust-std-1.16.0-x86_64-unknown-freebsd/rust-std-x86_
> 64-unknown-freebsd/lib/rustlib/x86_64-unknown-freebsd
>   extracting rust-std-1.16.0-x86_64-unknown-freebsd/rust-std-x86_
> 64-unknown-freebsd/lib/rustlib/x86_64-unknown-freebsd/lib
>   extracting rust-std-1.16.0-x86_64-unknown-freebsd/rust-std-x86_
> 64-unknown-freebsd/lib/rustlib/x86_64-unknown-freebsd/lib/GNUSparseFile.0/
> librustc_llvm-74a1be1110b5d4d0.so
> gmake[7]: Leaving directory '/usr/ports/lang/rust/work/rustc-1.17.0-src'
> *** Error code 1
> 
> Stop.
> make[6]: stopped in /usr/ports/lang/rust
> *** Error code 1
> 
> Stop.
> make[5]: stopped in /usr/ports/lang/rust
> *** Error code 1
> 
> Stop.
> make[4]: stopped in /usr/ports/www/firefox
> *** Error code 1
> 
> Stop.
> make[3]: stopped in /usr/ports/www/firefox
> *** Error code 1
> 
> Stop.
> make[2]: stopped in /usr/ports/www/firefox-i18n
> *** Error code 1
> 
> Stop.
> make[1]: stopped in /usr/ports/www/firefox-i18n
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/ports/www/firefox-i18n
> 
> 
> I am getting build failures with or without make_build_unsafe flags.
> 
> I am building from source and ports tree is updated to revision 441919.
> 
> Best,
> Owen
> ___
> 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"
___
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: 64-bit inodes (ino64) Status Update and Call for Testing

[Konstantin Belousov]

On Sun, May 21, 2017 at 04:03:55PM +0200, Jilles Tjoelker wrote:
> On Sun, May 21, 2017 at 03:31:18PM +0300, Konstantin Belousov wrote:
> > On Sun, May 21, 2017 at 02:14:56PM +0200, Jilles Tjoelker wrote:
> > > We have another type in this area which is too small in some situations:
> > > uint8_t for struct dirent.d_namlen. For filesystems that store filenames
> > > as upto 255 UTF-16 code units, the name to be stored in d_name may be
> > > upto 765 bytes long in UTF-8. This was reported in PR 204643. The code
> > > currently handles this by returning the short (8.3) name, but this name
> > > may not be present or usable, leaving the file inaccessible.
> 
> > > Actually allowing longer names seems too complicated to add to the ino64
> > > change, but changing d_namlen to uint16_t (using d_pad0 space) and
> > > skipping entries with d_namlen > 255 in libc may be helpful.
> 
> > > Note that applications using the deprecated readdir_r() will not be able
> > > to read such long names, since the API does not allow specifying that a
> > > larger buffer has been provided. (This could be avoided by making struct
> > > dirent.d_name 766 bytes long instead of 256.)
> 
> > > Unfortunately, the existence of readdir_r() also prevents changing
> > > struct dirent.d_name to the more correct flexible array.
> 
> > Yes, changing the size of d_name at this stage of the project is out of
> > question. My reading of your proposal is that we should extend the size
> > of d_namlen to uint16_t, am I right ? Should we go to 32bit directly
> > then, perhaps ?
> 
> Yes, my proposal is to change d_namlen to uint16_t.
> 
> Making it 32 bits is not useful with the 16-bit d_reclen, and increasing
> d_reclen does not seem useful to me with the current model of
> getdirentries() where the whole dirent must fit into the caller's
> buffer.
Bumping it now might cause less churn later, even if unused, but ok.

> 
> > I did not committed the change below, nor did I tested or even build it.
> 
> I'd like to skip overlong names in the native readdir_r() as well, so
> that long name support can be added to the kernel later without causing
> buffer overflows with applications using FreeBSD 12.0 libc.
> 
> The native readdir() does not seem to have such a problem.

Again, not even compiled.

diff --git a/lib/libc/gen/readdir-compat11.c b/lib/libc/gen/readdir-compat11.c
index 1c52f563c75..a865ab9157e 100644
--- a/lib/libc/gen/readdir-compat11.c
+++ b/lib/libc/gen/readdir-compat11.c
@@ -41,6 +41,7 @@ __FBSDID("$FreeBSD$");
 #define_WANT_FREEBSD11_DIRENT
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -53,10 +54,12 @@ __FBSDID("$FreeBSD$");
 
 #include "gen-compat.h"
 
-static void
+static bool
 freebsd11_cvtdirent(struct freebsd11_dirent *dstdp, struct dirent *srcdp)
 {
 
+   if (srcdp->d_namelen >= sizeof(dstdp->d_name))
+   return (false);
dstdp->d_type = srcdp->d_type;
dstdp->d_namlen = srcdp->d_namlen;
dstdp->d_fileno = srcdp->d_fileno;  /* truncate */
@@ -65,6 +68,7 @@ freebsd11_cvtdirent(struct freebsd11_dirent *dstdp, struct 
dirent *srcdp)
bzero(dstdp->d_name + dstdp->d_namlen,
dstdp->d_reclen - offsetof(struct freebsd11_dirent, d_name) -
dstdp->d_namlen);
+   return (true);
 }
 
 struct freebsd11_dirent *
@@ -75,13 +79,15 @@ freebsd11_readdir(DIR *dirp)
 
if (__isthreaded)
_pthread_mutex_lock(>dd_lock);
-   dp = _readdir_unlocked(dirp, 1);
+   dp = _readdir_unlocked(dirp, RDU_SKIP);
if (dp != NULL) {
if (dirp->dd_compat_de == NULL)
dirp->dd_compat_de = malloc(sizeof(struct
freebsd11_dirent));
-   freebsd11_cvtdirent(dirp->dd_compat_de, dp);
-   dstdp = dirp->dd_compat_de;
+   if (freebsd11_cvtdirent(dirp->dd_compat_de, dp))
+   dstdp = dirp->dd_compat_de;
+   else
+   dstdp = NULL;
} else
dstdp = NULL;
if (__isthreaded)
@@ -101,8 +107,10 @@ freebsd11_readdir_r(DIR *dirp, struct freebsd11_dirent 
*entry,
if (error != 0)
return (error);
if (xresult != NULL) {
-   freebsd11_cvtdirent(entry, );
-   *result = entry;
+   if (freebsd11_cvtdirent(entry, ))
+   *result = entry;
+   else /* should not happen due to RDU_SHORT */
+   *result = NULL;
} else
*result = NULL;
return (0);
diff --git a/lib/libc/gen/readdir.c b/lib/libc/gen/readdi

Re: 64-bit inodes (ino64) Status Update and Call for Testing

[Konstantin Belousov]

On Sun, May 21, 2017 at 02:14:56PM +0200, Jilles Tjoelker wrote:
> We have another type in this area which is too small in some situations:
> uint8_t for struct dirent.d_namlen. For filesystems that store filenames
> as upto 255 UTF-16 code units, the name to be stored in d_name may be
> upto 765 bytes long in UTF-8. This was reported in PR 204643. The code
> currently handles this by returning the short (8.3) name, but this name
> may not be present or usable, leaving the file inaccessible.
> 
> Actually allowing longer names seems too complicated to add to the ino64
> change, but changing d_namlen to uint16_t (using d_pad0 space) and
> skipping entries with d_namlen > 255 in libc may be helpful.
> 
> Note that applications using the deprecated readdir_r() will not be able
> to read such long names, since the API does not allow specifying that a
> larger buffer has been provided. (This could be avoided by making struct
> dirent.d_name 766 bytes long instead of 256.)
> 
> Unfortunately, the existence of readdir_r() also prevents changing
> struct dirent.d_name to the more correct flexible array.

Yes, changing the size of d_name at this stage of the project is out of
question. My reading of your proposal is that we should extend the size
of d_namlen to uint16_t, am I right ? Should we go to 32bit directly
then, perhaps ?

I did not committed the change below, nor did I tested or even build it.

diff --git a/lib/libc/gen/readdir-compat11.c b/lib/libc/gen/readdir-compat11.c
index 1c52f563c75..18d85adaa63 100644
--- a/lib/libc/gen/readdir-compat11.c
+++ b/lib/libc/gen/readdir-compat11.c
@@ -41,6 +41,7 @@ __FBSDID("$FreeBSD$");
 #define_WANT_FREEBSD11_DIRENT
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -53,10 +54,12 @@ __FBSDID("$FreeBSD$");
 
 #include "gen-compat.h"
 
-static void
+static bool
 freebsd11_cvtdirent(struct freebsd11_dirent *dstdp, struct dirent *srcdp)
 {
 
+   if (srcdp->d_namelen >= sizeof(dstdp->d_name))
+   return (false);
dstdp->d_type = srcdp->d_type;
dstdp->d_namlen = srcdp->d_namlen;
dstdp->d_fileno = srcdp->d_fileno;  /* truncate */
@@ -65,6 +68,7 @@ freebsd11_cvtdirent(struct freebsd11_dirent *dstdp, struct 
dirent *srcdp)
bzero(dstdp->d_name + dstdp->d_namlen,
dstdp->d_reclen - offsetof(struct freebsd11_dirent, d_name) -
dstdp->d_namlen);
+   return (true);
 }
 
 struct freebsd11_dirent *
@@ -80,8 +84,10 @@ freebsd11_readdir(DIR *dirp)
if (dirp->dd_compat_de == NULL)
dirp->dd_compat_de = malloc(sizeof(struct
freebsd11_dirent));
-   freebsd11_cvtdirent(dirp->dd_compat_de, dp);
-   dstdp = dirp->dd_compat_de;
+   if (freebsd11_cvtdirent(dirp->dd_compat_de, dp))
+   dstdp = dirp->dd_compat_de;
+   else
+   dstdp = NULL;
} else
dstdp = NULL;
if (__isthreaded)
@@ -101,8 +107,10 @@ freebsd11_readdir_r(DIR *dirp, struct freebsd11_dirent 
*entry,
if (error != 0)
return (error);
if (xresult != NULL) {
-   freebsd11_cvtdirent(entry, );
-   *result = entry;
+   if (freebsd11_cvtdirent(entry, ))
+   *result = entry;
+   else
+   *result = NULL;
} else
*result = NULL;
return (0);
diff --git a/sys/kern/vfs_syscalls.c b/sys/kern/vfs_syscalls.c
index 784af836aee..27b2635030d 100644
--- a/sys/kern/vfs_syscalls.c
+++ b/sys/kern/vfs_syscalls.c
@@ -3733,7 +3733,8 @@ freebsd11_kern_getdirentries(struct thread *td, int fd, 
char *ubuf, u_int count,
if (dp->d_reclen == 0)
break;
MPASS(dp->d_reclen >= _GENERIC_DIRLEN(0));
-   /* dp->d_namlen <= sizeof(dstdp.d_name) - 1 always */
+   if (dp->d_namlen >= sizeof(dstdp.d_name))
+   continue;
dstdp.d_type = dp->d_type;
dstdp.d_namlen = dp->d_namlen;
dstdp.d_fileno = dp->d_fileno;  /* truncate */
diff --git a/sys/sys/dirent.h b/sys/sys/dirent.h
index 341855d0530..691c4e8f90f 100644
--- a/sys/sys/dirent.h
+++ b/sys/sys/dirent.h
@@ -67,8 +67,9 @@ struct dirent {
off_t  d_off;   /* directory offset of entry */
__uint16_t d_reclen;/* length of this record */
__uint8_t  d_type;  /* file type, see below */
-   __uint8_t  d_namlen;/* length of string in d_name */
-   __uint32_t d_pad0;
+   __uint8_t  d_pad0
+   __uint16_t d_namlen;/* length of string in d_name */
+   __uint16_t d_pad1;
 #if __BSD_VISIBLE
 #defineMAXNAMLEN   255
chard_name[MAXNAMLEN + 1];  /* name must be no longer than this */

Re: FreeBSD Port: sysutils/zrep / ksh93

[Konstantin Belousov]

On Sat, Apr 22, 2017 at 04:29:40AM +0200, Kurt Jaeger wrote:
> Hi!
> 
> > >>> can you please update port sysutils/zrep to current version?
> > >>> GitHup repo https://github.com/bolthole/zrep has version 1.7.1 with many
> > >>> fixes and improvements.
> > >>
> > >> Hm, it looks like zrep depends on shells/ksh93, which is missing
> > >> from all MASTER_SITES. Do you still have the ksh93 distfile at hand ?
> > >
> > > Ups, it is strange, I installed zrep and ksh93 about one week ago
> > > without problem.
> > >
> > > Sure, I have these files:
> > >
> > > # ll /vol0/poudriere/distfiles/ksh93/*
> > > -rw-r--r--  1 root  wheel   383979 May 24  2013
> > > /vol0/poudriere/distfiles/ksh93/INIT.2013-05-24.tgz
> > > -rw-r--r--  1 root  wheel  2053532 Aug  7  2012
> > > /vol0/poudriere/distfiles/ksh93/ast-ksh.2012-08-01.tgz
> > >
> > > Should I post them somewhere?
> 
> Yes, please.
> 
> > Regarding to unavailable original sources... I found this discussion
> > https://unix.stackexchange.com/questions/246338/is-the-shell-ksh93-dead
> > 
> > Maybe it's time to move to another version of ksh:
> > 1) OpenBSD maintained version
> > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/bin/ksh/
> > 2) GitHub clone of AT version ksh93
> > https://github.com/att/ast/tree/master/src/cmd/ksh93
> 
> Patches to update the ksh93 port to use one of those so are very welcome!
pdksh (and its OpenBSD update) is quite different from the authentic ksh93.
I think that only the github' att/ast variant is feasible as a replacement.
___
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"

64-bit inodes (ino64) Status Update and Call for Testing

[Konstantin Belousov]

Inodes are data structures corresponding to objects in a file system,
such as files and directories. FreeBSD has historically used 32-bit
values to identify inodes, which limits file systems to somewhat under
2^32 objects. Many modern file systems internally use 64-bit identifiers
and FreeBSD needs to follow suit to properly and fully support these
file systems.

The 64-bit inode project, also known as ino64, started life many years
ago as a project by Gleb Kurtsou (gleb@).  After that time several
people have had a hand in updating it and addressing regressions, after
mckusick@ picked up and updated the patch, and acted as a flag-waver.

Sponsored by the FreeBSD Foundation I have spent a significant effort
on outstanding issues and integration -- fixing compat32 ABI, NFS and
ZFS, addressing ABI compat issues and investigating and fixing ports
failures.  rmacklem@ provided feedback on NFS changes, emaste@ and
jhb@ provided feedback and review on the ABI transition support. pho@
performed extensive testing and identified a number of issues that
have now been fixed.  kris@ performed an initial ports investigation
followed by an exp-run by antoine@. emaste@ helped with organization
of the process.

This note explains how to perform useful testing of the ino64 branch,
beyond typical smoke tests.

1. Overview.

The ino64 branch extends the basic system types ino_t and dev_t from
32-bit to 64-bit, and nlink_t from 16-bit to 64-bit.  The struct dirent
layout is modified due to the larger size of ino_t, and also gains a
d_off (directory offset) member. As ino64 implies an ABI change anyway
the struct statfs f_mntfromname[] and f_mntonname[] array length
MNAMELEN is increased from 88 to 1024, to allow for longer mount path
names.

ABI breakage is mitigated by providing compatibility using versioned
symbols, ingenious use of the existing padding in structures, and by
employing other tricks.  Unfortunately, not everything can be fixed,
especially outside the base system.  For instance, third-party APIs
which pass struct stat around are broken in backward and forward-
incompatible way.

2. Motivation.

The main risk of the ino64 change is the uncontrolled ABI breakage.
Due to expansion of the basic types dev_t, ino_t and struct dirent,
the impact is not limited to one part of the system, but affects:
- kernel/userspace interface (syscalls ABI, mostly stat(2), kinfo
  and more)
- libc interface (mostly related to the readdir(3), FTS(3))
- collateral damage in other libraries that happens to use changed types
  in the interfaces.  See, for instance, libprocstat, for which compat
  was provided using symbol versioning, and libutil, which shlib version
  was bumped.

3. Quirks.

We handled kinfo sysctl MIBs, but other MIBs which report structures
depended on the changed type, are not handled in general.  It was
considered that the breakage is either in the management interfaces,
where we usually allow ABI slip, or is not important.

Struct xvnode changed layout, no compat shims are provided.

For struct xtty, dev_t tty device member was reduced to uint32_t.  It
was decided that keeping ABI compat in this case is more useful than
reporting 64bit dev_t, for the sake of pstat.

4. Testing procedure.

The ino64 project can be tested by cloning the project branch from
GitHub or by applying the patch  to a working tree.  The authorative source is the
GitHub, I do not promise to update the review for each update.

To clone from GitHub:
% git clone -b ino64 https://github.com/FreeBSDFoundation/freebsd.git ino64

To fetch the patch from Phabricator:
- Visit https://reviews.freebsd.org/D10439
- Click "Download Raw Diff" at the upper right of the page

Or
% arc patch D10439

After that, in the checkout directory do
% (cd sys/kern && touch syscalls.master && make sysent)
% (cd sys/compat/freebsd32 && touch syscalls.master && make sysent)
If you use custom kernel configuration, ensure that
options COMPAT_FREEBSD11
is included into the config.  Then build world and kernel in the
usual way, install kernel, reboot, install new world.  Do not make
shortcuts in the update procedure.

4.1 New kernel, old world.

Build and install pristine HEAD world, apply patch and only build and
install updated kernel. The system must work same as with the pristine
kernel.

4.2 New kernel, new world, old third-party applications.

Build and install patched kernel and world.  Applications compiled on the
pristine HEAD (e.g. installed by pkg from the regular portmgr builds) must
work without a regression.

4.3 32bit compat.

Same as 4.1 and 4.2, but for 32bit (i386) binaries on the amd64 host.
Note that big-endian host, like powerpc, might expose additional
bugs in the 32bit compat with the patch, but the testing is too cumbersome
to arrange.

4.4 Targeted tests.

Useful programs to check items 4.1, 4.2 and 4.3 are versions of the
following programs, taken from the pristine system:

  stat(8). Use it on regular file, file in /dev, socket, pipe and 

Re: Chicken/egg problem with pkg

[Konstantin Belousov]

On Fri, Mar 10, 2017 at 02:55:13PM +0100, Jan Bramkamp wrote:
> Among other 
> things FreeBSD 10.3 added a bunch of new *at() system calls like openat. 
> These *at() system calls are useful inside (capsicum) sandboxes. Your 
> old 10.1 kernel lacks those systems calls and your old 10.1 libc lacks 
> the stubs to call them anyways. It is this missing stub that causes the 
> new libpkg.so to fail to link.

Although (removed) rest of your mail is mostly accurate, the cited part
is explicitely false. The openat(2) syscall and friends exist even in
FreeBSD 8.x.  What has changed in 10.2->10.3 is that the version for
openat symbol in libc has to be bumped due to some issue with libthr. As
result, newer binaries require a symbol version which does not exist in
older libc.
___
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: xorg-server 1.18.4 segfaults

[Konstantin Belousov]

On Wed, Feb 15, 2017 at 02:54:50AM +, Koichiro IWAO wrote:
> [180361.824] (EE) Backtrace:
> [180361.836] (EE) 0: /usr/local/bin/Xorg (OsInit+0x38a) [0x5abfca]
> [180361.846] (EE) 1: /lib/libthr.so.3 (_pthread_sigmask+0x50d) [0x802989bbd]
> [180361.857] (EE) 2: /lib/libthr.so.3 (_pthread_getspecific+0xe9f) 
> [0x802989acf]
> [180361.871] (EE) 3: ? (?+0xe9f) [0x8032]
> [180361.882] (EE) 4: /usr/local/llvm39/lib/libLLVM-3.9.so 
> (_ZN4llvm13StringMapImpl15LookupBucketForENS_9StringRefE+0xf0) [0x80b0c0340]
> [180361.898] (EE) 5: /usr/local/llvm39/lib/libLLVM-3.9.so 
> (LLVMParseCommandLineOptions+0x7cf) [0x80b08497f]
> [180361.909] (EE) 6: /usr/local/llvm39/lib/libLLVM-3.9.so 
> (LLVMParseCommandLineOptions+0x92c) [0x80b084c1c]
> [180361.923] (EE) 7: /usr/local/llvm39/lib/libLLVM-3.9.so 
> (_ZN4llvm2cl6Option11addArgumentEv+0x7c) [0x80b078dec]
> [180361.934] (EE) 8: /usr/local/llvm37/lib/libLLVMSupport.so.3.7 
> (_ZNSt3__127__insertion_sort_incompleteIRNS_6__lessINS_4pairIN4llvm10TimeRecordENS_12basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEESB_EEPSB_EEbT0_SF_T_+0x67d)
>  [0x8199ae31d]
> [180361.944] (EE) 9: /usr/local/llvm37/lib/libLLVMSupport.so.3.7 
> (_ZN4llvm3sys8WatchdogD1Ev+0x32) [0x8199e6264]
> [180361.955] (EE) 10: /usr/local/llvm37/lib/libLLVMSupport.so.3.7 (_init+0xe) 
> [0x819944ebc]
> [180361.964] (EE) 11: ? (_rtld_is_dlopened+0x1532) [0x80081a3e2]
> [180361.978] (EE) 12: ? (dlopen+0x191) [0x800816311]
> [180361.991] (EE) 13: /usr/local/lib/xorg/modules/extensions/libglx.so 
> (_init+0x1c544) [0x804a594f4]
> [180362.005] (EE) 14: /usr/local/lib/xorg/modules/extensions/libglx.so 
> (_init+0x1b9d9) [0x804a57df9]
> [180362.017] (EE) 15: /usr/local/lib/xorg/modules/extensions/libglx.so 
> (_init+0x1b056) [0x804a56a26]
> [180362.029] (EE) 16: /usr/local/bin/Xorg (InitExtensions+0x61) [0x4ab931]
> [180362.039] (EE) 17: /usr/local/bin/Xorg (remove_fs_handlers+0x3a2) 
> [0x43b4b2]
> [180362.050] (EE) 18: /usr/local/bin/Xorg (_start+0x17f) [0x42507f]
> [180362.064] (EE) 19: ? (?+0x17f) [0x80083917f]
> [180362.065] (EE) 
> [180362.066] (EE) Segmentation fault at address 0x819a07000

Deinstall llvm 3.7.
___
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: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Konstantin Belousov]

On Thu, Feb 09, 2017 at 04:42:45PM +, Matthew Seaman wrote:
> Why do you think it is not being enforced?  Forwards compatibility means
> that during the lifetime of a major branch you can only *add* symbols to
> the system shared libraries, not remove them nor modify any existing
> symbols.  The project has held to that for many years -- not breaking
> ABI forwards compatibility is a really big deal amongst developers.

We try hard to not break ABI backward compatibility between branches
as well, at least for user code (see below). In particular, versioned
libraries in base must be fully backward compatible between branches.
Whole set of the base C runtime libraries is versioned, i.e.
rtld/libc/libthr/libm. libc++ is versioned as well.

For non-versioned libraries, our promise is that on ABI breakage of
any kind, the library version (the libXXX.so.N, the N part) is bumped
so backward compatibility can be provided in some form by installing
previous version of the library. This is done, besides other means, by
misc/compatX ports.

The explanation above is of course, simplified, and somewhat incorrect.
To make it correct would require amount of work which is apparently too
much for single person to do and still be sane.  You can see it that
the project' ABI promise is not formalized even on wiki.

Place were ABI is very badly broken regularly is the management interfaces.
For instance, you are almost guaranteed that ifconfig(8) from a major
branch works only with the kernels on the same branch, and even then,
you must have the binary built with headers from very close kernel
version.  Same for cam(4).

Formalizing these exceptions is the hard part of writing the
ABI guarantee document.
___
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: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Konstantin Belousov]

On Thu, Feb 09, 2017 at 05:26:00PM +0100, Kurt Jaeger wrote:
> Hi!
> 
> > On Thu, Feb 09, 2017 at 04:30:20PM +0100, Franco Fichtner wrote:
> > > FreeBSD package management makes an ABI promise in the form of
> > > "FreeBSD:10:amd64", but not even pkg code itself adheres to this,
> > > and thus we have had subtle and yet fatal breakage in 10.2 and 10.3.
> > Stop spreading FUD. There is no ABI breakage on stable/10 branch,
> > nor there is a breakage in the package sets.
> 
> On the one hand:
> 
> Maybe we can agree that the pkg binary breaking between different
> 10.x versions was unfortunate ? I understand that it was not a
> break of the ABI promises per se, but I can tell you, I was surprised
> as well, when it bite me 8-}
The pkg did not break.  Your usage of it and probably assumptions which
lead to that usage, are broken.  It is as simple as never use a binary
which was built for later system, on earlier.  Even if the binary run, you
get undefined results, e.g. data corruption.

We even grow kern.disallow_high_osrel knob to help people, who cannot
manage herself, to avoid shooting into their foot.  There are some obvious
drawbacks from setting this knob on by default, which explains why it
is not set (it makes recovering from other user mistakes much harder
and the failure mode much more fatal).

> 
> On the other hand:
> 
> Getting the ports/pkg tree moving with the velocity necessary
> to cope with the fast-changing world, sometimes things break
> and we all try to prevent this. Sometimes, mistakes happen...
> 
> -- 
> p...@opsec.eu+49 171 3101372 3 years to 
> go !
___
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: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Konstantin Belousov]

On Thu, Feb 09, 2017 at 04:30:20PM +0100, Franco Fichtner wrote:
> FreeBSD package management makes an ABI promise in the form of
> "FreeBSD:10:amd64", but not even pkg code itself adheres to this,
> and thus we have had subtle and yet fatal breakage in 10.2 and 10.3.
Stop spreading FUD. There is no ABI breakage on stable/10 branch,
nor there is a breakage in the package sets. We only promise
backward-compatibility, and this works as advertized. A binary compiled
on later system, is not guaranteed to work on the early system even on
the same branch.

The current package set for stable/10 is built on 10.3 and is only
guaranteed to work on 10.3 and later. Trying to make arbitrary
combinations of binaries and base systems outside of the scope of the
project.
___
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: mariadb10* ports broken on 9.x since last commit

[Konstantin Belousov]

On Thu, Sep 01, 2016 at 10:50:18PM +0200, Dimitry Andric wrote:
> I don't know.  I understood from Kostik that it would need r232832, but
> apparently this breaks the ABI?
Yes, kind of.  I considered it not appropriate to change the interaction
between csu and rtld for long-lived stable branch.  Also, it might cause
problems for other language translators which provide their own runtimes.

That were the reasonings several years ago, when initializers were reworked,
and definitely I do not want to disturb the branch near EOL.
> 
> It is probably easier to work around this by configuring the binutils
> port so it does not emit .init_array/.fini_array sections.
It was already done in ports r421193.

> 
> -Dimitry
> 
> [1] https://svnweb.freebsd.org/base?view=revision=232832
> 


___
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: Fwd: [package - head-amd64-default][databases/postgis-jdbc] Failed for postgis-jdbc-2.1.7 in extract

[Konstantin Belousov]

On Thu, Sep 01, 2016 at 11:47:33AM +0200, Rainer Hurling wrote:
> I am the maintainer of databases/postgis-jdbc. For some days now I get
> mails like to one further down, for HEAD i386 and HEAD amd64.
> 
> The FreeBSD package build server complains about a problem with untaring
> the jar distfile.
> 
> This worked fine before, and as far as I can see, the distfile is ok. On
> Windows, I am also able to open the jar distfile and use it.
> 
> I think, the port and the distfile are ok, and there is something odd
> with base tar, used by the port system.
> 
> Any idea, what's going on here?
> 
> Thanks for any help in advance.
Probably related to the libarchive updates, in particular r304869,
r304988, r304989.

But I am not sure which version of the userspace the poudriere jail runs.
I see mention of r305036, which might be userspace, but also might be
just the kernel version.

> 
> Regards,
> Rainer Hurling
> 
> 
>  Weitergeleitete Nachricht 
> Betreff: [package - head-amd64-default][databases/postgis-jdbc] Failed
> for postgis-jdbc-2.1.7 in extract
> Datum: Thu, 1 Sep 2016 09:11:11 +
> Von: pkg-fall...@freebsd.org
> An: rhur...@gwdg.de
> Kopie (CC): pkg-fall...@freebsd.org
> 
> You are receiving this mail as a port that you maintain
> is failing to build on the FreeBSD package build server.
> Please investigate the failure and submit a PR to fix
> build.
> 
> Maintainer: rhur...@gwdg.de
> Last committer: m...@freebsd.org
> Ident:  $FreeBSD: head/databases/postgis-jdbc/Makefile 412346
> 2016-04-01 14:00:51Z mat $
> Log URL:
> http://beefy4.nyi.freebsd.org/data/head-amd64-default/p421100_s305036/logs/postgis-jdbc-2.1.7.log
> Build URL:
> http://beefy4.nyi.freebsd.org/build.html?mastername=head-amd64-default=p421100_s305036
> Log:
> 
> >> Building databases/postgis-jdbc
> build started at Thu Sep  1 09:11:08 UTC 2016
> port directory: /usr/ports/databases/postgis-jdbc
> building for: FreeBSD head-amd64-default-job-22 12.0-CURRENT FreeBSD
> 12.0-CURRENT r305036 amd64
> maintained by: rhur...@gwdg.de
> Makefile ident:  $FreeBSD: head/databases/postgis-jdbc/Makefile
> 412346 2016-04-01 14:00:51Z mat $
> Poudriere version: 3.1.14
> Host OSVERSION: 125
> Jail OSVERSION: 125
> 
> ---Begin Environment---
> SHELL=/bin/csh
> UNAME_v=FreeBSD 12.0-CURRENT r305036
> UNAME_r=12.0-CURRENT
> BLOCKSIZE=K
> MAIL=/var/mail/root
> STATUS=1
> OPSYS=FreeBSD
> ARCH=amd64
> SAVED_TERM=
> MASTERMNT=/usr/local/poudriere/data/.m/head-amd64-default/ref
> UID=0
> PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin
> _JAVA_VERSION_LIST_REGEXP=1.6\|1.7\|1.8\|1.6+\|1.7+\|1.8+
> POUDRIERE_BUILD_TYPE=bulk
> PKGNAME=postgis-jdbc-2.1.7
> OSREL=12.0
> _OSRELEASE=12.0-CURRENT
> PYTHONBASE=/usr/local
> OLDPWD=/
> _SMP_CPUS=24
> PWD=/usr/local/poudriere/data/.m/head-amd64-default/ref/.p/pool
> HAVE_COMPAT_IA32_KERN=YES LINUX_OSRELEASE=2.6.32
> MASTERNAME=head-amd64-default
> SCRIPTPREFIX=/usr/local/share/poudriere
> _JAVA_VENDOR_LIST_REGEXP=openjdk\|oracle\|sun
> USER=root
> HOME=/root
> POUDRIERE_VERSION=3.1.14
> SCRIPTPATH=/usr/local/share/poudriere/bulk.sh
> CONFIGURE_MAX_CMD_LEN=262144
> LIBEXECPREFIX=/usr/local/libexec/poudriere
> LOCALBASE=/usr/local
> PACKAGE_BUILDING=yes
> _JAVA_OS_LIST_REGEXP=native\|linux
> OSVERSION=125
> ---End Environment---
> 
> ---Begin OPTIONS List---
> ---End OPTIONS List---
> 
> --CONFIGURE_ARGS--
> 
> --End CONFIGURE_ARGS--
> 
> --CONFIGURE_ENV--
> XDG_DATA_HOME=/wrkdirs/usr/ports/databases/postgis-jdbc/work
> XDG_CONFIG_HOME=/wrkdirs/usr/ports/databases/postgis-jdbc/work
> HOME=/wrkdirs/usr/ports/databases/postgis-jdbc/work TMPDIR="/tmp"
> SHELL=/bin/sh CONFIG_SHELL=/bin/sh
> --End CONFIGURE_ENV--
> 
> --MAKE_ENV--
> XDG_DATA_HOME=/wrkdirs/usr/ports/databases/postgis-jdbc/work
> XDG_CONFIG_HOME=/wrkdirs/usr/ports/databases/postgis-jdbc/work
> HOME=/wrkdirs/usr/ports/databases/postgis-jdbc/work TMPDIR="/tmp"
> NO_PIE=yes MK_DEBUG_FILES=no MK_KERNEL_SYMBOLS=no SHELL=/bin/sh
> NO_LINT=YES PREFIX=/usr/local  LOCALBASE=/usr/local  LIBDIR="/usr/lib"
> CC="cc" CFLAGS="-O2 -pipe  -fstack-protector -fno-strict-aliasing"
> CPP="cpp" CPPFLAGS=""  LDFLAGS=" -fstack-protector" LIBS=""  CXX="c++"
> CXXFLAGS="-O2 -pipe -fstack-protector -fno-strict-aliasing "
> MANPREFIX="/usr/local" BSD_INSTALL_PROGRAM="install  -s -m 555"
> BSD_INSTALL_LIB="install  -s -m 444"  BSD_INSTALL_SCRIPT="install  -m
> 555"  BSD_INSTALL_DATA="install  -m 0644"  BSD_INSTALL_MAN="install  -m 444"
> --End MAKE_ENV--
> 
> --PLIST_SUB--
> JAVASHAREDIR="share/java"
> JAVAJARDIR="share/java/classes"
> OSREL=12.0
> PREFIX=%D
> LOCALBASE=/usr/local
> RESETPREFIX=/usr/local
> PORTDOCS=""
> PORTEXAMPLES=""
> LIB32DIR=lib
> DOCSDIR="share/doc/postgis-jdbc"
> EXAMPLESDIR="share/examples/postgis-jdbc"
> DATADIR="share/postgis-jdbc"
> WWWDIR="www/postgis-jdbc"
> ETCDIR="etc/postgis-jdbc"
> --End PLIST_SUB--
> 
> --SUB_LIST--
> JAVASHAREDIR="/usr/local/share/java"
> 

Re: problem installing ports

[Konstantin Belousov]

On Fri, Aug 26, 2016 at 07:14:38AM -0400, Robert Huff wrote:
>   So ...
>   I replaced my 10.3/i386 system with:
> 
> FreeBSD 11.0-RC2 #0 r304729: Wed Aug 24 06:59:03 UTC 2016 
> r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
> 
>   and kernel+world are working.
>   Installing ports is a different matter.
>   1) I created /usr/ports and /usr/doc.
>   2) I "self-installed" pkg; this brought with it
> 
> apr-1.5.2.1.5.4_1
> db5-5.3.28_4
> expat-2.1.1_2
> gdbm-1.12
> gettext-runtime-0.19.8.1
> indexinfo-0.2.4
> readline-6.3.8
> serf-1.3.8_1
> sqlite3-3.13.0
> 
>   3) Next:
> 
> root@>> pkg install subversion
> 
>   which I used to populate the ports tree.
>   4) Now, to install portmaster.  That requires dialog4ports:
> 
> root@>>   make clean
> ===>  Cleaning for dialog4ports-0.1.6
> root@>>   make
> ===>  License BSD2CLAUSE accepted by the user
> ===>   dialog4ports-0.1.6 depends on file: /usr/local/sbin/pkg - found
> ===> Fetching all distfiles required by dialog4ports-0.1.6 for building
> ===>  Extracting for dialog4ports-0.1.6
> => SHA256 Checksum OK for dialog4ports-0.1.6.tar.gz.
> ===>  Patching for dialog4ports-0.1.6
> ===>  Configuring for dialog4ports-0.1.6
> ===>  Building for dialog4ports-0.1.6
> --- dialog4ports.o ---
> --- mixedlist.o ---
> --- dialog4ports.1.gz ---
> --- dialog4ports.o ---
> cc -O2 -pipe  -fstack-protector -fno-strict-aliasing -Wall -pedantic -c 
> dialog4ports.c -o dialog4ports.o
> --- mixedlist.o ---
> cc -O2 -pipe  -fstack-protector -fno-strict-aliasing -Wall -pedantic -c 
> mixedlist.c -o mixedlist.o
> --- dialog4ports.1.gz ---
> gzip -cn dialog4ports.1 > dialog4ports.1.gz
> --- dialog4ports ---
> cc -O2 -pipe  -fstack-protector -fno-strict-aliasing -Wall -pedantic 
> dialog4ports.o mixedlist.o -o dialog4ports -lncursesw -lm -ldialog
> ===>  Staging for dialog4ports-0.1.6
> ===>   Generating temporary packing list
> install   -m 555 dialog4ports 
> /data/port-work/usr/ports/ports-mgmt/dialog4ports/work/stage/usr/local/bin
> install  -m 0644 dialog4ports.1.gz 
> /data/port-work/usr/ports/ports-mgmt/dialog4ports/work/stage/usr/local/man/man1
> > Compressing man pages (compress-man)
> root@>>   make install
> ===>  Installing for dialog4ports-0.1.6
> ===>  Checking if dialog4ports already installed
> ===>   Registering installation for dialog4ports-0.1.6
> Installing dialog4ports-0.1.6...
> Child process pid=6648 terminated abnormally: Bus error
> *** Error code 138
> 
> Stop.
> 
>   ... and pkg-static drops a core file.
>   I get this (with different pids) for _every_ port on "make install".
>   Never seen this before.  Google offered no possible causes.
>   "Bus error" means a memory violation - and I have no idea how to 
> proceed.  The core file has no debugging symbols, making a backtrace 
> useless.
> 

Let me guess, you have (NFSv4) ACLs enabled somewhere.  The HEAD was
supposedly fixed in r304075, but the change still was not merged to
stable/11.
___
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: Problems with out libgcc_s.so in base

[Konstantin Belousov]

On Fri, Aug 19, 2016 at 09:50:28PM +0200, Tijl Coosemans wrote:
> On Fri, 19 Aug 2016 10:28:14 +0300 Konstantin Belousov <kostik...@gmail.com> 
> wrote:
> > The option which would fix all this mess is:
> > 1. add rpath for gcc lib/ directory into spec file
> > and
> > 2. make ports collection use its own compiler instead of fighting with
> >the base.
> 
> That still doesn't cover all cases, e.g.:
> 
> port exec -> base lib -> libgcc_s.so.1
>   -> port lib -> recent libgcc_s.so.1
> 
> An example is:
> 
> % echo 'int main(void){}' > test.c
> % clang37 -o test test.c -lexecinfo -lgfortran -L/usr/local/lib/gcc5 
> -Wl,-rpath,/usr/local/lib/gcc5
> % ./test
> /lib/libgcc_s.so.1: version GCC_4.6.0 required by 
> /usr/local/lib/gcc5/libgfortran.so.3 not found
> 
> The base library (libexecinfo) doesn't have DT_RPATH or DT_RUNPATH so the
> only way rtld can find the right libgcc_s.so is if the executable (test)
> has DT_RPATH and no DT_RUNPATH.  Clang runs ld with --enable-new-dtags
> so the executable has DT_RUNPATH.  DT_RPATH is deprecated in the Linux
> world so there are probably more ports that use --enable-new-dtags.
> Another example seems to be Rust.

Indeed, and I rechecked the find_library() code against the latest gABI
once more.

So base libraries linked against libgcc_s are
/lib/libcxxrt.so.1
/usr/lib/libc++.so.1
/usr/lib/libexecinfo.so.1
/usr/lib/libprivatedevdctl.so.0
and only libexecinfo would be somewhat problematic.  libcxxrt and libc++
come from C++ runtime, which must be provided by the port's compiler,
the private library should not be linked to by behaving applications.

I suppose that libexecinfo pull unwinder from libgcc_s.  It might be
possible just dlopen() libgcc_s for _Unwind_Backtrace, it seems.
___
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: Problems with out libgcc_s.so in base

[Konstantin Belousov]

On Fri, Aug 19, 2016 at 01:14:32AM +0200, Tijl Coosemans wrote:
> On Thu, 18 Aug 2016 14:48:28 +0200 Dimitry Andric  wrote:
> > On 18 Aug 2016, at 11:15, Tijl Coosemans  wrote: 
> >> On Wed, 17 Aug 2016 14:17:10 -0700 Steve Kargl 
> >>  wrote:
> >>> % gfortran6 -o z foo.f90 && ./z
> >>> /lib/libgcc_s.so.1: version GCC_4.6.0 required by \
> >>> /usr/local/lib/gcc6/libgfortran.so.3 not found
> >>> % ldconfig -r | grep libgcc
> >>>6:-lgcc_s.1 => /lib/libgcc_s.so.1
> >>>735:-lgcc_s.1 => /usr/local/lib/gcc6/libgcc_s.so.1
> >>> 
> >>> Clearly, ldd is looking for 735 but finds 6.  If the lang/gcc6 could
> >>> be convinced to build, install, and use libgcc_s6.so.1, then the
> >>> problem is solved without a wrapper.  
> >> 
> >> In this case the real cause of the problem is that compilers and linkers
> >> search /lib and /usr/lib last and ldconfig searches them first.  Renaming
> >> the library is just a hack around that.  
> > 
> > Well, even if you would adjust the compilers and linkers to look in
> > /usr/local/lib first,
> 
> No, I wanted to change /etc/rc.d/ldconfig to put /lib and /usr/lib last.
> That would match base ld(1) so anything that links successfully at
> compile-time will also link successfully at run-time (if there are no
> other search order mismatches leading to conflicts).
> 
> But, this means that in case of a name conflict between base and ports,
> the ports provided library is assumed to be the right one.  I'm not 100%
> sure this is smart.  Usually the ports version of a library is more
> recent and if the name is the same it should be backward compatible, but
> if that's not the case (older or not compatible) base utilities may fail
> to run (like ./z in the example above) and that's maybe worse than ports
> or locally built programs failing.
> 
> > how would you solve the problem of having
> > multiple, possibly incompatible versions of the same library in
> > different directories?
> > 
> > For example, on one of my systems, I now have these:
> > 
> > /usr/local/lib/gcc47/libgcc_s.so.1
> > /usr/local/lib/gcc48/libgcc_s.so.1
> > /usr/local/lib/gcc49/libgcc_s.so.1
> > /usr/local/lib/gcc5/libgcc_s.so.1
> > /usr/local/lib/gcc6/libgcc_s.so.1
> > /usr/local/lib/gcc7/libgcc_s.so.1
> > 
> > So which one are you going to put at the front of the path?  The gcc7
> > version?  If you are lucky that one is backwards compatible with all the
> > previous ones, but still I would like it much better if a program
> > compiled by, say, gcc5 was linked *explicitly* against the gcc5 version
> > of libgcc_s.so.
> > 
> > Steve's proposed scheme solves that quite nicely, in my opinion.  The
> > problem is only in the details, as usual.  There will be many configure
> > scripts and libtool-like utilities out there, that assume libgcc must be
> > linked using -lgcc_s, not -lgcc_s$VERSION.
> 
> This is a separate problem that has been discussed many times before.
> The ports tree adds -Wl,-rpath to *FLAGS in several places to choose
> a library.  I now noticed there is a FAQ about this at
> https://gcc.gnu.org/faq.html#rpath.  It gives some suggestions including
> creating wrapper scripts, but they wouldn't work when code is compiled
> with gfortran but linked with Clang cc/c++.  The only thing that works
> in this case is -Wl,-rpath.  Another option would be to create a port
> that installs a recent version of libgcc in /usr/local/lib and let the
> gcc ports use that instead of their own copy.

The option which would fix all this mess is:
1. add rpath for gcc lib/ directory into spec file
and
2. make ports collection use its own compiler instead of fighting with
   the base.
___
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: sysutils/atop fails to build in head r302904 with poudriere

[Konstantin Belousov]

On Sun, Jul 17, 2016 at 10:40:17AM +0200, Matthias Apitz wrote:
> clang -O2 -pipe  -fstack-protector -fno-strict-aliasing -Wall -DFREEBSD -c 
> photoproc.c -o photoproc.o
> photoproc.c:397:51: error: use of undeclared identifier 'P_KTHREAD'
> ((pp->ki_flag & P_SYSTEM ) || (pp->ki_flag & P_KTHREAD)))
>  ^
> photoproc.c:464:75: error: use of undeclared identifier 'P_KTHREAD'
> if (filterkernel && ((pbase->ki_flag & P_SYSTEM ) || 
> (pbase->ki_flag & P_KTHREAD)))
>   
>  ^
> photoproc.c:577:74: error: use of undeclared identifier 'P_KTHREAD'
> if (filterkernel && ((pbase->ki_flag & P_SYSTEM ) || 
> (pbase->ki_flag & P_KTHREAD))) 
>   
>  ^
> photoproc.c:674:51: error: use of undeclared identifier 'P_KTHREAD'
> if ((pp->ki_flag & P_SYSTEM ) || (pp->ki_flag & P_KTHREAD))
> ^
> photoproc.c:690:44: error: use of undeclared identifier 'P_KTHREAD'
> curtask->cpu.rtprio = ((pp->ki_flag & P_KTHREAD) ? 
> pp->ki_pri.pri_native :
>   ^
> photoproc.c:694:44: error: use of undeclared identifier 'P_KTHREAD'
> curtask->cpu.rtprio = ((pp->ki_flag & P_KTHREAD) ? 
> pp->ki_pri.pri_native :

The flag was renamed to P_KPROC in HEAD/stable-12.
___
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: old ports/packages

[Konstantin Belousov]

On Sat, Jun 04, 2016 at 06:20:24PM +0100, Matthew Seaman wrote:
> On 2016/06/04 16:14, William A. Mahaffey III wrote:
> > One point of order if I may: It was stated earlier in the thread that
> > binary compatibility throughout a major release cycle (X.n-R, as 'n'
> > varies) is a specification. That is not explicitly addressed in the
> > above URL's, as far as I can see. Is that indeed considered a
> > specification ? If so, it would seem to satisfy the LTS desire
> > implicitly. TIA & have a good one.
> 
> At the moment we have a guarantee of binary compatibility for any
> software compiled on release X.n to be able to run on any release X.m
> where m >= n.  This is not going to change with the new support model.
> 
> ie. Something compiled for 11.0 will run on any subsequent 11.x release,
> but something compiled on 11.3 (say) would not necessarily run on 11.2.
>  Now, in fact, that sort of backwards compatibility usually does work,
> but it isn't guaranteed.  Putting in this sort of backwards incompatible
> change is something that is avoided unless there is some very good
> reason to introduce it.
> 
> Also recognize that libc.so in 11.x will support ABI multi-versions --
> so you can run anything that needs an earlier ABI version without any
> special configuration[*].  This does not apply to all of the shlibs
> provided by the system, so you may get mixed results depending on what
> your applications link against.
We ship libc.so+libpthread.so+libm.so+rtld which support backward
compatibility up to FreeBSD 7.0.  This means that the 'core' C runtime
is ABI-stable.

It is not true for the less 'core' FreeBSD shlibs indeed, but that other
libraries are typically OS-depended and are used for system management
or configuration.

More severe cause of ABI breakage are the third-party shlibs, which ABI
is not maintained by the project and which updates cause at least incompatible
shlib version bumps.  Examples are openssl and ncurses.

This explains the reason why the packages are still have to be build per
major branch.

> 
> This is why the FreeBSD packages are always built on the earliest still
> supported release from the same major branch.  The difference implied by
> the new support model is that the package building machines would be
> updated more frequently as they track the earliest still-supported
> release.  Practically speaking, as a pkg user you're unlikely to
> experience any difficulties even if you aren't up to date with your OS
> patching, but there may be some rare occasions where you will need to
> update your OS before you can update your ports.
> 
>   Cheers,
> 
>   Matthew
> 
> [*] IIRC the available version history goes back to 10.0-RELEASE; you'll
> definitely need compat libs for anything compiled earlier than that, but
> you may well be able to run 10.x applications on an 11.x system with no
> compatibility shims required.
> 



___
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: ports/pkg incompatibility, os/libc api changes

[Konstantin Belousov]

On Fri, Nov 06, 2015 at 10:34:27AM +0100, Norbert Koch wrote:
> Hello.
> 
> I am observing this on a system running FreeBSD 9.1:
> 
> If I build fontconfig from ports all is ok.
> 
> If I do pkg install fontconfig it does not work.
> 
> The reason is that fontconfig calls fcntl()
> with the parameter F_DUPFD_CLOEXEC. This has
> been introduced afaics since FreeBSD 9.2.
> 
> So, I obviously should update to 9.3 and all would be ok,
> but, due to different reasons, this is not a solution for me.
> 
> My question is:
> 
> Is it, according to FreeBSD policies,
> acceptable to change the os (or libc) api without
> changing FreeBSD's major version number?
Yes.

> 
> If yes, is there some documentation about potential
> problems like the one I found?
There is no formal statement about the guarantees the project provides,
but the essence is that the compatibility is backward (and not forward,
as you found).  In other words, we guarantee that a binary compiled and
worked on the previous version of the system, works on the newer version,
but not in reverse.  More, with the utilization of the symbol versioning,
binaries which only depend on the base C runtime, should be transportable
to the greater major versions as well.

The big exception is the binaries which utilize management interfaces,
e.g. there is no chance that ifconfig(8) would work on a different
version.

Your problem is due to the fontconfig binary was compiled on newer system
and then tried to run on older.

> Shouldn't pkg reject to install an incompatible package?
___
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: [HEADS-UP] switching default Perl to 5.22

[Konstantin Belousov]

On Fri, Aug 28, 2015 at 05:49:30PM +0200, Mathieu Arnold wrote:
 
 
 +--On 28 ao??t 2015 17:44:55 +0200 Mathieu Arnold m...@freebsd.org wrote:
 | +--On 28 ao??t 2015 17:34:49 +0200 Mark Martinec
 | mark.martinec+free...@ijs.si wrote:
 || 2015-08-28 17:16, Mathieu Arnold wrote:
 || +--On 28 ao??t 2015 17:13:34 +0200 Kurt Jaeger li...@opsec.eu wrote:
 || | | In one or two weeks, I'll be switching the default Perl version 
 || to
 || | | 5.22, and from now on, the new Perl will be added at the end of 
 || May
 || | | when released, and switched to at the beginning of September.
 || | | 
 || | | mod_perl is still broken with 5.22. Which is very sad. So maybe
 || | | it's premature to switch the default ?
 || | 
 || | But, it was building when I added Perl 5.22 in May, when did it 
 || break ?
 || | 
 || | ohauer marked it broken on the 9th of June.
 || 
 || Oh, maybe it did not work and I told myself never mind, mod_perl never
 || works anyway
 || 
 || The lang/perl5.20 will still be in ports, for anyone that needs it.
 || 
 || Being heavy Perl users we have switched to 5.22 when it hit the ports,
 || and I have no complaints about it.
 | 
 | Oh, yes, Perl 5.20 will still be until 2018-12-31, as will 5.18 until
 | 2017-12-31 and 5.16 until 2016-12-31 :-)
 
 Scratch that, remove one year for all those 0:-)

There is definitely some acrimony in the 5.22 release.  I only mention
Canary::Stability/stableperl bitter taste.  The TeXlive tlmgr tripped
over the cosmetic but annoying regression in 5.22, there were no fix
some time ago, despite the fact that the bug was known for porters for
long time, see http://www.perlmonks.org/?node_id=1132751 (the article
claims that the issue was fixed, I am not sure).

Previous policy, even if informal, was to wait for 5.xx.1 before bringing
the port to the tree.  May be, we should wait for xx.1 before switching
the default port, at least ?
___
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: The mystery of the missing library.

[Konstantin Belousov]

On Wed, Jul 29, 2015 at 07:46:14AM +0200, David Naylor wrote:
 On Tuesday, 28 July 2015 22:05:54 Bart??omiej Rutkowski wrote:
  I've checked how linux does it and it seems they're (at least Debian) 
 doing
  static linking - that would fix the issue, whatever it is. Can you adjust
  the port to do the static instead of dynamic linking binary?
 
 ```
 # cd /usr/local/bin
 
 # rm pypy 
   
 
 # ln ../pypy-2.6/bin/pypy 
   
 
 # ls -l pypy  
   
 -rwxr-xr-x  2 root  wheel  5152 Jul 28 22:10 pypy 
  
 
 # pypy
   
 Shared object libpypy-c.so not found, required by pypy
  
 
 # `which pypy`
   
 Shared object libpypy-c.so not found, required by pypy
 ```
 
 I had a look at Debian and they seem to have quite a large patchset 
 applied to pypy.  Perhaps they patch it to make it work?  
 
 Based on the documentation from pypy it appears they think a symlink 
 should work.  

There were relatively recent (as in, Feb 2015) changes to always resolve
symlinks for $ORIGIN expansion, using realpath.  The changes are in HEAD
and in stable/10, also in all 10.2 BETAs and RC.

What version of the userspace do you use ?  If not the versions listed
above, try them.  Hopefully, $ORIGIN starts behaving for you.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: Building www/rubygem-passenger inside Poudriere

[Konstantin Belousov]

On Mon, May 11, 2015 at 10:26:18PM +, Sergey A. Osokin wrote:
 Hi Patrick,
 
 I hope you're doing well too.
 The issue has been already reported
 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199953
 
 I'm closely working with Bryan Drewery bdrew...@freebsd.org on the issue.

I suspect that that similar or identical issue happens with the Berkeley
DB and WITH_BDB_VER. I use version 6 for my own needs, and portupgrade
correctly handled WITH_BDB_VER for p5-BerkeleyDB and other ports. I
tried to move my machines to packages from the poudriere builds, and
with the following content in poudriere.d/*make.conf
WITH_OPENSSL_PORT=true
WITH_BDB_VER=6
WANT_OPENLDAP_SASL=yes
DEFAULT_VERSIONS=perl5=5.20 ruby=2.2 pgsql=9.4
I see
 Ignoring databases/p5-BerkeleyDB: cannot install: no eligible BerkeleyDB 
version. Requested: 6, incompatible: . Try: make debug-bdb

The db6 port itself was built successfully.
Curiously, openldal-sasl did not cause troubles.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: PKG - Fail to kill children

[Konstantin Belousov]

On Mon, Jan 19, 2015 at 05:06:34PM +, Baptiste Daroussin wrote:
 January 19 2015 4:15 PM, Michael Jung mi...@mikej.com wrote: 
  On 2015-01-19 09:20, Michael Jung wrote:
  
  FreeBSD 10.1-RELEASE #0 r276896:
  pkg 1.4.4 or pkg 1.4.6
  poudriere 3.1.1 under 11.0-CURRENT r275419
  
  On i386 only pkg complains with Fail to kill children. I have
  checked some but not all packages
  and they appear to be updated as expected so this
  is a heads up.
  
 I do not understand your setting, but that means you have an old kernel 
 running a more recent userland (which is something unsupported btw :))
 
 So when building pkg is discovering it is being built on head (aka it support 
 the acquiring the reaper via procctl(2)) and assume it can use it. But your 
 kernel does not have support for that, hence the failure.
 
 Basically your host must always be newer that your jails

Would be useful for pkg to print the failed syscall name/basic mode and errno
in addition to its interpretation of the events.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: gnupg-2.1 - 2.1 appears to break decryption of saved messages

[Konstantin Belousov]

On Wed, Jan 07, 2015 at 07:16:12AM -0800, David Wolfskill wrote:
 On Wed, Jan 07, 2015 at 07:49:34AM -0600, Corey Halpin wrote:
  On 2014-11-20, David Wolfskill wrote:
  ...
   Then, a few minutes ago, I tried to retrieve a password from one of my
   saved encrypted messages... only to be informed Could not copy
   message.
  
I also enjoyed some friction trying to use gnupg 2.1 with mutt,
  though I didn't get the Could not copy message error that you
  report.
  
Instead I was seeing 'no secret key'.  In my case, this was resolved
  by following the advice at
https://wiki.archlinux.org/index.php/GnuPG#Unattended_passphrase .
 
 Thank you for digging further  reporting.
 
 I tried your suggestion, but still see the same failure.
 
 I then ran ktrace -di mutt ... to see what was going on (after
 replacing gnupg-2.0 with -2.1); that showed (after initialization):
 
 ...
   9268 gpg2 CALL  write(0x2,0x28c20800,0x28)
   9268 gpg2 GIO   fd 2 wrote 40 bytes
gpg: keydb_search failed: Invalid packet
   9268 gpg2 RET   write 40/0x28
   9268 gpg2 CALL  write(0x2,0x80d54e4,0x1)
   9268 gpg2 GIO   fd 2 wrote 1 byte


   9268 gpg2 RET   write 1
   9268 gpg2 CALL  write(0x2,0x28c20800,0x32)
   9268 gpg2 GIO   fd 2 wrote 50 bytes
gpg: encrypted with RSA key, ID 0xC0395DCCCFC71941
   9268 gpg2 RET   write 50/0x32
   9268 gpg2 CALL  write(0x2,0x80d70d1,0x1)
   9268 gpg2 GIO   fd 2 wrote 1 byte


   9268 gpg2 RET   write 1
   9268 gpg2 CALL  write(0x2,0x28c20800,0x25)
   9268 gpg2 GIO   fd 2 wrote 37 bytes
gpg: decryption failed: No secret key
   9268 gpg2 RET   write 37/0x25
   9268 gpg2 CALL  write(0x2,0x80dc2ea,0x1)
   9268 gpg2 GIO   fd 2 wrote 1 byte


   9268 gpg2 RET   write 1
   9268 gpg2 CALL  read(0x6,0x28c33000,0x2000)
   9268 gpg2 GIO   fd 6 read 0 bytes
 
   9263 mutt RET   fstat 0
   9263 mutt CALL  lseek(0x6,0,SEEK_SET,0)
   9263 mutt RET   lseek 0
   9263 mutt CALL  read(0x6,0x28d29000,0x1000)
   9263 mutt GIO   fd 6 read 130 bytes
gpg: keydb_search failed: Invalid packet
 gpg: encrypted with RSA key, ID 0xC0395DCCCFC71941
 gpg: decryption failed: No secret key

   9263 mutt RET   read 130/0x82
   9263 mutt CALL  read(0x6,0x28d29000,0x1000)
   9263 mutt GIO   fd 6 read 0 bytes
 ...
   9263 mutt CALL  write(0x1,0x28c40800,0x35)
   9263 mutt GIO   fd 1 wrote 53 bytes
0x 0d1b 5b33 316d 1b5b 3433 6d1b 5b31 6d44  |..[31m.[43m.[1mD|
0x0010 6563 7279 7074 696f 6e20 6661 696c 6564  |ecryption failed|
0x0020 1b5b 6d1b 5b33 393b 3439 6d1b 5b33 376d  |.[m.[39;49m.[37m|
0x0030 1b5b 3430 6d |.[40m|
 
   9263 mutt RET   write 53/0x35
   9263 mutt CALL  write(0x1,0x28c40800,0x1)
   9263 mutt GIO   fd 1 wrote 1 byte
0x 07   |.|
 
   9263 mutt RET   write 1
   9263 mutt CALL  write(0x1,0x28c40800,0x41)
   9263 mutt GIO   fd 1 wrote 65 bytes
0x 0d1b 5b33 316d 1b5b 3433 6d1b 5b31 6d43  |..[31m.[43m.[1mC|
0x0010 6f75 6c64 206e 6f74 2064 6563 7279 7074  |ould not decrypt|
0x0020 2050 4750 206d 6573 7361 6765 1b5b 6d1b  | PGP message.[m.|
0x0030 5b33 393b 3439 6d1b 5b33 376d 1b5b 3430  |[39;49m.[37m.[40|
0x0040 6d   |m|
 
   9263 mutt RET   write 65/0x41
   9263 mutt CALL  close(0x5)
 
 
Namely:
echo allow-loopback-pinentry  ~/.gnupg/gpg-agent.conf
 
 FWIW, I hadn't had a ~/.gnupg/gpg-agent.conf before doinbg that.
 
and editing my copy of mutt's gpg.rc to add '--pinentry-mode
  loopback' to every gpg invocation involving a passphrase-fd.
  
After that, things were back to normal for me.
  ...
 
 Unfortunately, that wasn't my experience.  I'll revert back to gnupg-2.0
 for now.

Invalid packet is a reaction to some 'invalid' key in some ring.
I used approximately the following procedure, for which I am unable
to find a reference right now.

mv .gnupg .gnupg-bad
mkdir .gnupg
mv .gnupg-bad/gpg.conf .gnupg/
gpg --import .gnupg-bad/secring.gpg
gpg --import .gnupg-bad/pubring.gpg
cp .gnupd/bad/trustdb.gpg .gnupg/

It was rather stressfull half of a hour while I thought that my private
keys are destroyed.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: [CFT] New upstream version of mplayer + mencoder

[Konstantin Belousov]

On Mon, Dec 29, 2014 at 09:35:37AM +0100, Thomas Zander wrote:
 On 29 December 2014 at 07:45, Matthias Apitz g...@unixarea.de wrote:
  btw: Is there a way to let the installed mplayer print the flags which
  have been used to compile?
 
 Not that I know of. mplayer itself does not store this information. Sorry

Mplayer does store something into the binary.  I am not sure how to obtain
this using mplayer command, but you can find this in the binary:
$ strings /usr/local/bin/mplayer | grep -e -L/usr
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: [CFT] New upstream version of mplayer + mencoder

[Konstantin Belousov]

On Thu, Dec 25, 2014 at 05:26:24PM +0100, Thomas Zander wrote:
 On 25 December 2014 at 16:09, Konstantin Belousov kostik...@gmail.com wrote:
  On Thu, Dec 25, 2014 at 02:42:26PM +0100, Thomas Zander wrote:
  - Remove -fomit-frame-pointer from CFLAGS (we have apparently a fair
number of CPUs out there which can't run code compiled with this
option reliably)
 
  Could you, please, explain this ?
 
 Unfortunately, I don't know yet why this happens. But I can point you
 to the PR where we narrowed the issue down. So far, it seems to affect
 various CPUs in 32 bit mode. If you have additional insights, I'd
 appreciate it. See here:
 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185560

The track in the PR does not contain clean summary, and I have troubles
making the conclusion from the vague info there.

I very much doubt that the problem is a CPU bug, it would be very
high-profile event and would be discovered much earlier then now,
esp. for Pentium IV class machines.

It seems that everything makes circles around stack alignment and SSE.
At least, this is strongly suggested by references to OCFLAGS and the
fact that -fomit-frame-pointer implicitely changes stack alignment.
SIGBUS is somewhat consistent with this observation.

This might be a compiler bug (what compiler ?  I cannot find a conclusive
answer in the PR), or more likely, it is a bug in inline assembler code,
which probably makes unwarranted assumptions about stack alignment.

Reporters must show the disassembly of the failed instruction and register
dump to confirm or deny my theory.  You might want to play with the
-mstackrealign compiler option.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: [CFT] New upstream version of mplayer + mencoder

[Konstantin Belousov]

On Thu, Dec 25, 2014 at 02:42:26PM +0100, Thomas Zander wrote:
 - Remove -fomit-frame-pointer from CFLAGS (we have apparently a fair
   number of CPUs out there which can't run code compiled with this
   option reliably)

Could you, please, explain this ?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: libgstreamer-0.10.so.0: Undefined symbol ppoll

[Konstantin Belousov]

On Sun, Dec 14, 2014 at 10:17:16AM +0200, Andriy Gapon wrote:
 
 I have a program linked to libgstreamer and after upgrading to the latest
 official packages (gstreamer-0.10.36_2) the program does not run anymore:
 /usr/local/lib/libgstreamer-0.10.so.0: Undefined symbol ppoll
 
 Indeed:
 $ nm -D /usr/local/lib/libgstreamer-0.10.so.0 | fgrep ppoll
  U ppoll
 
 I wonder what package provides a library that provides the required ppoll on
 FreeBSD.

The symbol is provided by libc.so.7.  What is your branch, and how old is
your world ?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: [HEADS-UP] svn commit: r373448 - in head: . Mk Mk/Uses archivers/dpkg archivers/p5-Archive-Any archivers/p5-Archive-Any-Lite archivers/p5-Archive-Any-Plugin-Rar archivers/p5-Archive-Extract archiv

[Konstantin Belousov]

On Wed, Nov 26, 2014 at 02:18:50PM +0100, Mathieu Arnold wrote:

It seems to be broken on the machine which has /usr/local symlinked.
Amd64 stable/10 with
lrwxr-xr-x   1 root  wheel 15 Sep 21 20:09 local - /usr/sfw/local8

I get the following

---  Installing the new version via the port with make flags: WITH_BDB_VER=6 
WANT_OPENLDAP_SASL=yes
===  Installing for p5-parent-0.228_1
===   p5-parent-0.228_1 depends on file: /usr/local/bin/perl5.20.1 - found
===   Registering installation for p5-parent-0.228_1
pkg-static: 
lstat(/usr/home/portworkdir/usr/bsd/ports/devel/p5-parent/work/stage/usr/local/./usr/local/lib/perl5/site_perl/mach/5.20/auto/parent/.packlist):
 No such file or directory
pkg-static: 
lstat(/usr/home/portworkdir/usr/bsd/ports/devel/p5-parent/work/stage/usr/local/./usr/local/lib/perl5/site_perl/mach/5.20/auto/parent/.packlist):
 No such file or directory
pkg-static: 
lstat(/usr/home/portworkdir/usr/bsd/ports/devel/p5-parent/work/stage/usr/local/./usr/local/lib/perl5/site_perl/mach/5.20/auto/parent/.packlist):
 No such file or directory
*** Error code 74

Stop.  
make[1]: stopped in /usr/bsd/ports/devel/p5-parent

On my other machines, where /usr/local is not symlinked, the update went
uneventful.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: [HEADS-UP] svn commit: r373448 - in head: . Mk Mk/Uses archivers/dpkg archivers/p5-Archive-Any archivers/p5-Archive-Any-Lite archivers/p5-Archive-Any-Plugin-Rar archivers/p5-Archive-Extract archiv

[Konstantin Belousov]

On Thu, Nov 27, 2014 at 03:41:55PM +0100, Mathieu Arnold wrote:
 +--On 27 novembre 2014 14:36:11 +0200 Konstantin Belousov
 kostik...@gmail.com wrote:
 | On Wed, Nov 26, 2014 at 02:18:50PM +0100, Mathieu Arnold wrote:
 | 
 | It seems to be broken on the machine which has /usr/local symlinked.
 | Amd64 stable/10 with
 | lrwxr-xr-x   1 root  wheel 15 Sep 21 20:09 local - /usr/sfw/local8
 | 
 | I get the following
 | 
 
 I think this was fixed in r373485.

I think it was not.

---  Installing the new version via the port with make flags: WITH_BDB_VER=6 
WANT_OPENLDAP_SASL=yes
===  Installing for p5-HTTP-Date-6.02_1
===   p5-HTTP-Date-6.02_1 depends on file: /usr/local/bin/perl5.20.1 - found
===   Registering installation for p5-HTTP-Date-6.02_1
pkg-static: 
lstat(/usr/home/portworkdir/usr/bsd/ports/www/p5-HTTP-Date/work/stage/usr/local/./usr/local/lib/perl5/site_perl/mach/5.20/auto/HTTP/Date/.packlist):
 No such file or directory
pkg-static: 
lstat(/usr/home/portworkdir/usr/bsd/ports/www/p5-HTTP-Date/work/stage/usr/local/./usr/local/lib/perl5/site_perl/mach/5.20/auto/HTTP/Date/.packlist):
 No such file or directory
*** Error code 74

Stop.
make[1]: stopped in /usr/bsd/ports/www/p5-HTTP-Date
*** Error code 1

Ports are at r373490, installed perl5-5.20.1_6.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: [HEADS-UP] svn commit: r373448 - in head: . Mk Mk/Uses archivers/dpkg archivers/p5-Archive-Any archivers/p5-Archive-Any-Lite archivers/p5-Archive-Any-Plugin-Rar archivers/p5-Archive-Extract archiv

[Konstantin Belousov]

On Thu, Nov 27, 2014 at 04:11:33PM +0100, Mathieu Arnold wrote:
 
 
 +--On 27 novembre 2014 17:01:42 +0200 Konstantin Belousov
 kostik...@gmail.com wrote:
 | On Thu, Nov 27, 2014 at 03:41:55PM +0100, Mathieu Arnold wrote:
 | +--On 27 novembre 2014 14:36:11 +0200 Konstantin Belousov
 | kostik...@gmail.com wrote:
 | | On Wed, Nov 26, 2014 at 02:18:50PM +0100, Mathieu Arnold wrote:
 | | 
 | | It seems to be broken on the machine which has /usr/local symlinked.
 | | Amd64 stable/10 with
 | | lrwxr-xr-x   1 root  wheel 15 Sep 21 20:09 local - /usr/sfw/local8
 | | 
 | | I get the following
 | | 
 | 
 | I think this was fixed in r373485.
 | 
 | I think it was not.
 | 
 | ---  Installing the new version via the port with make flags:
 | WITH_BDB_VER=6 WANT_OPENLDAP_SASL=yes ===  Installing for
 | p5-HTTP-Date-6.02_1
 | ===   p5-HTTP-Date-6.02_1 depends on file: /usr/local/bin/perl5.20.1 -
 | found ===   Registering installation for p5-HTTP-Date-6.02_1
 | pkg-static:
 | lstat(/usr/home/portworkdir/usr/bsd/ports/www/p5-HTTP-Date/work/stage/usr
 | /local/./usr/local/lib/perl5/site_perl/mach/5.20/auto/HTTP/Date/.packlist
 | ): No such file or directory pkg-static:
 | lstat(/usr/home/portworkdir/usr/bsd/ports/www/p5-HTTP-Date/work/stage/usr
 | /local/./usr/local/lib/perl5/site_perl/mach/5.20/auto/HTTP/Date/.packlist
 | ): No such file or directory *** Error code 74
 
 Are you sure your pkg-plist file doesn't have a ./usr/local/... line in it ?

Indeed, it has that line, and the problem was systematic, i.e. the ports'
checkout tree was massively damaged.

Thank you for the idea, but how that could happen ?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: rawrec fail - 10.1 breakage?

[Konstantin Belousov]

On Fri, Nov 21, 2014 at 08:46:47AM -0800, Jeff Anton wrote:
 I've been using the rawrec port and after the 10.1 upgrade it no longer 
 works.
 
 atlas.hesiod.org:anton[42]: rawrec
 (null): sigaction on SIGIO failed: Invalid argument
 
 I reinstalled with pkg install -f rawrec and built from the port and 
 still get the problem.
 
 10.0 worked ok, but 10.1 is failing.
 
 I don't have time to debug in detail right now, but this kind of failure 
 feels like an ABI breakage to me.  Other audio applications such as xmms 
 and mixer are working so it doesn't seem like a driver problem.
 
 Any clues?

I cannot provide you with clue without the problem being debugged.

A voice near me says that it could be due to uninitialized struct
sigaction' sa_flags. Before 10.1, unused bits in sa_flags where silently
ignored, while 10.1 started checking. If this is true, the program
triggered undefined behaviour, which is catched now.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: at - atrun utility bug on 10.0

[Konstantin Belousov]

On Sun, Oct 19, 2014 at 10:53:35AM -0700, Jim Pazarena wrote:
 I find that while a job is running via the at facility, that is,
 atrun has executed it, every subsequent execution of atrun (via
 cron) STAYS running while the original program (executed by atrun)
 is still active.
 
 Generally, according to the docs, atrun is executed every 5 minutes
 */5 * * * * within /etc/crontab
 I always modify this to * * * * * for more prompt at execution.
 
 I have jobs submitted via 'at' which tend to run for several hours
 sometimes even all day.
 If I do a 'ps wwax' I could see dozens, hundreds, even thousands
 of atrun running.
 When the original job completes all the atruns disappear.
 I noticed this on 10.0, where on 9.1 it simply does not happen.
 
 It is my feeling that the atrun on 10.0 is either being held up by
 a lock fyl, an flock, or something else which is blocking its
 normal termination when there is an empty queue, or rather when
 there is an item in the queue which is already being tended to
 by another process.
 
 I would think that the general */5 granularity of atrun, along with
 most jobs NOT running for multiple hours tends to obfuscate this
 (what I think is a) bug. And most people looking at an wwax would
 skip past it without giving it any thought.
 
 If anyone could confirm that I am not going insane, I would file a
 bug report thru normal channels. Of course, I may be going insane
 regardless of THIS email :-)

I doubt that port people can help you.

What version of FreeBSD do you run, exactly ?  It is 10.0 or stable/10 ?

It seems that your observations are sound, and your trouble is caused
by HEAD r251625.  OTOH, it seems that HEAD r264617, merged to stable/10
as r265368, fixed something which is described very similar to the bug
you hit.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: Need help compiling use of std::vector

[Konstantin Belousov]

On Wed, Sep 24, 2014 at 08:57:17PM +0200, Matthias Andree wrote:
 Am 24.09.2014 um 17:04 schrieb Shane Ambler:
  I am trying to compile the new version of a port I maintain and have
  trouble related to std::vector. The code producing the error can be
  boiled down to the following test case, which compiles as 64bit but
  fails as 32bit.
  
  #include stdlib.h
  #include vector
  
  int main(int argc, char *argv[])
  {
  int num_layers = 3;
  std::vectorconst char * layers (num_layers, NULL);
  
  exit(0);
  }
  
  So that should create a vector containing 3 items initially set to NULL.
  
  10.0 compiles ok - both 32 and 64 bit. (libc++)
  8.4, 9.2 and 9.3 compiles 64bit but fails on 32bit. (libstdc++)
  
  Using the above code
  clang++ -m32 test.cpp
  fails with
  
  /usr/include/c++/4.2/bits/stl_algobase.h:641:15: error: assigning to
  'const char *' from incompatible type 'const int'
 
 I don't think -m32 compilation has ever worked properly for C++ on the
 older FreeBSD releases, where older includes 9.3.
The headers for machine/x86 were only consilidated during 10-CURRENT.
The -m32 works on 10.0 and later, but not on stable/9.

 
 You're probably better off trying to build with 32-bit chroots or jails
 on your 64-bit host, like poudriere or Tinderbox are doing (but I'm not
 sure if they support setting up 32-bit jails on 64-bit computers).
 
 See here
 https://lists.freebsd.org/pipermail/freebsd-stable/2009-September/051855.html
 
 so it's a long-standing thing, and for recent developments:
 
 https://lists.freebsd.org/pipermail/freebsd-current/2013-June/042378.html
 -so that would have been for 10-CURRENT at the time, and hints that the
 headers weren't pure enough for -m32 and similar tricks.
 
 I am not aware that this effort was ever MFH'd.
No, it was not, and it will not be merged.

 
 I am Cc'ing Konstantin Belousov in case he wants to shed more light on
 this issue.
 
 HTH
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: Lots of installed ports show succeeds index

[Konstantin Belousov]

On Sat, Jul 26, 2014 at 09:57:49AM +0100, Matthew Seaman wrote:
 On 24/07/2014 18:19, Kevin Oberman wrote:
  If 'pkg version' only took a few seconds for you, I suspect  you had very
  few ports installed. It has always taken minutes for me.
  
  That said, '-P' is much slower than the old default, even though it is
  doing as close as possible to the same thing.
 
 The reason that the -P check is slower is because it now checks not just
 for the presence of the port directory, but also that the port is hooked
 up to the ports tree.  See
 
 https://github.com/freebsd/pkg/commit/2c84533f4d7291c26fe826a67217fb3c3ab446a5
 
 So you've got a choice here: slow and unreliable versus even slower, but
 correct.  Unfortunately the only way to extract version information from
 the ports involves running make(1) and that is intrinsically slow.

Am I right that it checks for the presence of a port in the category
directory, but possible absence of the same port in the category/Makefile ?
If yes, can this behaviour made optional ?


pgpJezo03jSdu.pgp
Description: PGP signature

Re: Lots of installed ports show succeeds index

[Konstantin Belousov]

On Wed, Jul 23, 2014 at 09:07:58PM +0200, Herbert J. Skuhra wrote:
 On Wed, 23 Jul 2014 21:03:14 +0200
 Herbert J. Skuhra wrote:
 
  Hi,
  
  is there anything wrong with svn0.eu.freebsd.org?
  
  After the latest 'svnlite up' I now get:
  
  GeoIP-1.4.8_7 succeeds index (index has 1.4.8_6)
  [...]
 
 'make fetchindex' resolved it. This is new?

It seems that 1.3 pkg version now uses index by default.
To get older behaviour, -P is needed, which seemingly regressed.
It takes now around 10 minutes to execute pkg version -vL= on
a machine which previously did it in tens of seconds.


pgpwmiiz6Han9.pgp
Description: PGP signature

Re: [hylafax-users] Hylafax on FreeBSD 100% CPU

[Konstantin Belousov]

There was quite good and encouraging progress made on the state
of the Hylafax for the FreeBSD, thanks to the efforts of Daren and Lee
Howard. I do not know when the next release of Hylafax come out with the
committed changes below, but whenever it happens, the port update to new
release should improve things.

The port accumulated quite a bit of problems, and most pressing issues
on FreeBSD with the 100% CPU time spent on FIFO reads, as well as
utmp-utmpx conversion, are fixed in upstream now.

There is no maintainer for the Hylafax port, I am forwarding this
message to ports@ in hope some motivated ports person will pick the
stuff.  My belief is that the programming issues are fixed, the
remaining work is packaging-related.

On Thu, Jul 10, 2014 at 06:07:35PM -0700, Lee Howard wrote:
 On 07/10/2014 01:39 AM, Konstantin Belousov wrote:
  On Thu, Jul 10, 2014 at 09:28:25AM +0100, Daren wrote:
  I had a quick go with your patch, but it didn't apply.  Having a quick
  look I believe it's simply an issue with the path to the hfaxd folder,
  so I'll have another look as soon as I get a little time.  I did also
  have a quick look at compiling version 5.5.5 (at first without the
  patch) but ran into issues straight away.  When compiling GettyBSD.c++,
  it's having a fatal error 'utmp.h' file not found.  A quick google
  suggests this was changed to utmpx.h in recent versions of FreeBSD and
  looking at the ports version of hylafax6, there's a few patches that
  need applying for that to compile properly (and although I can see what
  they do, I'm unsure why they do it!)  I'll try and have another go when
  I get a spare hour or two at work.
  This in fact means that FreeBSD port-specific patches should be upstreamed.
  But the ports does not have a maintainer.  Somebody needs to communicate
  the patches to the Hylafax developers.
 
 I've taken what little of those patches seemed appropriate for upstream 
 application and I've committed them:
 
 http://sourceforge.net/p/hylafax/HylaFAX+/2336/
 http://sourceforge.net/p/hylafax/HylaFAX+/2337/
 
 However, the real difference had to do with how the package in FreeBSD 
 ports was being built: --with-GETTY=SysV instead of the BSD default 
 that would get picked-up normally.  Since the SysVGetty supported utmpx 
 this worked.
 
 Nonetheless, I've updated the BSDGetty code in HylaFAX+ to support 
 utmpx.  So it can now be built with SysV or BSD Getty support, as may be 
 desired.  It seems to run fine with BSDGetty in my limited testing on a 
 FreeBSD 10 installation on a virtual machine using an iaxmodem.
 
 http://sourceforge.net/p/hylafax/HylaFAX+/2339/
 
 Daren, since you seem to have a working solution it may not matter to 
 you to mess around with any more testing.  You would have some limited 
 benefit in updating to HylaFAX+ code, but it may not be worth the effort 
 to you.  If you can easily mimick the build and installation from 
 FreeBSD ports, then updating should be no problem.  But it seems that 
 this may be a bit more struggle for you, and you may be happiest to just 
 remain with your working solution. I'll send you a tarball of the code 
 separately - saving you the effort of patching.  If you don't want to 
 use it, that's understandable and fine.
 
 If you (or anyone else) want to build and install HylaFAX+ on FreeBSD it 
 is this easy:
 
 ./configure -with-LIBTIFF=-L/usr/local/lib -ltiff 
 -with-TIFFINC=-I/usr/local/include  make  make install
 
 If you want to use SysV Getty instead of BSD Getty, then change the 
 configure command to:
 
 ./configure -with-LIBTIFF=-L/usr/local/lib -ltiff 
 -with-TIFFINC=-I/usr/local/include -with-GETTY=SysV
 
 It may be more-involved if you want to get things going like JBIG and 
 color fax support, etc.  Someone interested should really volunteer to 
 be the FreeBSD HylaFAX ports maintainer.
 
 Thanks,
 
 Lee.


pgpyIWT98s585.pgp
Description: PGP signature

Re: Hylafax on FreeBSD 10 and 100% CPU

[Konstantin Belousov]

On Thu, Jul 03, 2014 at 10:44:34AM +0100, Daren wrote:
 On 02/07/2014 23:24, Konstantin Belousov wrote:
  On Wed, Jul 02, 2014 at 10:35:16AM +0100, Daren wrote:
  Hi
 
  I've tried installing Hylafax from ports on fresh FreeBSD 10.  We
  previously had it running on an 8.2 system without issue.
 
  After starting faxgetty creeps up to and stays on 100% cpu.  I did find
  a previous PR for this
  (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166071) which has the
  status of resolved fixed although people have requested it be re-opened
  as the problem is still occurring for them as well.
 
  I can add another comment to this if it helps get it noticed again, but
  my knowledge with C etc is non-existent to be able to help with it,
  although searching has come up with a similar/same issue on dragonflybsd
  (http://bugs.dragonflybsd.org/issues/2028)
 
  Does anyone know if this is being looked at?
 
  
  I once looked at the source code of the program, and the ktrace reports
  in the mentioned PR 166071 are consistent with what I remember I saw in
  code, as well as what was discussed at that time.
  
  If you look at the kdump, you note the series of read(2) syscalls on the
  same FIFO, which return 0, the indicator of the EOF.  AFAIR, the Hylafax
  code does  not check for the EOF condition and just spins trying to
  read more data.  Select(2) returns the fd for EOF'ed FIFO ready, because
  the read(2) indeed does not block at EOF.
  
  My decision at that time was that the issue is the program bug.
  I do not use the program, and cannot set it up locally to even try
  coding the fix.
  
 
 Thanks for the answer.  Unfortunately I know nothing about these sorts
 of things so it doesn't mean much to me!
 
 I'll try posting to the hylafax list with this, but I'm sure I came
 across this previously mentioned to them on a search and they made out
 it was an OS bug - although now I cannot find it again.

I am happy to listen to the authors of this application, in particular,
I am interested in exact description of what behaviour do they expect.


pgpd3fst3O0hg.pgp
Description: PGP signature

Re: Hylafax on FreeBSD 10 and 100% CPU

[Konstantin Belousov]

On Wed, Jul 02, 2014 at 10:35:16AM +0100, Daren wrote:
 Hi
 
 I've tried installing Hylafax from ports on fresh FreeBSD 10.  We
 previously had it running on an 8.2 system without issue.
 
 After starting faxgetty creeps up to and stays on 100% cpu.  I did find
 a previous PR for this
 (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166071) which has the
 status of resolved fixed although people have requested it be re-opened
 as the problem is still occurring for them as well.
 
 I can add another comment to this if it helps get it noticed again, but
 my knowledge with C etc is non-existent to be able to help with it,
 although searching has come up with a similar/same issue on dragonflybsd
 (http://bugs.dragonflybsd.org/issues/2028)
 
 Does anyone know if this is being looked at?
 

I once looked at the source code of the program, and the ktrace reports
in the mentioned PR 166071 are consistent with what I remember I saw in
code, as well as what was discussed at that time.

If you look at the kdump, you note the series of read(2) syscalls on the
same FIFO, which return 0, the indicator of the EOF.  AFAIR, the Hylafax
code does  not check for the EOF condition and just spins trying to
read more data.  Select(2) returns the fd for EOF'ed FIFO ready, because
the read(2) indeed does not block at EOF.

My decision at that time was that the issue is the program bug.
I do not use the program, and cannot set it up locally to even try
coding the fix.


pgpYSHLjVeFDx.pgp
Description: PGP signature

bash usage of fdescfs [was: Re: amd64/188699: Dev tree]

[Konstantin Belousov]

On Mon, Apr 21, 2014 at 02:31:12PM -0400, John Baldwin wrote:
 On Thursday, April 17, 2014 2:50:01 pm Konstantin Belousov wrote:
  The following reply was made to PR amd64/188699; it has been noted by GNATS.
  
  From: Konstantin Belousov kostik...@gmail.com
  To: John Allman free...@hugme.org
  Cc: freebsd-gnats-sub...@freebsd.org
  Subject: Re: amd64/188699: Dev tree
  Date: Thu, 17 Apr 2014 21:44:52 +0300
  
   On Wed, Apr 16, 2014 at 05:32:45PM +, John Allman wrote:
This is how to reproduce it:

Fresh install of 10 on AMD 64
install bash `pkg install bash`
Switch to bash `bash`
push a here document into a loop: `while true ; do echo; done (echo 
  123)`
receive an error: -su: /dev/fd/62: No such file or directory

I'm sorry I haven't been able to research this any further. I found how 
  while working on some important matters. As I mentioned the above works 
  fine in all 
 previous versions of FreeBSD up until 10.
How-To-Repeat:
Fresh install
pkg install bash
bash
while true; do echo foo done (echo 123)

-su: /dev/fd/62: No such file or directory
   
   So do you have fdescfs mounted on /dev/fd on the machine where the
   test fails ?  It works for me on head, and if unmounted, I get the
   same failure message as yours.  I very much doubt that it has anything
   to do with a system version.
 
 Question I have is why is bash deciding to use /dev/fd/n and require
 fdescfs?  On older releases bash uses named pipes for this instead.

The aclocal.m4 contains the test which verifies the presence and usability
of /dev/fd/n for n=3 on the _build_ host.  The result of the test
is used on the installation host afterward.

Such kinds of bugs are endemic in our ports, but apparently upstreams
are guilty too.


pgpUx4zuqtj1y.pgp
Description: PGP signature

Re: bash usage of fdescfs [was: Re: amd64/188699: Dev tree]

[Konstantin Belousov]

On Mon, Apr 21, 2014 at 05:23:04PM -0400, John Baldwin wrote:
 On Monday, April 21, 2014 3:51:33 pm Konstantin Belousov wrote:
  On Mon, Apr 21, 2014 at 02:31:12PM -0400, John Baldwin wrote:
   On Thursday, April 17, 2014 2:50:01 pm Konstantin Belousov wrote:
The following reply was made to PR amd64/188699; it has been noted by 
 GNATS.

From: Konstantin Belousov kostik...@gmail.com
To: John Allman free...@hugme.org
Cc: freebsd-gnats-sub...@freebsd.org
Subject: Re: amd64/188699: Dev tree
Date: Thu, 17 Apr 2014 21:44:52 +0300

 On Wed, Apr 16, 2014 at 05:32:45PM +, John Allman wrote:
  This is how to reproduce it:
  
  Fresh install of 10 on AMD 64
  install bash `pkg install bash`
  Switch to bash `bash`
  push a here document into a loop: `while true ; do echo; done 
(echo 
 123)`
  receive an error: -su: /dev/fd/62: No such file or directory
  
  I'm sorry I haven't been able to research this any further. I found 
 how while working on some important matters. As I mentioned the above works 
 fine in all 
   previous versions of FreeBSD up until 10.
  How-To-Repeat:
  Fresh install
  pkg install bash
  bash
  while true; do echo foo done (echo 123)
  
  -su: /dev/fd/62: No such file or directory
 
 So do you have fdescfs mounted on /dev/fd on the machine where the
 test fails ?  It works for me on head, and if unmounted, I get the
 same failure message as yours.  I very much doubt that it has anything
 to do with a system version.
   
   Question I have is why is bash deciding to use /dev/fd/n and require
   fdescfs?  On older releases bash uses named pipes for this instead.
  
  The aclocal.m4 contains the test which verifies the presence and usability
  of /dev/fd/n for n=3 on the _build_ host.  The result of the test
  is used on the installation host afterward.
  
  Such kinds of bugs are endemic in our ports, but apparently upstreams
  are guilty too.
 
 Yuck, yuck.  Should we fix our default package builders to not mount fdescfs?

IMO, using /dev/fd is more efficient since it avoids pipe inode creation
for the 'document here' interpretation.  The /dev/fd is also needed for
fexecve(2) to work (with the shebang scripts).  Also, I believe that
some other high-profile ports require it (OpenJDK ?).

That said, the solution is to have fdescfs mounted on /dev/fd.
This probably should be done by an installer.


pgpnsguSJhZcD.pgp
Description: PGP signature

Re: bash usage of fdescfs [was: Re: amd64/188699: Dev tree]

[Konstantin Belousov]

On Mon, Apr 21, 2014 at 11:52:59PM +0200, Emanuel Haupt wrote:
 On 21/04/14 21:51, Konstantin Belousov wrote:
  On Mon, Apr 21, 2014 at 02:31:12PM -0400, John Baldwin wrote:
  On Thursday, April 17, 2014 2:50:01 pm Konstantin Belousov wrote:
  The following reply was made to PR amd64/188699; it has been noted by 
  GNATS.
 
  From: Konstantin Belousov kostik...@gmail.com
  To: John Allman free...@hugme.org
  Cc: freebsd-gnats-sub...@freebsd.org
  Subject: Re: amd64/188699: Dev tree
  Date: Thu, 17 Apr 2014 21:44:52 +0300
 
On Wed, Apr 16, 2014 at 05:32:45PM +, John Allman wrote:
 This is how to reproduce it:

 Fresh install of 10 on AMD 64
 install bash `pkg install bash`
 Switch to bash `bash`
 push a here document into a loop: `while true ; do echo; done (echo 
  123)`
 receive an error: -su: /dev/fd/62: No such file or directory

 I'm sorry I haven't been able to research this any further. I found 
  how while working on some important matters. As I mentioned the above 
  works fine in all
  previous versions of FreeBSD up until 10.
 How-To-Repeat:
 Fresh install
 pkg install bash
 bash
 while true; do echo foo done (echo 123)

 -su: /dev/fd/62: No such file or directory
 
So do you have fdescfs mounted on /dev/fd on the machine where the
test fails ?  It works for me on head, and if unmounted, I get the
same failure message as yours.  I very much doubt that it has anything
to do with a system version.
 
  Question I have is why is bash deciding to use /dev/fd/n and require
  fdescfs?  On older releases bash uses named pipes for this instead.
 
  The aclocal.m4 contains the test which verifies the presence and usability
  of /dev/fd/n for n=3 on the _build_ host.  The result of the test
  is used on the installation host afterward.
 
  Such kinds of bugs are endemic in our ports, but apparently upstreams
  are guilty too.
 
 Is there anything I can do to patch the bash port? I am more than happy 
 to implement a fix and contact upstream about the problem.

Ideally, upstream should test the presence of fdescfs mount at runtime,
instead of the compile time.  They already have unused have_devfd
variable.

The port could add the pkg installation message which would mention
the need of the mount, like it is done by openjdk ports currently.


pgpM_1FsY1dbp.pgp
Description: PGP signature

Re: net/avahi-app core dumps signal 11

[Konstantin Belousov]

On Fri, Jan 31, 2014 at 10:57:05PM +0100, Dimitry Andric wrote:
 On 31 Jan 2014, at 21:35, Dimitry Andric d...@freebsd.org wrote:
 ...
  Hmm, at least I can reproduce it, but the stack trace does not tell me that 
  much:
  
  (gdb) run
  Starting program: 
  /usr/work/share/dim/ports/net/avahi-app/work/avahi-0.6.31/./avahi-utils/.libs/avahi-browse
  [New LWP 101263]
  
  Program received signal SIGSEGV, Segmentation fault.
  [Switching to LWP 101263]
  _thr_cancel_enter (curthread=0x0) at 
  /share/dim/src/freebsd/head-clang34/lib/libthr/thread/thr_cancel.c:141
  141 curthread-cancel_point = 1;
  (gdb) bt
  #0  _thr_cancel_enter (curthread=0x0) at 
  /share/dim/src/freebsd/head-clang34/lib/libthr/thread/thr_cancel.c:141
  #1  0x280d0f2d in __open (path=optimized out, flags=optimized out)
 at 
  /share/dim/src/freebsd/head-clang34/lib/libthr/thread/thr_syscalls.c:390
  #2  0x280fef46 in __guard_setup () at 
  /share/dim/src/freebsd/head-clang34/gnu/lib/libssp/../../../contrib/gcclibs/libssp/ssp.c:72
  #3  0x280ff182 in ?? () from /lib/libssp.so.0
  #4  0x280fe749 in _init () from /lib/libssp.so.0
  #5  0x in ?? ()
  (gdb) up
  #1  0x280d0f2d in __open (path=optimized out, flags=optimized out)
 at 
  /share/dim/src/freebsd/head-clang34/lib/libthr/thread/thr_syscalls.c:390
  390 _thr_cancel_enter(curthread);
  (gdb) up
  #2  0x280fef46 in __guard_setup () at 
  /share/dim/src/freebsd/head-clang34/gnu/lib/libssp/../../../contrib/gcclibs/libssp/ssp.c:72
  72fd = open (/dev/urandom, O_RDONLY);
  
  E.g., __guard_setup() tries to get some random bytes from /dev/urandom
  (probably for the stack canaries), libthr considers this to be a thread
  cancellation point, but for some reason the current thread is zeroed
  out?  I don't think this is ever supposed to happen... :-)
 
 So avahi-browse gets linked as follows (wrapped a little for clarity): 
 
 cc -I.. -DDEBUG_TRAP=__asm__(\int \$3\)
 -DDATABASE_FILE=\/usr/local/lib/avahi/service-types.db\ -O2 -pipe
 -march=corei7 -g -fno-strict-aliasing -fstack-protector -std=c99 -Wall
 -W -Wextra -pedantic -pipe -Wformat -Wold-style-definition
 -Wdeclaration-after-statement -Wfloat-equal -Wmissing-declarations
 -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls
 -Wmissing-noreturn -Wshadow -Wendif-labels -Wpointer-arith
 -Wbad-function-cast -Wcast-qual -Wcast-align -Wwrite-strings
 -fdiagnostics-show-option -Wno-cast-qual -fno-strict-aliasing
 -o .libs/avahi-browse avahi_browse-avahi-browse.o avahi_browse-sigint.o
 avahi_browse-stdb.o -L/usr/local/lib
 ../avahi-client/.libs/libavahi-client.so /usr/local/lib/libdbus-1.so
 -lpthread
 /usr/work/share/dim/ports/net/avahi-app/work/avahi-0.6.31/avahi-common/.libs/libavahi-common.so
 ../avahi-common/.libs/libavahi-common.so /usr/local/lib/libgdbm.so -lssp
 /usr/local/lib/libintl.so -pthread -Wl,-rpath -Wl,/usr/local/lib
 
 This executable segfaults, and has the NEEDED libs in the following
 order:
 
 .libs/avahi-browse:
 libavahi-client.so.3 = /usr/local/lib/libavahi-client.so.3 
 (0x28076000)
 libdbus-1.so.3 = /usr/local/lib/libdbus-1.so.3 (0x28085000)
 libthr.so.3 = /lib/libthr.so.3 (0x280cf000)
 libavahi-common.so.3 = /usr/local/lib/libavahi-common.so.3 
 (0x280f1000)
 libgdbm.so.4 = /usr/local/lib/libgdbm.so.4 (0x280fc000)
 libssp.so.0 = /lib/libssp.so.0 (0x28106000)
 libintl.so.9 = /usr/local/lib/libintl.so.9 (0x28109000)
 libc.so.7 = /lib/libc.so.7 (0x28112000)
 
 When I remove the -lssp from the above linking command line, it is
 automatically induced anyway, but the executable then gets the following
 NEEDED libs order:
 
 .libs/avahi-browse:
 libavahi-client.so.3 = /usr/local/lib/libavahi-client.so.3 
 (0x28076000)
 libdbus-1.so.3 = /usr/local/lib/libdbus-1.so.3 (0x28085000)
 libthr.so.3 = /lib/libthr.so.3 (0x280cf000)
 libavahi-common.so.3 = /usr/local/lib/libavahi-common.so.3 
 (0x280f1000)
 libgdbm.so.4 = /usr/local/lib/libgdbm.so.4 (0x280fc000)
 libintl.so.9 = /usr/local/lib/libintl.so.9 (0x28106000)
 libc.so.7 = /lib/libc.so.7 (0x2810f000)
 libssp.so.0 = /lib/libssp.so.0 (0x28263000)
 
 E.g. libssp.so.0 is now located at the end of the list.  And _this_
 executable runs fine...!
 
 If anyone has a good explanation for this, I would be dying to know. :-)

This sounds as if libssp initializers were run before libthr was initialized.
Indeed, open(2) must be interposed by libthr to provide the cancellation
point.

Recompile rtld with debugging symbols and debugging enabled, like this:
cd libexec/rtld-elf
make DEBUG_FLAGS=-g DEBUG=-DDEBUG
and run both binaries with the LD_DEBUG=1 env variable set, than compare.


pgplETU3QU8oV.pgp
Description: PGP signature

Re: Problems with linking on FreeBSD-10

[Konstantin Belousov]

On Fri, Jan 31, 2014 at 12:19:46AM +, Montgomery-Smith, Stephen wrote:
 I maintain the port math/sage.  The port builds its own version of the
 libreadline library.  The port also uses lang/gcc instead of clang,
 because the port needs Fortran.
 
 The port is wanting to create a shared library called libR.so, which it
 wants to link with the libreadline library it created itself.  So it
 issues this kind of command:
 
 gcc46 -Wl,-rpath=path-of-newly-made-library -o libR.so -lreadline
 
 I have left out most of the command for brevity.
Not for brevity, but to make the diagnostic impossible.

 
 Unfortunately the libR.so pulls in /lib/libreadline - the version that
 comes with the base FreeBSD.  I thought that -rpath flag was supposed to
 tell the linker where to find the library.  But it doesn't.
Show exact commands and exact error message.  It is not possible to
understand from you message is the failure at the static linking (ld(1))
or dynamic (at the program startup) stage.

Just in case this might be useful:
- -rpath only affects runtime search path
- ld(1) search for libraries is directed with the -L path option.

 
 The failure is when using FreeBSD-10.  With FreeBSD-8 it works great.  I
 also assume that gcc46 uses /usr/local/bin/ld instead of /usr/bin/ld,
 since devel/binutils is a dependency of lang/gcc.
 
 Can anyone help me?  Is this a bug with FreeBSD?  Or is there some extra
 flag I can set with the linker to make it work?  I have tried
 -rpath-link and -z origin, but these were random guesses. and I don't
 really know what I am doing.
 
 Thanks, Stephen
 
 ___
 freebsd-ports@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


pgpBG4HKMt2lM.pgp
Description: PGP signature

Re: Position independent code and global destructor order (devel/ice)

[Konstantin Belousov]

On Sat, Nov 30, 2013 at 10:34:27PM +0100, Michael Gmelin wrote:
 We discussed this topic about half a year ago, but came to no
 conclusion. I CCed everyone who participated in the discussion back
 then.
 
 Since 10-RELEASE is around the corner and I'm trying to get devel/ice
 working on it, one more attempt:
 
 When -fPIC is used on objects that are linked into an executable (and
 not a shared library), the static destruction order guaranteed by the
 C++ standard is not followed. There is also no warning or error while
 building/linking. The end-result of this problem is subtle and will
 only surface on exit (at the end of runtime). When porting bigger
 projects (like Ice in my case), finding all those problems is really
 hard, since they're not reported at build time. It's not uncommon to
 set global CFLAGS in a build, and not every projects distinguishes
 between objects which will end up in shared libraries and those which
 will be linked to executables directly.
 
 In case of Ice this leads to crashes (bus error etc.) on exit,
 depending on the projects the results of this could be quite severe.
 The fix is to go through every Makefile of the project, basically
 creating a big patch that touches everything to work around this
 issue, hoping not to forget a single object file. Every user of the library
 and the generated code will have to do the same in their
 Makefiles/Cmakefiles/Jamfiles etc. It makes porting and using C++ code
 on FreeBSD hard and software that runs fine on other platforms will
 break for reasons people won't understand/will take them forever to
 debug.
 
 So is there anything that could be done to:
 
 a) Make -fPIC just work like it did before r211706?
or if this is not an option.
 b) Report an error when linking the executable, so that objects built
with -fPIC can't be used in that case/barf at compile time.
 
 I would appreciate any kind of constructive response at this point, the
 last I got was back in June: I think that we could revert the
 termination calls to the functions from the dso being unloaded, but
 this is quite unfortunate, since it will restore the endless series of
 'segfault at the process termination' reports.

If you provided link to the original discussion, it would take much less
energy and time to refresh the memory.

I looked over this, and I think that r211706 can be refined, by only
calling atexit hooks for 'wrong' dso when the call to __cxa_finalize()
is from the real dlclose(), as opposed to the process exit.  For me,
with the world where the patch is applied, your 'major tom' test passes.

Of course, when dso1 registers __cxa_atexit hook located in dso2, and
dso2 is unloaded before dso1, the hooks are called in the wrong order
still, but the only alternatives there are either crash or do not call
such hooks at all.

diff --git a/include/dlfcn.h b/include/dlfcn.h
index c508843..38957e2 100644
--- a/include/dlfcn.h
+++ b/include/dlfcn.h
@@ -53,7 +53,8 @@
 #defineRTLD_DI_SERINFO 4   /* Obtain search path info. */
 #defineRTLD_DI_SERINFOSIZE 5   /*  ... query for required 
space. */
 #defineRTLD_DI_ORIGIN  6   /* Obtain object origin */
-#defineRTLD_DI_MAX RTLD_DI_ORIGIN
+#defineRTLD_DI_GLOBALEXIT  7
+#defineRTLD_DI_MAX RTLD_DI_GLOBALEXIT
 
 /*
  * Special handle arguments for dlsym()/dlinfo().
diff --git a/lib/libc/stdlib/atexit.c b/lib/libc/stdlib/atexit.c
index 18c31c3..b08d1de 100644
--- a/lib/libc/stdlib/atexit.c
+++ b/lib/libc/stdlib/atexit.c
@@ -37,6 +37,7 @@ static char sccsid[] = @(#)atexit.c  8.2 (Berkeley) 7/3/94;
 __FBSDID($FreeBSD$);
 
 #include namespace.h
+#include dlfcn.h
 #include link.h
 #include stddef.h
 #include stdlib.h
@@ -162,8 +163,10 @@ __cxa_finalize(void *dso)
struct dl_phdr_info phdr_info;
struct atexit *p;
struct atexit_fn fn;
-   int n, has_phdr;
+   int n, has_phdr, global_exit;
 
+   global_exit = 0;
+   dlinfo(dso, RTLD_DI_GLOBALEXIT, global_exit);
if (dso != NULL)
has_phdr = _rtld_addr_phdr(dso, phdr_info);
else
@@ -177,8 +180,9 @@ __cxa_finalize(void *dso)
fn = p-fns[n];
if (dso != NULL  dso != fn.fn_dso) {
/* wrong DSO ? */
-   if (!has_phdr || !__elf_phdr_match_addr(
-   phdr_info, fn.fn_ptr.cxa_func))
+   if (!has_phdr || global_exit ||
+   !__elf_phdr_match_addr(phdr_info,
+   fn.fn_ptr.cxa_func))
continue;
}
/*
@@ -200,6 +204,6 @@ __cxa_finalize(void *dso)
if (dso == NULL)
_MUTEX_DESTROY(atexit_mutex);
 
-   if (has_phdr  __pthread_cxa_finalize != NULL)
+   if (has_phdr  !global_exit  

Re: Position independent code and global destructor order (devel/ice)

[Konstantin Belousov]

On Fri, Dec 06, 2013 at 03:25:52AM +0100, Michael Gmelin wrote:
 I tested your patch on 10-BETA2 and 10-BETA3. I built our complete
 production environment from scratch, ran a huge number of unit and
 integration tests. Everything works as expected, including Ice's
 Schwarz Counter implementation
 (http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Nifty_Counter).
 
 So as far as I can tell this fixes the problem, while still
 accomplishing the goals of r211706.

Great, thank you.

I think that the patch can be further simplified.  From what I understand
about __cxa_finalize(3) protocol, confirmed by LSB, __cxa_finalize(NULL)
must only be called at the process exit, once.  Than, libc can use the
call as an indication of the final call to finalize, avoiding need for
help from rtld.

Please test the patch below.  It is enough to rebuild libc only.

diff --git a/lib/libc/stdlib/atexit.c b/lib/libc/stdlib/atexit.c
index 18c31c3..01d09fe 100644
--- a/lib/libc/stdlib/atexit.c
+++ b/lib/libc/stdlib/atexit.c
@@ -151,6 +151,8 @@ __cxa_atexit(void (*func)(void *), void *arg, void *dso)
 #pragma weak __pthread_cxa_finalize
 void __pthread_cxa_finalize(const struct dl_phdr_info *);
 
+static int global_exit;
+
 /*
  * Call all handlers registered with __cxa_atexit for the shared
  * object owning 'dso'.  Note: if 'dso' is NULL, then all remaining
@@ -164,10 +166,12 @@ __cxa_finalize(void *dso)
struct atexit_fn fn;
int n, has_phdr;
 
-   if (dso != NULL)
+   if (dso != NULL) {
has_phdr = _rtld_addr_phdr(dso, phdr_info);
-   else
+   } else {
has_phdr = 0;
+   global_exit = 1;
+   }
 
_MUTEX_LOCK(atexit_mutex);
for (p = __atexit; p; p = p-next) {
@@ -177,8 +181,9 @@ __cxa_finalize(void *dso)
fn = p-fns[n];
if (dso != NULL  dso != fn.fn_dso) {
/* wrong DSO ? */
-   if (!has_phdr || !__elf_phdr_match_addr(
-   phdr_info, fn.fn_ptr.cxa_func))
+   if (!has_phdr || global_exit ||
+   !__elf_phdr_match_addr(phdr_info,
+   fn.fn_ptr.cxa_func))
continue;
}
/*
@@ -200,6 +205,6 @@ __cxa_finalize(void *dso)
if (dso == NULL)
_MUTEX_DESTROY(atexit_mutex);
 
-   if (has_phdr  __pthread_cxa_finalize != NULL)
+   if (has_phdr  !global_exit  __pthread_cxa_finalize != NULL)
__pthread_cxa_finalize(phdr_info);
 }


pgpJHXoUccp0j.pgp
Description: PGP signature

Re: Global destructor order problems

[Konstantin Belousov]

On Thu, Jun 27, 2013 at 03:41:48PM +0200, Dimitry Andric wrote:
 On 2013-06-27 01:56, Michael Gmelin wrote:
  On Thu, 27 Jun 2013 00:28:33 +0300
  Konstantin Belousov kostik...@gmail.com wrote:
 
  On Wed, Jun 26, 2013 at 11:17:41PM +0200, Michael Gmelin wrote:
  Are you both on the same architecture?
 
  I tested both on amd64 and i386. For i386, it was -m32 for clang, and
  native 32bit gcc 4.8.1, stock build from the tarball.
 
 
  For completeness sake I tested once more using various compilers
  including gcc 4.8.1 on 10-CURRENT amd64 (see below).
 
 I have now tested the lang/gcc44, 46, 47, 48 and 49 ports, on both i386
 and amd64. All result in the incorrect destructor order.

My build of gcc is stock, not from the ports.  Another detail, I built
the compiler on stable/9, but use it on both stable and current.  I am
very curious what makes the my build to generate the code which uses
PLT instead of direct reference, but have no time to investigate.

I think that we could revert the termination calls to the functions
from the dso being unloaded, but this is quite unfortunate, since it
will restore the endless series of 'segfault at the process termination'
reports.


pgp0dK4g8Uv87.pgp
Description: PGP signature

Re: Global destructor order problems (was: Re: Are ports supposed to build and run on 10-CURRENT?)

[Konstantin Belousov]

On Wed, Jun 26, 2013 at 09:26:09PM +0200, Dimitry Andric wrote:
 This revision is not in 9.1-RELEASE, but it is in 9-STABLE, so the
 problem can also be reproduced there.
...
 This is roughly gcc 4.3.0 and later.  For example, gcc 4.8 generates:
I just tested the thing with gcc 4.8 on up to date stable/9 and HEAD.
In both cases, major tom did not fail, at least not in the peculiar way.
The gcc-generated code passed the PLT address of the corresponding
destructor.

The r211706 intent is indeed to prevent a situation when the libc calls
the atexit(3)-registered termination function from dso which is already
unloaded.  This is apparently epidemic with PHP and similar environments.



pgpwWH7hGEgLY.pgp
Description: PGP signature

Re: Global destructor order problems (was: Re: Are ports supposed to build and run on 10-CURRENT?)

[Konstantin Belousov]

On Wed, Jun 26, 2013 at 10:51:37PM +0200, Michael Gmelin wrote:
 Could you replicate the problem using clang on stable/9 and HEAD? (I
 didn't test gcc  4.2.1 myself).
On stable no, it is not reproducable.  As I understand, stable clang is
3.2-something.

On HEAD with clang, I do see the indentation change and wrong order.


pgprltNqRk5hk.pgp
Description: PGP signature

Re: Global destructor order problems (was: Re: Are ports supposed to build and run on 10-CURRENT?)

[Konstantin Belousov]

On Wed, Jun 26, 2013 at 10:59:24PM +0200, Dimitry Andric wrote:
 On Jun 26, 2013, at 22:45, Konstantin Belousov kostik...@gmail.com wrote:
  On Wed, Jun 26, 2013 at 09:26:09PM +0200, Dimitry Andric wrote:
  This revision is not in 9.1-RELEASE, but it is in 9-STABLE, so the
  problem can also be reproduced there.
  ...
  This is roughly gcc 4.3.0 and later.  For example, gcc 4.8 generates:
  I just tested the thing with gcc 4.8 on up to date stable/9 and HEAD.
  In both cases, major tom did not fail, at least not in the peculiar way.
  The gcc-generated code passed the PLT address of the corresponding
  destructor.
 
 That is strange, did you compile the main program with -fPIC?  That is
 the problem case.  If you don't compile the main program with -fPIC, the
 problem will indeed not occur.

I just used the Makefile provided by the earlier message, and it contains
the -fPIC flag (which is strange thing to do on its own, binaries should
use -fPIE).

This is how the registration for the outer dtr looks for me, gcc 4.8.1/i386:

   0x08048763 +42:call   0x8048520 _ZN5OuterC1Ev@plt
   0x08048768 +47:lea0x28(%ebx),%eax
   0x0804876e +53:mov%eax,0x8(%esp)
   0x08048772 +57:lea0x34(%ebx),%eax
   0x08048778 +63:mov%eax,0x4(%esp)
   0x0804877c +67:mov-0x4(%ebx),%eax
   0x08048782 +73:mov%eax,(%esp)
   0x08048785 +76:call   0x8048500 __cxa_atexit@plt

ebx was set up earlier as the GOT pointer.


pgpX4Lvv7pEwG.pgp
Description: PGP signature

Re: Global destructor order problems (was: Re: Are ports supposed to build and run on 10-CURRENT?)

[Konstantin Belousov]

On Wed, Jun 26, 2013 at 11:17:41PM +0200, Michael Gmelin wrote:
 Are you both on the same architecture?

I tested both on amd64 and i386. For i386, it was -m32 for clang, and
native 32bit gcc 4.8.1, stock build from the tarball.



pgpx_vSDnRqU4.pgp
Description: PGP signature

Re: [CFH] FreeBSD 10 and ports

[Konstantin Belousov]

On Tue, Jun 11, 2013 at 02:50:03PM +0800, Martin Wilke wrote:
 
 Dear All,
 
 As we all know FreeBSD 10 brings a new compiler along, and for that we need 
 to get ports on the right
 track. I have done several exp-runs on the current src and we still have a 
 lot of fallouts. We
 would like to ask you to have a look [1] at the failed ports and help to fix 
 them. We will start this week
 an i386 exp-run to see how the status is.
 
 Thanks for your time.
 
 - Martin on behalf of portmgr
 
 [1]http://pointyhat-west.isc.freebsd.org/errorlogs/amd64-10-exp-latest/

Didn't a sort of consensus when switching to clang for base was
discussed, was that ports would start use a port-provided version of gcc
? The adoption of the ports gcc was stalled due to the unability to make
exp-runs, AFAIK.

What you are proposing is de-facto forking the whole open-source code
base. This cannot work, and in fact steals the FreeBSD resources for
something which has absolutely no relevance for FreeBSD project.

Ports should not be forced to use clang, either a ports gcc work
should be finished, or cc in HEAD switched back to gcc.  This is
de-facto blocker for the 10.0.


pgpTFwZ8p9HUp.pgp
Description: PGP signature

Re: Another Firefox 21.0 crash (new backtrace)

[Konstantin Belousov]

On Mon, Jun 03, 2013 at 12:15:43AM +0200, Dimitry Andric wrote:
 On Jun 2, 2013, at 23:31, Ted Faber fa...@lunabase.org wrote:
  On Sun, Jun 02, 2013 at 05:35:27PM +0200, Dimitry Andric wrote:
  As a better fix, please try dropping the attached file into the
  /usr/ports/www/firefox/files directory, then rebuild the firefox port
  from scratch, and reinstall it.
  
  That works as well - firefox runs with compat6x installed, but compliled
  with the patch to www/firefox .
  
  Thanks again for debugging this!
 
 
 Well, the mystery is not entirely solved, as Firefox does not crash with
 a similar failure on -current, even with the compat6x libc.so.6
 installed, and without the patch to osfile_unix_allthreads.jsm.
 
 So *something* is different in the way multiple versions of libc.so are
 handled, when they are loaded into the same process.  Kostik, maybe you
 have any idea?

The same library of different version loaded into the process address
space causes all sort of funny effects which are not very useful to
investigate in the details.  E.g., non-hidden private symbols both
function and data types which are also present in the earlier library
are resolved to the symbols from earlier library.  The split definitely
causes complicated and contradictory behaviour.

In other words, if not loading libc.so.6 makes the process behave, I
consider the case closed.


pgpUwuiVftagM.pgp
Description: PGP signature

Re: Kernel panic CURRENT r248596 at virtualbox-ose-kmod module load

[Konstantin Belousov]

On Sat, Mar 23, 2013 at 01:26:27PM +0200, Ivan Klymenko wrote:
 I have
 uname -a
 FreeBSD nonamehost 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r248596: Fri
 Mar 22 01:17:08 EET 2013
 ivan@nonamehost:/usr/obj/usr/src/sys/GENERIC  amd64
 
 I updated the ports tree to r314921 and recompiled virtualbox-ose-kmod
 
 After load the module a have kernel panic.
 
 Panic  String:  Lock  vm  object  not  exclusively   locked   @
 /usr/src/sys/vm/vm_page.c:1396
 
 http://pkgupdate.nevosoft.ru/backtrace.txt

This looks like a vbox issue, the driver did not properly locked
the object passed to the vm_page_alloc_contig().

If you want this fixed, you probably need to look up the code yourself,
compiling the vbox kld with debugging, finding the offending call
to vm_page_alloc_contig() and looking around it to see which object is
passed and why it is not locked.


pgpuAsk05vmKU.pgp
Description: PGP signature

Re: VirtualBox patch

[Konstantin Belousov]

On Tue, Mar 12, 2013 at 09:01:43AM -0300, Sergio de Almeida Lenzi wrote:
 Em Seg, 2013-03-11 ??s 10:28 +0100, Ferenc Balku escreveu:
 
  Hi Sergio!
  
  Awfully sorry to disturb You, but I have found this link via Google
  http://lists.freebsd.org/pipermail/freebsd-ports/2013-March/081979.html
  and can not find the patch to download a make VBox work again on our 
  FBSD10 test server.
  
  Can You please send me a link to download the patch.
  
  Thanks in advance,
  
  Best Regards
  
  Ferenc Balku
 
 
 No problem   I was travel business...
 here is the patch,
 the list does not allow attach files...
 
 go to the /usr/ports/emulators/virtualbox-ose-kmod,
 put the fix in the files directory with a name like ==
 patch-the-freebsd-kernel
 and do a make clean install
 ==
 --- src/VBox/Runtime/r0drv/freebsd/the-freebsd-kernel.h.orig
 2012-12-19 16:27:29.0 -0200
 +++ src/VBox/Runtime/r0drv/freebsd/the-freebsd-kernel.h 2013-03-09
 14:42:18.924039639 -0300
 @@ -50,6 +50,7 @@
  #include sys/unistd.h
  #include sys/kthread.h
  #include sys/lock.h
 +#include sys/rwlock.h
  #include sys/mutex.h
  #include sys/sched.h
  #include sys/callout.h
 @@ -70,6 +71,12 @@
  #include sys/resourcevar.h
  #include machine/cpu.h
  
 +/*
 +   fix VM_OBJ_LOCK
 +*/
 +#defineVM_OBJECT_LOCK(o) VM_OBJECT_RLOCK(o)
 +#defineVM_OBJECT_UNLOCK(o) VM_OBJECT_RUNLOCK(o)

This is definitely wrong. For the blind substitution, you should
use VM_OBJECT_WLOCK/VM_OBJECT_WUNLOCK.


pgpKwtPIFBhK3.pgp
Description: PGP signature

Re: VirtualBox patch

[Konstantin Belousov]

On Tue, Mar 12, 2013 at 04:58:34PM +0100, Bernhard Fr?hlich wrote:
 On Tue, Mar 12, 2013 at 4:17 PM, Konstantin Belousov
 kostik...@gmail.com wrote:
  On Tue, Mar 12, 2013 at 09:01:43AM -0300, Sergio de Almeida Lenzi wrote:
  Em Seg, 2013-03-11 ??s 10:28 +0100, Ferenc Balku escreveu:
 
   Hi Sergio!
  
   Awfully sorry to disturb You, but I have found this link via Google
   http://lists.freebsd.org/pipermail/freebsd-ports/2013-March/081979.html
   and can not find the patch to download a make VBox work again on our
   FBSD10 test server.
  
   Can You please send me a link to download the patch.
  
   Thanks in advance,
  
   Best Regards
  
   Ferenc Balku
 
 
  No problem   I was travel business...
  here is the patch,
  the list does not allow attach files...
 
  go to the /usr/ports/emulators/virtualbox-ose-kmod,
  put the fix in the files directory with a name like ==
  patch-the-freebsd-kernel
  and do a make clean install
  ==
  --- src/VBox/Runtime/r0drv/freebsd/the-freebsd-kernel.h.orig
  2012-12-19 16:27:29.0 -0200
  +++ src/VBox/Runtime/r0drv/freebsd/the-freebsd-kernel.h 2013-03-09
  14:42:18.924039639 -0300
  @@ -50,6 +50,7 @@
   #include sys/unistd.h
   #include sys/kthread.h
   #include sys/lock.h
  +#include sys/rwlock.h
   #include sys/mutex.h
   #include sys/sched.h
   #include sys/callout.h
  @@ -70,6 +71,12 @@
   #include sys/resourcevar.h
   #include machine/cpu.h
 
  +/*
  +   fix VM_OBJ_LOCK
  +*/
  +#defineVM_OBJECT_LOCK(o) VM_OBJECT_RLOCK(o)
  +#defineVM_OBJECT_UNLOCK(o) VM_OBJECT_RUNLOCK(o)
 
  This is definitely wrong. For the blind substitution, you should
  use VM_OBJECT_WLOCK/VM_OBJECT_WUNLOCK.
 
 It would be great if someone could come up with a proper patch.
 All I've seen so far looks wrong or hackish and I cannot add that
 to the port nor send it upstream to get it fixed for future releases.

The patch would be to replace all occurences of VM_OBJECT_LOCK with
VM_OBJECT_WLOCK, and VM_OBJECT_UNLOCK with VM_OBJECT_WUNLOCK.
I assume that vbox module does not assert the lock state.

Sorry, I am not set up to produce the patch, but it should just a
mechanical substitution.


pgpGWYQuAP85V.pgp
Description: PGP signature

Re: openssh-portable segmentation faults

[Konstantin Belousov]

On Fri, Feb 08, 2013 at 12:16:40AM +0100, Dimitry Andric wrote:
 This is exactly the same problem as reported in this thread about
 the security/pam_ssh_agent_auth port (rather long, beware):
 
http://lists.freebsd.org/pipermail/freebsd-stable/2013-January/071703.html
 
 Executive summary: we recently imported a strnvis() implementation from
 NetBSD, which has differently ordered arguments from the strnvis()
 implementation in OpenBSD.  When OpenSSH calls it with arguments ordered
 in the way OpenBSD expects, the function segfaults.
 
 I guess a similar approach as take in the above thread should be taken,
 e.g. rename the function in the port to openbsd_strnvis(), and have the
 port call that.  Or use macro trickery to swap the arguments... :)

I suggest taking a reverse approach, and rename our libc function to
e.g. NetBSD_strnvis(). This way, at least linking binaries would
result in the build-time failure. For shared libraries, we also get
some semi-helpful message from rtld which would allow to identify
the problem without obtaining the backtrace. Anyway, the porter will
see the issue cleanly.

This should be done before merging the libc changes to stable.


pgpu2SEEYuAEo.pgp
Description: PGP signature

Re: Help my maintainer timeout PRs

[Konstantin Belousov]

 This one is not under ports/, but still trivial:
 
 bin/168415: [PATCH] stdbuf(1) does not allow cmd with no parameters
 http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/168415

jlh could have not noticed it. Anyway, ports@ is definitely wrong for
src-related PR discussion.


pgpmGRuONJKtn.pgp
Description: PGP signature

Re: sshguard dumping core on 9-STABLE

[Konstantin Belousov]

On Thu, Jan 03, 2013 at 01:15:49PM +0200, Ion-Mihai Tetcu wrote:
 On Wed, 2 Jan 2013 20:27:46 +0200
 Konstantin Belousov kostik...@gmail.com wrote:
 
  On Wed, Jan 02, 2013 at 02:38:34PM +0200, Ion-Mihai Tetcu wrote:
   Hi,
   
   
   I'm seeing shhguard-ipfw sig 10 on start on my machines updated to
   9-STABLE (eg. FreeBSD 9.1-STABLE #5 r244924: Tue Jan  1 19:45:55
   EET 2013 :/usr/obj/usr/src/sys/GENERIC  amd64 ) while on some
   -PRERELEASE it's running fine. Anyone seeing something similar?
 
  Recompile libc with the debugging and get the backtrace again.
 
 
 Hm, here it is:
 
 Core was generated by `sshguard'.
 Program terminated with signal 10, Bus error.
 Reading symbols from /lib/libthr.so.3...done.
 Loaded symbols for /lib/libthr.so.3
 Reading symbols from /lib/libc.so.7...done.
 Loaded symbols for /lib/libc.so.7
 Reading symbols from /libexec/ld-elf.so.1...done.
 Loaded symbols for /libexec/ld-elf.so.1
 #0  getenv (name=0x800b9267b TZ) at /usr/src/lib/libc/stdlib/getenv.c:438
 438 if (environ == NULL || environ[0] == NULL)
 [New Thread 801007800 (LWP 100516/sshguard)]
 [New Thread 801007400 (LWP 100507/sshguard)]
 (gdb) bt full
 #0  getenv (name=0x800b9267b TZ) at /usr/src/lib/libc/stdlib/getenv.c:438
 envNdx = value optimized out

What is the value of the 'environ' variable ?  And 'environ[0]' ?


pgp7eTWwWrKFk.pgp
Description: PGP signature

Re: sshguard dumping core on 9-STABLE

[Konstantin Belousov]

On Wed, Jan 02, 2013 at 02:38:34PM +0200, Ion-Mihai Tetcu wrote:
 Hi,
 
 
 I'm seeing shhguard-ipfw sig 10 on start on my machines updated to 9-STABLE 
 (eg. 
  FreeBSD 9.1-STABLE #5 r244924: Tue Jan  1 19:45:55 EET 2013 
 :/usr/obj/usr/src/sys/GENERIC  amd64
 ) while on some -PRERELEASE it's running fine.
 Anyone seeing something similar?
 
 
 
 #0  0x000800b7dced in getenv () from /lib/libc.so.7
 [New Thread 801007800 (LWP 100290/sshguard)]
 [New Thread 801007400 (LWP 100146/sshguard)]
 (gdb) bt full
 #0  0x000800b7dced in getenv () from /lib/libc.so.7
 No symbol table info available.
 #1  0x000800b61e11 in tzsetwall () from /lib/libc.so.7
 No symbol table info available.
 #2  0x000800b62112 in localtime_r () from /lib/libc.so.7
 No symbol table info available.
 #3  0x000800b62270 in ctime_r () from /lib/libc.so.7
 No symbol table info available.
 #4  0x000800b5d938 in vsyslog () from /lib/libc.so.7
 No symbol table info available.
 #5  0x000800b5d838 in syslog () from /lib/libc.so.7
 No symbol table info available.
 #6  0x00403c6f in sshguard_log (prio=5, fmt=0x40aea0 Started 
 successfully [(a,p,s)=(%u, %u, %u)], now ready to scan.) at 
 sshguard_log.c:129
 ap = {{gp_offset = 40, fp_offset = 48, overflow_arg_area = 
 0x7fffd030, reg_save_area = 0x7fffcf50}}
 __func__ = sshguard_log
 #7  0x00402516 in main (argc=16907520, argv=0x80101d080) at 
 sshguard.c:222
 tid = 0x801007800
 retv = 775238193
 source_id = 32767
 buf = '\0' repeats 72 times, 
 {Wd\000\b\000\000\000\000\000\000\000\002\000\002\000\br?\000\b\000\000\000\200\177\000\000\000?e\000\b\000\000\000\220\177\000\\177\000\000\000\000\000\000\000\000\000\000?zd\000\b,
  '\0' repeats 21 times, d\000\b, '\0' repeats 29 times, 
 d\000\b\000\000\000\030\203\205\000\b\000\000\0008u©\000\b, '\0' repeats 
 44 times, 
 \221e\000\b\000\000\000\020\177\000\000?\177\000\000\000\000\000\000\000\000\000\000?\177\000\000W{d\000\b\000\000\000?\020@\000\000\000\000\000\004?\212\006\000\000\000\000??\217?\000\000...
   

Recompile libc with the debugging and get the backtrace again.


pgptz9ToyaqHX.pgp
Description: PGP signature

Re: net-p2p/retroshare VoIP plugin: Undefined symbol

[Konstantin Belousov]

On Sat, Nov 03, 2012 at 01:59:18PM +0100, Peter Klett wrote:
 
 Hi All,
 
 I'm currently trying to get the VoIP plugin from RetroShare to work 
 under FreeBSD.
 After this patch I was able to build it:
 
 --- plugins/VOIP/services/rsvoipitems.cc~   2012-02-26 
 18:13:54.0 +0100
 +++ plugins/VOIP/services/rsvoipitems.cc2012-10-29 
 12:53:56.650925587 +0100
 @@ -182,7 +182,7 @@
  ok = setRawUInt32(data, tlvsize, offset, flags);
  ok = setRawUInt32(data, tlvsize, offset, data_size);
   std::cerr  data_size :   data_size  std::endl;
 -memcpy(data+offset,voip_data,data_size) ;
 +memcpy(((uint8_t*)data)[offset],voip_data,data_size) ;
  offset += data_size ;
 
  if (offset != tlvsize)
 
 But I can't get RetroShare to load it:
 
 Cannot open plugin: /home/user/.retroshare/extensions/libVOIP.so: 
 Undefined symbol _ZN9p3Service7receiveEP9RsRawItem
 
 Now the symbol is part of the RetroShare binary:
 
 $ grep _ZN9p3Service7receiveEP9RsRawItem 
 work/trunk/retroshare-gui/src/RetroShare
 Binary file work/trunk/retroshare-gui/src/RetroShare matches
 
 but somehow the symbols from the main binary do not get exported to the 
 plugin.
 The FreeBSD man page for dlopen(3) states in the NOTES section
 
 ELF executables need to be linked using the -export-dynamic option to
 ld(1) for symbols defined in the executable to become visible to 
 dlsym().
 
 
 So I rebuilt RetroShare with the -export-dynamic option, and the symbol 
 is part of the symbol table:
 
 $ objdump -t work/trunk/retroshare-gui/src/RetroShare | grep 
 _ZN9p3Service7receiveEP9RsRawItem
 00809580 g F .text  00c7  
 _ZN9p3Service7receiveEP9RsRawItem
 
 but still to no avail (same undefined symbol error).
 My knowledge of ELF binaries is pretty sparse, so if someone has more 
 clues, I would appreciate sharing :)

The objdump -t dumps wrong table. You want to examine the output of -T
AKA --dynamic-syms.


pgpPoCweZVYHj.pgp
Description: PGP signature

Re: Possible regression in i386 build with gcc 4.6

[Konstantin Belousov]

On Wed, Oct 03, 2012 at 04:50:58AM +0930, Shane Ambler wrote:
 I found a situation where gcc v4.2 compiles a i386 working binary and
 v4.6 doesn't. (Currently 4.7 and 4.8 fail to build this code) I have
 verified that this happens with 8.2/8.3/9.0 i386 systems. x86_64
 versions build without issue as does clang i386/x86_64.
 
 It appears that the x86_64 target of gcc offers gcc atomics while the
 i386 target doesn't - and this appears to be a freebsd specific setup,
 the i386 targets then fall back to using tbb atomics.
 
 Is this some subtle bug I'm missing? can it be alleviated with compiler
 flags/more universal code?
 
 I have tried to cut this down to just the call that triggers a
 segmentation fault but the one call itself isn't enough.
 
 The issue can be found in graphics/openimageio. The easiest way I know
 to cause the segmentation fault is with the image viewer that is part of
 the port (it is a Qt app) it seg faults during startup. There is no need
 to open any images just starting iv with an empty window is fine.
 
 The makefile is setup to USE_GCC=4.6+ for i386/8.2 - this is a leftover
 from earlier versions that will be removed next update.
 
 cd /usr/ports/graphics/openimageio
 make
 ./work/.build/iv/iv
 
 The error appears to stem from line 193 of src/libutil/ustring.cpp
 
 atomic_exchange_and_add (ustring_stats_constructed, 1);
 
 Commenting this line prevents the crash but isn't a valid fix.
 the relevant function it calls is -- src/include/thread.h:283
 which uses the atomic class template from tbb for the i386 build.
 
 inline long long
 atomic_exchange_and_add (volatile long long *at, long long x)
 {
 #ifdef USE_GCC_ATOMICS
  return __sync_fetch_and_add (at, x);
 #elif USE_TBB
  atomiclong long *a = (atomiclong long *)at;
  return a-fetch_and_add (x);
 #elif defined(__APPLE__)
snip
 #endif
 }
The in-tree gcc is indeed defaults to the -march=486. I think that the ports
gcc lacks several customizations. At least we recently updates specs
to include both SysV and GNU hash tables, as well as enabled new dtags.
There are probably more small things.

The right solution, obviously, is to push these customizations into the
gcc source.


pgpui0CHpikuu.pgp
Description: PGP signature

Re: [PATCH] unbreak imake build when clang set as base compiler

[Konstantin Belousov]

On Wed, Sep 26, 2012 at 11:10:25AM +0200, Niclas Zeising wrote:
 On 2012-09-26 01:13, Eitan Adler wrote:
  On 25 September 2012 18:45, Garrett Cooper yaneg...@gmail.com wrote:
  On Tue, Sep 25, 2012 at 3:37 PM, Oliver Pinter oliver.p...@gmail.com 
  wrote:
  Hi all!
 
  This patch fixed the problem, when buildig imake on a machine where
  clang is the base the compiler (WITH_CLANG_IS_CC).
 
  (Picking a random message to reply to) Why not create PRs and CC the
  relevant parties?
 
 The issue, as Jan pointed out in another thread, is that ucpp isn't
 compatible with gnu cpp either.  It causes other issues, the only
 difference is that it passes the configure script test.
 In my opinion, the solution to this problem is to fix the (X11) ports
 that abuse cpp, and deprecate imake.
This is not a solution as well. The imake is usable and used on its own
for miriad of proprietary X/motif software. Removing it from ports is
no-go.

Not all useful software lives in ports, FYI.

 
 Also, don't cross post ports issues to current@
 Regards!
 -- 
 Niclas
 ___
 freebsd-...@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-x11
 To unsubscribe, send any mail to freebsd-x11-unsubscr...@freebsd.org


pgpAFw1crTuZU.pgp
Description: PGP signature

Re: Building with WITH_DEBUG (-g) in make.conf

[Konstantin Belousov]

On Tue, Sep 04, 2012 at 11:50:35PM +0200, Dimitry Andric wrote:
 On 2012-09-04 17:53, Eitan Adler wrote:
 On 4 September 2012 05:26, Jake Smith j...@avenue22.net wrote:
 ...
 It got me thinking, is there any reason why it would be a bad idea to 
 build
 all my ports with debug symbols from now on?
 
 Are there any performance hits
 
 Yes. Code size grows and the flags may enable internal
 debugging in the program itself.
 
 There's a difference between just using '-g', which should never change
 the behaviour of the program at runtime, and adding -DDEBUG or similar
 flags on the command line, which may or may not enable extra code, or
 even cause totally different code paths.
 
 What is not different, is that both -g and other debugging options will
 generally cause compiling and linking to take longer, since these stages
 will have to process the additional debug information.
 
 
 or security risks with this?
 
 no.
 
 You cannot know in general.  If debug options enable a different code
 path, you might as well get a security problem with it for free. :)
 
 I have seen many debug printf's which could easily be exploited for
 buffer overruns, etc.
 
 However, only using '-g' should make no difference, indeed.
To nitpick, this is not true if you have code that explicitely
tries to use dwarf information from the resulting binary.
Think e.g. libunwind which can be configured to use .debug
sections.


pgpIAJr4owDvt.pgp
Description: PGP signature

Re: apcupsd compile fails on 9-stable amd64

[Konstantin Belousov]

On Tue, Aug 28, 2012 at 11:46:31AM +0300, Ion-Mihai Tetcu wrote:
 On Sat, 25 Aug 2012 14:01:09 -0600 (MDT)
 Warren Block wbl...@wonkity.com wrote:
 
  On Sat, 25 Aug 2012, Oleg Ginzburg wrote:
  
   On Saturday 25 August 2012 18:06:29 Warren Block wrote:
   Discovered last night that sysutils/apcupsd will not compile on
   9-stable amd64 if the USB or SNMP options are enabled.  It does
   compile on 8.3-stable i386.  Stock gcc, not clang.  ccache is
   installed, but not used for ports.  Any suggestions?
  
   ...
  CXX   src/apcupsd.c
  CXX   src/apcnis.c
  LDsrc/apcupsd
   /usr/ports/sysutils/apcupsd/work/apcupsd-3.14.10/src/drivers/libdrivers.a(s
   nmp.o): In function
   `Snmp::VarBindList::VarBindList(Asn::Sequence)':
   snmp.cpp:(.text+0x7a8): undefined reference to `operator
   new[](unsigned
   long)' 
   /usr/ports/sysutils/apcupsd/work/apcupsd-3.14.10/src/drivers/libdrivers.a(
snmp.o):
   In function `Snmp::VarBindList::Append(Asn::ObjectId const,
   Snmp::Variable*)': snmp.cpp:(.text+0xdc9): undefined reference to
   `operator new[](unsigned
   long)' 
   /usr/ports/sysutils/apcupsd/work/apcupsd-3.14.10/src/drivers/libdrivers.a(
snmp.o):
   In function `Snmp::VarBindList::VarBindList(Asn::Sequence)':
   snmp.cpp:(.text+0xec8): undefined reference to `operator
   new[](unsigned
   long)' 
   /usr/ports/sysutils/apcupsd/work/apcupsd-3.14.10/src/drivers/libdrivers.a(
asn.o):
   In function `Asn::Sequence::assign(Asn::Sequence const)':
   asn.cpp:(.text+0x73d): undefined reference to `operator
   new[](unsigned
   long)' 
   /usr/ports/sysutils/apcupsd/work/apcupsd-3.14.10/src/drivers/libdrivers.a(
asn.o):
   In function `Asn::ObjectId::demarshal(unsigned char*, unsigned
   int)': asn.cpp:(.text+0x82b): undefined reference to `operator
   new[](unsigned
   long)' 
   /usr/ports/sysutils/apcupsd/work/apcupsd-3.14.10/src/drivers/libdrivers.a(
asn.o):asn.cpp:(.text+0x934):
   more undefined references to `operator new[](unsigned long)' follow
  
   Ive already register PR for this: http://www.freebsd.org/cgi/query-
   pr.cgi?pr=ports/170522
  
  Sorry, saw that last night, but forgot about it.  The fix works for
  me. Thanks!
 
 Thanks for confirming 

I do not think the 'fix' is right one. The issue there is that C compiler
driver is used to link object files generated by C++ compiler. Basically,
you need to change $(CC) to $(CXX) somewhere for LD.


pgpuo8lvsURrY.pgp
Description: PGP signature

Re: __FreeBSD_version bump? (was: Re: vlc 2.0.3 ProjectM path fix)

[Konstantin Belousov]

On Sat, Aug 18, 2012 at 10:45:10PM +0200, Juergen Lock wrote:
 On Wed, Aug 15, 2012 at 10:09:59AM -0700, Kevin Oberman wrote:
  On Wed, Aug 15, 2012 at 5:01 AM, Juergen Lock n...@jelal.kn-bremen.de 
  wrote:
   On Tue, Aug 14, 2012 at 09:54:54PM +0200, Olli Hauer wrote:
   ...
I think I got it: It is only a problem of configuring in the running
vlc. You have to set the right path under
'Settings','All','Audio','Visualizing','projectM'. That's all ;-)
   
Aah-haah! :)  I've fixed the default paths and made a new patch:
   
http://people.freebsd.org/~nox/tmp/vlc-2.0.3-010.patch
   
  
  
   From your patch:
workaround is to deinstall the old vlc-1.x version before building
the new one.
  
   What about a conflict line ?
   CONFLICTS_BUILD=${PORTNAME}-1.*
  
   This allows users to fetch the source but they have to deinstall the
   old version before building the new one.
  
   Hm well the rtld bug this workaround is for only affects the
   pulseaudio and notify knobs, and the workaround doesn't work for
   the notify knob so it would only cover half the cases, and also
   checking if this is needed in the port would require a
   __FreeBSD_version bump which is probably overkill for this bug.
  
  And why is it overkill? I regularly see comments about not wanting to
  bump __FreeBSD_version, but it's just an integer (though presented as
  a fixed-point fraction). There is no shortage and I never have
  understood why people are so hesitant to change it when there is a
  real, even if fairly small benefit from the bump.
 
 Hmm.  Alexander, what do you think?

Not being Alexander, but appeared on Cc:.

IMO, bumping __FreeBSD_version should not be done frivolous, and routine
bug fixes are definitely not the good reason to bump.

For one, users of HEAD or stable are assumed to run tip of the branch.
If you want defined point of the branch, use release. With this POV,
the usefulness of the bump for bug fix is only a week or two.

Second, bump of __FreeBSD_version signifies major incompatibility between
pre-bumped tree and current one. In the kernel, each bump of version in HEAD
means that new modules cannot be loaded into new kernel.

Bumping for bug fixes is a misuse of the mechanism which was put there
to provide information about major changes in system. For small or
detectable items, use autoconf-like runtime (or build-time *) tests.

* - Usually, the tests must be run-time, and not build-time. This bug is
greatly amplified by use of __FreeBSD_version. The case that initiated
the discussion is probably the first time I ever saw the when build-time
test makes some sense.


pgpoRahquxJaz.pgp
Description: PGP signature

Re: Segfault in rtld - dlopen RTLD_LAZY (was: Re: CFT: vlc 2.0.3 - want to know where it works and where only partly)

[Konstantin Belousov]

On Mon, Aug 13, 2012 at 01:13:35AM +0200, Juergen Lock wrote:
 On Sun, Aug 05, 2012 at 07:38:11PM +0200, Juergen Lock wrote:
  On Sun, Aug 05, 2012 at 07:13:53PM +0300, Konstantin Belousov wrote:
   On Sun, Aug 05, 2012 at 05:31:19PM +0200, Juergen Lock wrote:
Hi kib, -current, seems we have a segfault in rtld when updating
the multimedia/vlc port from the version currently in ports to the
2.0.3 CFT version from here:

http://people.freebsd.org/~nox/tmp/vlc-2.0.3-006.patch

(If you test the LIVEMEDIA knob you also need this update:

http://people.freebsd.org/~nox/tmp/livemedia-20120404-001.patch

)
   Please do two things.
   
   1. Provide me the output of readelf -a for the module that was loaded.
   
   2. Recompile rtld with debug symbols and redo the build to get the useful
   backtrace from core:
 cd /usr/src/libexec/rtld-elf
 make clean
 make all install DEBUG_FLAGS=-g
   
  Ok, someone who got the crash will have to do this as I couln't
  reproduce it here (sorry forgot to say...)
  
 I just learned that the missing piece in reproducing this is the
 pulseaudio knob, now I finally have a bt:
 
 [...]
 Loaded symbols for /libexec/ld-elf.so.1
 #0  symlook_obj (req=0x7fffbf40, obj=0x800640400) at 
 /d3t/d3t/home/nox/src10b/src/libexec/rtld-elf/rtld.c:3847
 3847for (symnum = obj-buckets[req-hash % obj-nbuckets];
 [New Thread 802406400 (LWP 100159/vlc-cache-gen)]
 (gdb) bt
 #0  symlook_obj (req=0x7fffbf40, obj=0x800640400) at 
 /d3t/d3t/home/nox/src10b/src/libexec/rtld-elf/rtld.c:3847
 #1  0x000800608ae7 in symlook_list (req=0x7fffc120, objlist=Variable 
 objlist is not available.
 ) at /d3t/d3t/home/nox/src10b/src/libexec/rtld-elf/rtld.c:3611
 #2  0x00080060911b in symlook_default (req=0x7fffc1c0, 
 refobj=Variable refobj is not available.
 ) at /d3t/d3t/home/nox/src10b/src/libexec/rtld-elf/rtld.c:3569
 #3  0x00080060939d in find_symdef (symnum=15, refobj=0x8006fd000, 
 defobj_out=0x7fffc260, flags=0, cache=0x80061d000, 
 lockstate=0x7fffc300)
 at /d3t/d3t/home/nox/src10b/src/libexec/rtld-elf/rtld.c:1541
 #4  0x000800603690 in reloc_non_plt (obj=0x8006fd000, obj_rtld=Variable 
 obj_rtld is not available.
 ) at /d3t/d3t/home/nox/src10b/src/libexec/rtld-elf/amd64/reloc.c:204
 #5  0x000800606ae8 in relocate_object (obj=0x8006fd000, bind_now=0 '\0', 
 rtldobj=0x800819d00, flags=0, lockstate=0x7fffc300)
 at /d3t/d3t/home/nox/src10b/src/libexec/rtld-elf/rtld.c:2433
 #6  0x0008006084a8 in dlopen_object (name=0x80243ec80 
 ../modules/access/.libs/libpulsesrc_plugin.so, fd=Variable fd is not 
 available.
 )
 at /d3t/d3t/home/nox/src10b/src/libexec/rtld-elf/rtld.c:2392
 #7  0x000800608f67 in rtld_dlopen (name=0x80243ec80 
 ../modules/access/.libs/libpulsesrc_plugin.so, fd=-1, mode=1)
 at /d3t/d3t/home/nox/src10b/src/libexec/rtld-elf/rtld.c:2761
 #8  0x000800ad377d in vlc_timer_create () from 
 /usr/ports/multimedia/vlc-203a/work/vlc-2.0.3/src/.libs/libvlccore.so.6
 #9  0x000800ab9998 in module_gettext () from 
 /usr/ports/multimedia/vlc-203a/work/vlc-2.0.3/src/.libs/libvlccore.so.6
 #10 0x000800aba0aa in module_list_get () from 
 /usr/ports/multimedia/vlc-203a/work/vlc-2.0.3/src/.libs/libvlccore.so.6
 #11 0x000800ab9db1 in module_list_get () from 
 /usr/ports/multimedia/vlc-203a/work/vlc-2.0.3/src/.libs/libvlccore.so.6
 #12 0x000800ab9db1 in module_list_get () from 
 /usr/ports/multimedia/vlc-203a/work/vlc-2.0.3/src/.libs/libvlccore.so.6
 #13 0x000800aba17d in module_list_get () from 
 /usr/ports/multimedia/vlc-203a/work/vlc-2.0.3/src/.libs/libvlccore.so.6
 #14 0x000800aba631 in module_list_get () from 
 /usr/ports/multimedia/vlc-203a/work/vlc-2.0.3/src/.libs/libvlccore.so.6
 #15 0x000800a52573 in libvlc_InternalInit () from 
 /usr/ports/multimedia/vlc-203a/work/vlc-2.0.3/src/.libs/libvlccore.so.6
 #16 0x0008008227a7 in libvlc_new () from 
 /usr/ports/multimedia/vlc-203a/work/vlc-2.0.3/lib/.libs/libvlc.so.8
 #17 0x00400cd4 in main ()
 (gdb) p obj-buckets
 $1 = (const Elf_Hashelt *) 0x804de0160
 (gdb) p req-hash % obj-nbuckets
 $2 = 399
 (gdb) p obj-buckets[req-hash % obj-nbuckets] 
 Cannot access memory at address 0x804de079c
 (gdb) p obj-nbuckets
 $3 = 521
Can you show the output of p *obj there ?


pgp5gA5rODpPF.pgp
Description: PGP signature

Re: Segfault in rtld - dlopen RTLD_LAZY (was: Re: CFT: vlc 2.0.3 - want to know where it works and where only partly)

[Konstantin Belousov]

On Sun, Aug 05, 2012 at 05:31:19PM +0200, Juergen Lock wrote:
 Hi kib, -current, seems we have a segfault in rtld when updating
 the multimedia/vlc port from the version currently in ports to the
 2.0.3 CFT version from here:
 
   http://people.freebsd.org/~nox/tmp/vlc-2.0.3-006.patch
 
 (If you test the LIVEMEDIA knob you also need this update:
 
   http://people.freebsd.org/~nox/tmp/livemedia-20120404-001.patch
 
 )
Please do two things.

1. Provide me the output of readelf -a for the module that was loaded.

2. Recompile rtld with debug symbols and redo the build to get the useful
backtrace from core:
cd /usr/src/libexec/rtld-elf
make clean
make all install DEBUG_FLAGS=-g

 
 In article 20120804110952.4f3a9...@ernst.jennejohn.org you write:
 On Fri, 3 Aug 2012 18:36:33 +0200
 Juergen Lock n...@jelal.kn-bremen.de wrote:
 
  On Fri, Aug 03, 2012 at 05:00:37PM +0200, Rainer Hurling wrote:
   On 03.08.2012 14:27 (UTC+2), Gary Jennejohn wrote:
On Thu, 2 Aug 2012 22:56:26 +0200
Juergen Lock n...@jelal.kn-bremen.de wrote:
   
[trimmed irrelevant content]
Ok I added that check:
   
  http://people.freebsd.org/~nox/tmp/vlc-2.0.3-005.patch
   
  Enjoy, :)
   
   
AMD64 on HEAD.
   
I always get this error, no matter which patch I use:
   
   GEN../modules/plugins.dat
gmake[2]: *** [../modules/plugins.dat] Segmentation fault: 11 (core 
dumped)
gmake[2]: Leaving directory 
`/usr/ports/multimedia/vlc/work/vlc-2.0.3/bin'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/usr/ports/multimedia/vlc/work/vlc-2.0.3'
gmake: *** [all] Error 2
*** [do-build] Error code 1
   
   I get exactly the same error with CURRENT amd64.
   
  Hm how old are both your installed src and ports?  You two are the
  first to report this and I just tried to reproduce it on a head
  checkout from May 13 and ports from June 18, and couldn't.
  
 
 I update the ports and source trees almost every day.  I do not install
 new ports binaries unless absolutely necessary, so the ports binaries
 are pretty much rather old.
 
 Just installed a new world/kernel today (updated yesterdya), r239006.
 
   BTW, mplayer from ports does not build with liveMedia-20120404 ...
   
Stop in /usr/ports/multimedia/vlc.
*** [build] Error code 1
   
and there's a work/vlc-2.0.3/bin/vlc-cache-gen.core generated.
   
May be because I have a mix of old and new dependencies, although the 
vlc
port never tries to update any of them.
   
   Well ports never update dependencies themselves, you need to use
  tools like portmaster for that.
  
 
 I avoid using tools whenever possible.  Maybe I will have to try
 portmaster, but I dread seeing 50 ports updated just because I
 want to update one port.
 
 I turned on -g in make.conf and ran vlc-cache-gen in gdb.  Here's the
 result.
 
 gdb /usr/ports/multimedia/vlc/work/vlc-2.0.3/bin/.libs/vlc-cache-gen
 GNU gdb 6.1.1 [FreeBSD]
 Copyright 2004 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you are
 welcome to change it and/or distribute copies of it under certain conditions.
 Type show copying to see the conditions.
 There is absolutely no warranty for GDB.  Type show warranty for details.
 This GDB was configured as amd64-marcel-freebsd...
 (gdb) r ../modules/
 Starting program: 
 /usr/ports/multimedia/vlc/work/vlc-2.0.3/bin/.libs/vlc-cache-gen ../modules/
 [New LWP 100125]
 [New Thread 802406400 (LWP 100125/vlc-cache-gen)]
 
 Program received signal SIGSEGV, Segmentation fault.
 [Switching to Thread 802406400 (LWP 100125/vlc-cache-gen)]
 0x000800606588 in matched_symbol () from /libexec/ld-elf.so.1
 (gdb) bt
 #0  0x000800606588 in matched_symbol () from /libexec/ld-elf.so.1
 #1  0x0008006087e4 in symlook_obj () from /libexec/ld-elf.so.1
 #2  0x000800608ae7 in symlook_list () from /libexec/ld-elf.so.1
 #3  0x00080060911b in symlook_default () from /libexec/ld-elf.so.1
 #4  0x00080060939d in find_symdef () from /libexec/ld-elf.so.1
 #5  0x00080060375b in reloc_non_plt () from /libexec/ld-elf.so.1
 #6  0x000800606ae8 in relocate_object () from /libexec/ld-elf.so.1
 #7  0x0008006084a8 in dlopen_object () from /libexec/ld-elf.so.1
 #8  0x000800608f67 in rtld_dlopen () from /libexec/ld-elf.so.1
 #9  0x000800affe95 in module_Load (p_this=0x80244c198,
 psz_file=0x802472c00 ../modules//codec/.libs/libfluidsynth_plugin.so,
 p_handle=0x7fffd180, lazy=true) at posix/plugin.c:62
 #10 0x000800adef4b in module_InitDynamic (obj=0x80244c198,
 path=0x802472c00 ../modules//codec/.libs/libfluidsynth_plugin.so,
 fast=true) at modules/bank.c:536
 #11 0x000800adede2 in AllocatePluginFile (bank=0x7fffd490,
 abspath=0x802472c00 ../modules//codec/.libs/libfluidsynth_plugin.so,
 relpath=0x802472b80 codec/.libs/libfluidsynth_plugin.so,
 st=0x7fffd210) at 

Re: Linux binary looks for /proc/cpuinfo, dies when cannot be found, even when linprocfs mounted.

[Konstantin Belousov]

On Sat, Jun 23, 2012 at 02:23:42PM +1200, Benjamin wrote:
 Hi all. I have posted this question on the forums, and it was suggested 
 that I post it here.
 
 I am currently porting Altera Quartus II design software to FreeBSD. I 
 have got it installing, but running the binary requires /proc/cpuinfo to 
 exist, and it dies when it can't find it.
 
 I have both procfs and linprocfs mounted.
To be sure, show us the mount -v output.

 
 As a workaround (read hack) I can do the following to make the binary 
 execute.
 
 1. unmount procfs.
 2. symlink /compat/linux/proc/cpuinfo to /proc/cpuinfo
 
 Since this problem has no doubt come up before, what is the best way to 
 get around this issue?
No, it did not came up before.

Show the file(1) output on the binary which exhibit the faulty behaviour.
 
 Cheers,
 
 Benjamin
 
 
 ___
 freebsd-ports@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


pgptmTGLaNL81.pgp
Description: PGP signature

Re: Linux binary looks for /proc/cpuinfo, dies when cannot be found, even when linprocfs mounted.

[Konstantin Belousov]

On Sat, Jun 23, 2012 at 09:55:22PM +1200, Benjamin wrote:
 On 06/23/12 20:57, Konstantin Belousov wrote:
 On Sat, Jun 23, 2012 at 02:23:42PM +1200, Benjamin wrote:
 Hi all. I have posted this question on the forums, and it was suggested
 that I post it here.
 
 I am currently porting Altera Quartus II design software to FreeBSD. I
 have got it installing, but running the binary requires /proc/cpuinfo to
 exist, and it dies when it can't find it.
 
 I have both procfs and linprocfs mounted.
 To be sure, show us the mount -v output.
 
 [snipped]
 linprocfs on /usr/compat/linux/proc (linprocfs, local)
 procfs on /proc (procfs, local)
 [/snipped]
 
 As a workaround (read hack) I can do the following to make the binary
 execute.
 
 1. unmount procfs.
 2. symlink /compat/linux/proc/cpuinfo to /proc/cpuinfo
 
 Since this problem has no doubt come up before, what is the best way to
 get around this issue?
 No, it did not came up before.
 
 Show the file(1) output on the binary which exhibit the faulty behaviour.
 Aha. I think you've identified the problem
 
 quartus_sh: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), 
 dynamically linked (uses shared libs), for GNU/Linux 2.2.5, not stripped
 
 brandelf(1)ing this to Linux seems to have worked. What does SYSV 
 represent anyway? brandelf -l only lists
 
 known ELF types are: FreeBSD(9) Linux(3) Solaris(6) SVR4(0)
 
 so what does SYSV mean?
There it means that an old branding method was not used on the binary.
Note that the note is present in the executable, so even file is
able to identify the binary as using Linux ABI.

I very much doubt that your report of 'crash' was due to unability
to open /proc/cpuinfo, the failure scenario should be much more spectacular
and fun to watch.

What version of the kernel do you use and what arch ? We have support
for note-based ABI branding for very long time. I wonder is your kernel
so ancient that it lacks the support, or we have a regression.

Can you put the binary somewere so I can look into it ?


pgpCEUueB7rm8.pgp
Description: PGP signature

Re: Ruby 1.9 as default

[Konstantin Belousov]

On Mon, Jun 04, 2012 at 08:25:08PM -0400, Steve Wills wrote:
 On 06/01/12 22:30, Stanislav Sedov wrote:
  
  I'm not sure it's a good idea.
  Ruby 1.9 still has some nasty bugs on FreeBSD, related to the threads and
  fork.  That is fork in ruby 1.9 hangs sometimes...
 
 The ONLY thing I can find is this:
 
 http://bugs.ruby-lang.org/issues/2097
 
 which implies that it's fixed. If there's more to this issue than
 broken on 7.3 and earlier, PLEASE let me know.

If ruby indeed does what the bugs described, that is, calls non-async
signal safe functions from the threaded process after fork, then you
are guaranteed to get random hangs sometimes.


pgpJjLtcLgwhW.pgp
Description: PGP signature

Re: Ruby 1.9 as default

[Konstantin Belousov]

On Tue, Jun 05, 2012 at 02:04:33AM -0700, Stanislav Sedov wrote:
 
 On Jun 5, 2012, at 1:52 AM, Konstantin Belousov wrote:
 
  On Mon, Jun 04, 2012 at 08:25:08PM -0400, Steve Wills wrote:
  On 06/01/12 22:30, Stanislav Sedov wrote:
  
  I'm not sure it's a good idea.
  Ruby 1.9 still has some nasty bugs on FreeBSD, related to the threads and
  fork.  That is fork in ruby 1.9 hangs sometimes...
  
  The ONLY thing I can find is this:
  
  http://bugs.ruby-lang.org/issues/2097
  
  which implies that it's fixed. If there's more to this issue than
  broken on 7.3 and earlier, PLEASE let me know.
  
  If ruby indeed does what the bugs described, that is, calls non-async
  signal safe functions from the threaded process after fork, then you
  are guaranteed to get random hangs sometimes.
 
 Actually, the problem I'm trying to debug right now is more weird.
 When I run mono via system(3) from the ruby 1.9 process (I mean,
 exactly system(3), not via some ruby wrapper) twice, it hangs on some
 umtx the second time.  This works all the time.
 
 I'm still trying to track it down in mono, though it's not clear how
 this can happen at all.  Isn't execve(2) used by system(3) is supposed
 to clear everything (mutexes at least)?

The address space of the exec-ed process is completely reset, but the
full process state is not. Most often, the problematic bits are the
ignored signals, which are inherited.

Please note that 'umtx hangs' are not system problems most often, but
indicate an application bug. If program has multithreading bug that results
in threads deadlock, you end up with threads in some umtx sleep state.

Sorry, I cannot give any further advise except the hand-waving above.


pgpFM7HMUcAGU.pgp
Description: PGP signature

Re: Need a little help with a dynamic linking problem

[Konstantin Belousov]

On Wed, Apr 25, 2012 at 05:58:37PM -0700, Ronald F. Guilmette wrote:
 
 In message 
 CADt0fhw=cOrwaAmb8VNDRbCnwAuzhRyu=n3l_so732epv1v...@mail.gmail.com
 , you wrote:
 
 Without being able to look at the details in-depth myself, it looks like
 the shared object is looking for a symbol which the RTLD can't resolve.
 
 That much seems self-evident.  The error message itself in effect says
 precisely that.
 
 The symbol is defined in the gthumb application itself. Is that symbol 
 exported
 such that shared objects can reference it?
 
 Based on the outcome, I would have to say that this answer to that question
 is also (self-evidently?) no.
 
 But I'm really not sure, frankly, because I have never before seen an
 instance of anybody trying to do something screwy like this... I mean
 having a shared library that depends upon somthing (a symbol) that is
 intended to be satisfied by the main executable.  Frankly, this seems
 altogether screwy and bizzare to me.  Unsually, the main executable depends
 on (or uses, dynamically) a number of shared libraries.  Sharded libraries
 in turn typically depend on either (a) nothing at all or else (b) some
 combination of other shared and/or static linking libraries.  That has
 always been my own past experience anyway.  By like I said, I have been away
 from the software development tools for awhile, so mabe having a dynamic
 library that depends upon something in the main executable is considered
 kosher now.  (Or maybe it ain't, actually, but it is nonthelwess one of
 those screwy things that the current or original developer or maintainer
 found out that he could get away with anyway, you know, like JUST over
 on that well-known hobbist OS whose name begins with the letter L.)
 
 Like I say.  I don't know, cuz I'm not the developer/maintainer of this
 thing.
 
 If the problem is still unresolved by tomorrow...
 
 It doesn't seem to be healing on its own so far...
 
 I can draft up a sample and confirm my suspicions
 (that non-exported symbols won't be resolvable by dynamically-loaded shared
 objects).
 
 Oh, I do believe that you are 100% correct about that.  This much, at least,
 I _do_ remember from ancient times when I worked on the GNU software develop-
 ment tools (including the linker).
 
 In every object file... either a main executable or a shared library, there
 are symbols that are externally available/visible and then there are ones
 that aren't... i.e. that are local, and that the dynamic linker either never
 sees or, at any rate, doesn't pay any attention to.
 
 But my dim recollection is that you can easily tell which is which by looking
 at the type letter that appears next to the symbol in the `nm' output.  For
 example:
 
 % nm gthumb | fgrep gth_viewer_page_get_type
 004aaf10 T gth_viewer_page_get_type
  ^
 
 Here, the symbol type indicator is the letter `T', meaning that this is
 a ``text'' (executable/code) type of symbol.  That much I know for sure.
 The part I am less clear about anymore is that I _think_ I remember that
 when the type letter on the nm output is a capital letter (as in this case)
 it means that the symbol in question is ``public'' and available for
 linking.  (Actually, I _am_ pretty darn sure that this is indeed what CAPITAL
 type letters in the nm output mean.)
 
 The only other thing that I can't quite remember anymore is whether such
 a symbol is always and necessarily available for *dynamic* linking purposes.
 It might perhaps just be externally available  visible ONLY for *static*
 linking purposes, in which case that might explain why I am seeing a `T'
 on the nm output for the required symbol, but yet the dynamic linker
 clearly can't seem to find it.
 

You need to pass --export-dynamic to the linker when linking binary that
is supposed to export its own symbols.


pgpo71aLSij2q.pgp
Description: PGP signature

Re: Postgresql 8.2 branch - keep it in tree

[Konstantin Belousov]

On Sun, Mar 25, 2012 at 12:54:36PM +, Chris Rees wrote:
 On 25 Mar 2012 13:51, Radim Kolar h...@filez.com wrote:
 
  please do not remove this pgsql branch. its newest branch using old
 postgresql-contrib full text search engine. Upgrading to 8.3+ is not
 possible for such applications.
 
 I'm afraid it's not only end of life by upstream, but also vulnerable in
 more than one CVE, and will not be fixed.
Why is presence of a CVE relevant for 90% of all port users ?

Sigh.
 
 Can you give more detail on exactly what you are trying to do?
 
 Chris
 ___
 freebsd-ports@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


pgpJIBr4Sxl52.pgp
Description: PGP signature

Re: Fix nvidia-like ports, help needed

[Konstantin Belousov]

On Fri, Mar 02, 2012 at 01:34:12AM -0800, Doug Barton wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 On 02/28/2012 14:36, Baptiste Daroussin wrote:
  On Tue, Feb 28, 2012 at 01:19:44PM -0800, Doug Barton wrote:
  On 2/28/2012 1:15 PM, Baptiste Daroussin wrote:
  Here is a patch to add support for includedir keyword to
  libmap.conf so that we
  
  I think this is overly complicated, and not generally useful. It
  also delays the utility of the solution until this gets into the
  base.
  
  What I would do instead is to incorporate an nvidia option into
  the xorg meta-port, and separate the GL libs into a separate
  port. If the nvidia option is checked the GL libs come from an
  nvidia slave port. If not, they come from an xorg-server slave
  port.
  
  Or, we just keep doing what we're doing now, since it works. I'm
  still not sure what problem we're trying to solve. :)
  
  
  Doug
  
  the problem we are trying to solve is to avoid having the nvidia
  drivers overwritting libGL.so.1 which break the package database
  consistency.
 
 In that case the solution I outlined above would work, and it's hard
 for me to see why it wouldn't be the best solution.
There are hybrid machines which have both Intel and NVidia GPUs.
Depending on a switch position, you may activate one of the GPU.
Usually, on-CPU GPU gives power efficiency, while discrete one provdes
a performance.

For such machines, it is _very_ useful to have both libGL.so.1 installed
and somehow switched around. It would be best to have Mesa and NVidia
libGL.so.1 installed under other names, like libGL-mesa.so.1. and
ligGL-nvidia.so.1, and provide a symlink for libGL.so.1

BTW, besides libGL.so.1, another conflicting file is
/usr/local/lib/xorg/modules/extensions/libglx.so.


pgpas3pLEG6Sa.pgp
Description: PGP signature

Re: Fix nvidia-like ports, help needed

[Konstantin Belousov]

On Fri, Mar 02, 2012 at 10:36:44AM -0800, Doug Barton wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 On 03/02/2012 01:47, Konstantin Belousov wrote:
  On Fri, Mar 02, 2012 at 01:34:12AM -0800, Doug Barton wrote:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA256
 
  On 02/28/2012 14:36, Baptiste Daroussin wrote:
  On Tue, Feb 28, 2012 at 01:19:44PM -0800, Doug Barton wrote:
  On 2/28/2012 1:15 PM, Baptiste Daroussin wrote:
  Here is a patch to add support for includedir keyword to
  libmap.conf so that we
 
  I think this is overly complicated, and not generally useful. It
  also delays the utility of the solution until this gets into the
  base.
 
  What I would do instead is to incorporate an nvidia option into
  the xorg meta-port, and separate the GL libs into a separate
  port. If the nvidia option is checked the GL libs come from an
  nvidia slave port. If not, they come from an xorg-server slave
  port.
 
  Or, we just keep doing what we're doing now, since it works. I'm
  still not sure what problem we're trying to solve. :)
 
 
  Doug
 
  the problem we are trying to solve is to avoid having the nvidia
  drivers overwritting libGL.so.1 which break the package database
  consistency.
 
  In that case the solution I outlined above would work, and it's hard
  for me to see why it wouldn't be the best solution.
 
  There are hybrid machines which have both Intel and NVidia GPUs.
  Depending on a switch position, you may activate one of the GPU.
  Usually, on-CPU GPU gives power efficiency, while discrete one provdes
  a performance.
  
  For such machines, it is _very_ useful to have both libGL.so.1 installed
  and somehow switched around. It would be best to have Mesa and NVidia
  libGL.so.1 installed under other names, like libGL-mesa.so.1. and
  ligGL-nvidia.so.1, and provide a symlink for libGL.so.1
  
  BTW, besides libGL.so.1, another conflicting file is
  /usr/local/lib/xorg/modules/extensions/libglx.so.
 
 For us to support that would actually require a script of some sort, but
 it's not impossible. If the switch you're referring to provides a devd
 event it could even be automated, although (AFAIK) you'd have to restart
 X. I'm not opposed to what you're proposing, install both libs and
 symlink one or the other ... but that situation is still most easily
 handled by having the GL components of both xorg-server and
 nvidia-driver being split out into separate slave ports.

Well, the switch only works sometime, and for FreeBSD, you need to
reboot the OS (basically, BIOS shall reprogram the video commutator and
activate/deactivate PCI devices). Linux does have some alpha-stage support
for switching GPUs on fly, but you are required to use the Nouveau.
NVidia optimus (the newest variation of the dual-GPU systems) does
not have commutator, and video signal is generated by on-CPU GPU always.

I think that packaging libGL.so variants into separate packages from the
nvidia driver/mesa has nothing to do with names/symlink issue.

And yes, I use a script that checks PCI devices on boot and symlinks
libGL.so.1 and libglx.so to appropriate implementations. The only trouble
right now is that reinstall of libGL or nvidia driver ports requires
manual fixing of the .so.


pgp00NxSj9hTe.pgp
Description: PGP signature

Re: Fix nvidia-like ports, help needed

[Konstantin Belousov]

On Fri, Mar 02, 2012 at 10:54:46AM -0800, Freddie Cash wrote:
 On Fri, Mar 2, 2012 at 10:49 AM, Konstantin Belousov
 kostik...@gmail.com wrote:
  And yes, I use a script that checks PCI devices on boot and symlinks
  libGL.so.1 and libglx.so to appropriate implementations. The only trouble
  right now is that reinstall of libGL or nvidia driver ports requires
  manual fixing of the .so.
 
 Ah, but splitting the GL bits out into slave ports would fix that.  :)
No, it moves the moment of problem from mesa/nvidia update to mesa-libGL
and nvidia-libGL update. And, libGl.so.1 from Mesa is already in the
separate port, FWIW.


pgpAExzofdBch.pgp
Description: PGP signature

Re: Fix nvidia-like ports, help needed

[Konstantin Belousov]

On Fri, Mar 02, 2012 at 11:10:06AM -0800, Freddie Cash wrote:
 On Fri, Mar 2, 2012 at 11:02 AM, Konstantin Belousov
 kostik...@gmail.com wrote:
  On Fri, Mar 02, 2012 at 10:54:46AM -0800, Freddie Cash wrote:
  On Fri, Mar 2, 2012 at 10:49 AM, Konstantin Belousov
  kostik...@gmail.com wrote:
   And yes, I use a script that checks PCI devices on boot and symlinks
   libGL.so.1 and libglx.so to appropriate implementations. The only trouble
   right now is that reinstall of libGL or nvidia driver ports requires
   manual fixing of the .so.
 
  Ah, but splitting the GL bits out into slave ports would fix that.  :)
 
  No, it moves the moment of problem from mesa/nvidia update to mesa-libGL
  and nvidia-libGL update. And, libGl.so.1 from Mesa is already in the
  separate port, FWIW.
 
 How?  Unless the ports include the creation of the symlink (which they
 shouldn't), then there is no problem anymore.
 
 You install nvidia-gl port, you get libGL-nvidia.so installed.
So nvidia-something port needs to install libGL-nvidia.so.1, and
not libGL.so.1.

 
 You install mesa-gl port, you get libGL-mesa.so installed.
 
 You run the alternatives script to create the symlink (or manually
 create it, or tweak a knob somewhere to create it), and then never
 touch it again.
 
 Update nvidia-gl port, only libGL-nvidia.so gets updated.  The symlink
 doesn't change.
 
 Update mesa-gl port, only libGL-mesa.so gets updated.  The symlink
 doesn't change.
 
 Where's the problem?
Should I repeat what I said already, or can I just point to my other
message ?

The renames of the libGL.so inside the packages are orthohonal to
package splits. The issue is that libGL.so.1 installed by both packages
(graphics/libGL and x11/nvidia-driver). And not that the nvidia-driver
contains some other stuff.


pgpIOaZYI48Jp.pgp
Description: PGP signature

Re: Fix nvidia-like ports, help needed

[Konstantin Belousov]

On Fri, Mar 02, 2012 at 11:35:42AM -0800, Doug Barton wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 On 03/02/2012 11:21, Konstantin Belousov wrote:
  The renames of the libGL.so inside the packages are orthohonal to
  package splits. The issue is that libGL.so.1 installed by both packages
  (graphics/libGL and x11/nvidia-driver). And not that the nvidia-driver
  contains some other stuff.
 
 Right, I see your point. If the symlink solution is used, slave ports
 are likely unnecessary.
 
 Another question that occurred to me, has anyone tested that ports built
 against one version of the GL stuff can safely be run if the other
 version suddenly appears at runtime?

The different libGL.so versions should be ABI-compatible. The OpenGL
extension mechanism assumes that OpenGL consumers test the presence
of the optional features at runtime and adapts. You do not link directly
to the new symbol in libGL, but call a function to get the function
pointer for extension.

On other systems, different OpenGL providers support different versions
of OpenGL standard, and this usually not cause much problem for applications.

Sure, there may be bugs (and usually there are).


pgprWTqwCFhsJ.pgp
Description: PGP signature

Re: rtld or lang/gcc cannot find libgcc_s.so.1

[Konstantin Belousov]

On Tue, Feb 21, 2012 at 11:42:59AM -0800, Steve Kargl wrote:
 On Tue, Feb 21, 2012 at 08:57:54PM +0200, Konstantin Belousov wrote:
  On Tue, Feb 21, 2012 at 10:28:50AM -0800, Steve Kargl wrote:
   
   troutmask:kargl[210] halfspace
   /lib/libgcc_s.so.1: version GCC_4.6.0 required by 
   /home/kargl/bin/halfspace
not foundtroutmask:kargl[211]
   
   (Note, the annoying absense of a newline character after the error
   message, which is a completely different issue.)
   
   I see this problem on both freebsd-i386 and freebsd-amd64.
   
   troutmask:kargl[212] ldd ~/bin/halfspace
   /home/kargl/bin/halfspace:
   liblapack.so.4 = /usr/local/lib/liblapack.so.4 (0x2008c3000)
   libblas.so.2 = /usr/local/lib/libblas.so.2 (0x201463000)
   libgfortran.so.3 = /usr/local/lib/gcc46/libgfortran.so.3 
   (0x20175d000)
   libm.so.5 = /lib/libm.so.5 (0x201a7)
   libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x201c95000)
   libquadmath.so.0 = /usr/local/lib/gcc46/libquadmath.so.0 
   (0x201ea2000)
   libc.so.7 = /lib/libc.so.7 (0x2020d6000)
   troutmask:kargl[212] ldconfig -r | grep libgcc_s
   29:-lgcc_s.1 = /lib/libgcc_s.so.1
   723:-lgcc_s.1 = /usr/local/lib/gcc46/libgcc_s.so.1
   
   So, it appears that rtld is finding the wrong libgcc_s.so.1 or 
   the lang/gcc port is no longer providing sufficient information
   for rtld to choose the correct library.
   
   I have reverted revisions 230784, 299768, and 229508 (and
   various combinitions of these revisions) from rtld-elf.  The
   result does not change the above error.
   
   I can work around the problem by specifying -static during
   the building of my programs.  Or, I can work around the
   problem by *explicitly* adding '-rpath /usr/local/lib' to the
   command line, which I have never had to do.
   
  I highly suspect that you just happen to not need a symbol from the
  newest namespace before.
  
  The thing to look first is the library search path in the ld.so hints,
  which is output at the second line of ldconfig -r. I think that you have
  /lib before /usr/local/lib/gcc46 in your setup. This guess is confirmed
  by the numeration of the two instances of gcc_s above. Either change
  the config, or use -rpath. AFAIR, ldconfig -m adds the directory
  at the end of the search list.
 
 Yes, /lib comes before /usr/local/lib/gcc46.  I suppose
 that this is a heads up for gerald@. lang/gcc is used by
 the ports collections to build a large number of other
 ports, so others are likely to hit this issue.
 
 I tried reading rtld.c to see where the issue lies.  One
 possibility seems to be a change in rtld.c (lines 4012-13)
 to remember the version mismatch, then continuing the search 
 to see if another library with the same name but different
 location matches.  After exhausting the list of directories
 in the search path, either an error is reported or a match
 has been found.  Note, I'm still trying to parse and understand
 the rtld.c code, so may be what I'm suggesting is not 
 feasible.
No, it is not feasible. The version check that tripped is there to check
consistency, and not to start loading. In fact, it is too late to
load other library (with the same name). The configuration needs to
be fixed, and not the rtld.


pgpQf8VpXvI63.pgp
Description: PGP signature

Re: rtld or lang/gcc cannot find libgcc_s.so.1

[Konstantin Belousov]

On Tue, Feb 21, 2012 at 10:28:50AM -0800, Steve Kargl wrote:
 Sorry about the cross post, but I can't tell if this
 a -current issue of a -ports issue.  Unfortunately,
 I updated my freebsd 10.0 systems and the lang/gcc
 port during the same timeframe.
 
 I have compiled my math library and several programs
 with gfortran, which is installed by lang/gcc (pkg_info 
 shows gcc-4.6.2_1).  When I try running the program
 I get
 
 troutmask:kargl[210] halfspace
 /lib/libgcc_s.so.1: version GCC_4.6.0 required by /home/kargl/bin/halfspace
  not foundtroutmask:kargl[211]
 
 (Note, the annoying absense of a newline character after the error
 message, which is a completely different issue.)
 
 I see this problem on both freebsd-i386 and freebsd-amd64.
 
 troutmask:kargl[212] ldd ~/bin/halfspace
 /home/kargl/bin/halfspace:
 liblapack.so.4 = /usr/local/lib/liblapack.so.4 (0x2008c3000)
 libblas.so.2 = /usr/local/lib/libblas.so.2 (0x201463000)
 libgfortran.so.3 = /usr/local/lib/gcc46/libgfortran.so.3 
 (0x20175d000)
 libm.so.5 = /lib/libm.so.5 (0x201a7)
 libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x201c95000)
 libquadmath.so.0 = /usr/local/lib/gcc46/libquadmath.so.0 
 (0x201ea2000)
 libc.so.7 = /lib/libc.so.7 (0x2020d6000)
 troutmask:kargl[212] ldconfig -r | grep libgcc_s
 29:-lgcc_s.1 = /lib/libgcc_s.so.1
 723:-lgcc_s.1 = /usr/local/lib/gcc46/libgcc_s.so.1
 
 So, it appears that rtld is finding the wrong libgcc_s.so.1 or 
 the lang/gcc port is no longer providing sufficient information
 for rtld to choose the correct library.
 
 I have reverted revisions 230784, 299768, and 229508 (and
 various combinitions of these revisions) from rtld-elf.  The
 result does not change the above error.
 
 I can work around the problem by specifying -static during
 the building of my programs.  Or, I can work around the
 problem by *explicitly* adding '-rpath /usr/local/lib' to the
 command line, which I have never had to do.
 
I highly suspect that you just happen to not need a symbol from the
newest namespace before.

The thing to look first is the library search path in the ld.so hints,
which is output at the second line of ldconfig -r. I think that you have
/lib before /usr/local/lib/gcc46 in your setup. This guess is confirmed
by the numeration of the two instances of gcc_s above. Either change
the config, or use -rpath. AFAIR, ldconfig -m adds the directory
at the end of the search list.


pgpCP0Lz8ObQK.pgp
Description: PGP signature