On Sat, Feb 23, 2019 at 09:19:01AM +1100, Dave Horsfall wrote:
> On Fri, 22 Feb 2019, Tijl Coosemans wrote:
>
> > 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
On Fri, 22 Feb 2019, Tijl Coosemans wrote:
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.
I'm late to this
Wow,
I have just discovered the "native-tools" and "native-tools-install"
target in /usr/src/Makefile, and am playing around with it to
crossbuild my RPI2 packages with synth. It has sped up package
building impressively!
Thank you, FreeBSD developers!
--
Jonathan Chen
On Fri, 22 Feb 2019 19:14:33 +0200 Konstantin Belousov
wrote:
> On Fri, Feb 22, 2019 at 05:09:59PM +0100, Tijl Coosemans wrote:
>> 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
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
On Fri, Feb 22, 2019 at 07:09:11PM +0200, Konstantin Belousov wrote:
> On Fri, Feb 22, 2019 at 08:44:54AM -0800, Steve Kargl wrote:
> >
> > 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
On Fri, 22 Feb 2019 08:44:54 -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
>>> Do you agree that the ultimate and proper solution is to add missed symbols
>>> and versions to the base
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
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
On Fri, Feb 22, 2019 at 05:11:20PM +0100, Tijl Coosemans wrote:
> On Thu, 21 Feb 2019 10:24:51 -0800 Steve Kargl
>
> > BTW, if you compare gcc trunks symbol map
> > ./x86_64-unknown-freebsd13.0/libgcc/libgcc.map
> > with src/lib/libgcc_s/Version.map, you'll find that
> > that maps are no
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
On Fri, 22 Feb 2019 09:19:54 -0700 "Russell L. Carter"
wrote:
> On 2/22/19 6:04 AM, Tijl Coosemans wrote:
>> 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.
>
> Maybe some distros, but at least for
On 2/22/19 6:04 AM, Tijl Coosemans wrote:
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
On Thu, 21 Feb 2019 10:24:51 -0800 Steve Kargl
wrote:
> On Thu, Feb 21, 2019 at 06:05:15PM +0100, Tijl Coosemans wrote:
>> There's also the fact that gfortran behaves differently from the C
>> compilers (both clang and gcc) when it comes to libgcc_s. Gfortran
>> always links with libgcc_s. The C
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.
On Fri, Feb 22, 2019 at 03:43:14PM +0100, Jan Beich wrote:
> bob prohaska writes:
>
> > In trying to compile /usr/ports/devel/rust-cbindgen on an
> > rpi3 running -current make fails with errors such as
> >
> > error[E0412]: cannot find type `c_long` in the crate root
> >
> > It's tempting to
On Fri, Feb 22, 2019 at 12:28:41PM +0100, Tijl Coosemans wrote:
> > PS: For the record, the GCC_4.6.0 are needed for gfortran REAL(16)
> > type.
>
> With my patch gfortran resolves the GCC_4.6.0 symbols statically just
> like the C compilers do. If the C compilers didn't do this we'd have
> this
On Fri, Feb 22, 2019 at 09:32:03AM -0500, Ed Maste wrote:
> On Thu, 21 Feb 2019 at 16:47, Steve Kargl
> wrote:
> >
> > The missing symbols are
> >
> > % objdump -x lib/libgfortran.so | grep GCC_4.6.0 | awk '{print $5}' | sort
>
> Thank you for collecting these.
>
> > It looks like we may be
Cy Schubert wrote on 2019/02/22 15:45:
On February 22, 2019 1:42:05 AM PST, Miroslav Lachman <000.f...@quip.cz> wrote:
Hi,
I used xpdf for many years on headless servers without X11, now I
noticed that this options is nolonger there. Was it removed by upstream
or is it still some way to have
On February 22, 2019 1:57:40 AM PST, Mehmet Erol Sanliturk
wrote:
>On Fri, Feb 22, 2019 at 12:50 PM Miroslav Lachman <000.f...@quip.cz>
>wrote:
>
>> Hi,
>> I used xpdf for many years on headless servers without X11, now I
>> noticed that this options is nolonger there. Was it removed by
On February 22, 2019 1:42:05 AM PST, Miroslav Lachman <000.f...@quip.cz> wrote:
>Hi,
>I used xpdf for many years on headless servers without X11, now I
>noticed that this options is nolonger there. Was it removed by upstream
>
>or is it still some way to have working xpdf without dependency on
bob prohaska writes:
> In trying to compile /usr/ports/devel/rust-cbindgen on an
> rpi3 running -current make fails with errors such as
>
> error[E0412]: cannot find type `c_long` in the crate root
>
> It's tempting to think this is some sort of configuration
> error. Can anyone suggest a
On Thu, 21 Feb 2019 at 16:47, Steve Kargl
wrote:
>
> The missing symbols are
>
> % objdump -x lib/libgfortran.so | grep GCC_4.6.0 | awk '{print $5}' | sort
Thank you for collecting these.
> It looks like we may be able to grab some of these from libc/softfloat:
> getf2.c, gttf2.c, letf2.c,
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.
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
On Thu, 21 Feb 2019 16:13:15 -0800 Steve Kargl
wrote:
> On Thu, Feb 21, 2019 at 11:18:50PM +0100, Tijl Coosemans wrote:
>> On Thu, 21 Feb 2019 13:30:41 -0500 Diane Bruce wrote:
>>> On Thu, Feb 21, 2019 at 06:05:15PM +0100, Tijl Coosemans wrote:
On Sun, 17 Feb 2019 10:16:04 -0500 Diane Bruce
On Fri, Feb 22, 2019 at 12:50 PM Miroslav Lachman <000.f...@quip.cz> wrote:
> Hi,
> I used xpdf for many years on headless servers without X11, now I
> noticed that this options is nolonger there. Was it removed by upstream
> or is it still some way to have working xpdf without dependency on Qt5?
Hi,
I used xpdf for many years on headless servers without X11, now I
noticed that this options is nolonger there. Was it removed by upstream
or is it still some way to have working xpdf without dependency on Qt5?
Kind regards
Miroslav Lachman
___
28 matches
Mail list logo
