On Mon, Nov 30, 2020 at 09:43:50PM +0530, Mayuresh wrote:
> On Mon, Nov 30, 2020 at 02:49:53PM +0100, tlaro...@polynum.com wrote:
> > 1) There is no .strtab pb neither with a cross-ld or with the native ld
> > on earmv7hf using the test that was sufficient to exhibit the problem
> > before the fix
On Mon, Nov 30, 2020 at 02:49:53PM +0100, tlaro...@polynum.com wrote:
> 1) There is no .strtab pb neither with a cross-ld or with the native ld
> on earmv7hf using the test that was sufficient to exhibit the problem
> before the fix of Aug 2019;
I do not know if this is relevant, but the build of
Here what I have found:
1) There is no .strtab pb neither with a cross-ld or with the native ld
on earmv7hf using the test that was sufficient to exhibit the problem
before the fix of Aug 2019;
2) When installing firefox32, retrieving the package and all its
dependencies from NetBSD packages
On Sat, Nov 28, 2020 at 09:15:15AM +0100, tlaro...@polynum.com wrote:
> It is also caused by knowledge of C: one imagine that strcpy is
> implemented doing _string_ manipulation (because of its name) and what one
> will do programming it directly that is:
>
> p = buf;
> q = buf + positive_shift;
On Sat, Nov 28, 2020 at 08:41:50AM +0100, Martin Husemann wrote:
> On Fri, Nov 27, 2020 at 11:29:13PM -0500, Jeffrey Walton wrote:
> > > Concerning the core dumps, there is another thing to look at:
> > > _FORTIFY_SOURCE. There are checks about the use of strings functions
> > > that can cause an
On Sat, Nov 28, 2020 at 09:41:21AM +0530, Mayuresh wrote:
> On Fri, Nov 27, 2020 at 07:39:44PM +0100, tlaro...@polynum.com wrote:
> > $ file /usr/bin/ld
> >
> > If the linker is for 9.1 it will tell so.
>
> /usr/bin/ld: ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYSV),
> dynamically
On Sat, Nov 28, 2020 at 3:15 AM wrote:
>
> On Sat, Nov 28, 2020 at 08:41:50AM +0100, Martin Husemann wrote:
> > On Fri, Nov 27, 2020 at 11:29:13PM -0500, Jeffrey Walton wrote:
> > > > Concerning the core dumps, there is another thing to look at:
> > > > _FORTIFY_SOURCE. There are checks about the
On Fri, Nov 27, 2020 at 11:29:13PM -0500, Jeffrey Walton wrote:
> > Concerning the core dumps, there is another thing to look at:
> > _FORTIFY_SOURCE. There are checks about the use of strings functions
> > that can cause an abort even if the actual use is probably, with
> > a classic C
On Fri, Nov 27, 2020 at 6:47 AM wrote:
> ...
> Concerning the core dumps, there is another thing to look at:
> _FORTIFY_SOURCE. There are checks about the use of strings functions
> that can cause an abort even if the actual use is probably, with
> a classic C implementation, safe---I hit it with
On Fri, Nov 27, 2020 at 07:39:44PM +0100, tlaro...@polynum.com wrote:
> $ file /usr/bin/ld
>
> If the linker is for 9.1 it will tell so.
/usr/bin/ld: ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYSV),
dynamically linked, interpreter /usr/libexec/ld.elf_so, for NetBSD 9.1,
compiled for:
On Fri, Nov 27, 2020 at 09:37:29PM +0530, Mayuresh wrote:
> On Fri, Nov 27, 2020 at 04:54:20PM +0100, tlaro...@polynum.com wrote:
> > Just to be sure: on your RPI, the kernel is 9.1 but the userland is not
> > 8.x?
>
> I didn't build it. It is the released image of 9.1 from netbsd.org.
>
> Is
On Fri, Nov 27, 2020 at 09:54:49PM +0530, Mayuresh wrote:
> If I got it right, I should test some other dependency of libfribidi to
> see whether it runs into the same problem? Yes, can try.
Found grapviz and ffmpeg, both seem to be running fine and link with
libfribidi. [Hopefully just running
On Fri, Nov 27, 2020 at 05:13:13PM +0100, tlaro...@polynum.com wrote:
> What do you call "binary repo"? I was speaking about a:
>
> PKG_PATH=ftp://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/earmv7hf/9.1/All/
It's probably the same. I posted in the OP:
On Fri, Nov 27, 2020 at 09:30:43PM +0530, Mayuresh wrote:
> On Fri, Nov 27, 2020 at 04:54:20PM +0100, tlaro...@polynum.com wrote:
> > If on the remote NetBSD pkg directory there is the "good" version for
> > your system
>
> I don't think I have that. There is just local device and there is the
>
On Fri, Nov 27, 2020 at 04:54:20PM +0100, tlaro...@polynum.com wrote:
> Just to be sure: on your RPI, the kernel is 9.1 but the userland is not
> 8.x?
I didn't build it. It is the released image of 9.1 from netbsd.org.
Is there any way to check binutils like file names and sizes, like Martin
On Fri, Nov 27, 2020 at 04:54:20PM +0100, tlaro...@polynum.com wrote:
> If on the remote NetBSD pkg directory there is the "good" version for
> your system
I don't think I have that. There is just local device and there is the
binary repo. The binary repo was first tried and it did have the
Mayuresh writes:
> On Fri, Nov 27, 2020 at 10:56:01AM -0500, Greg Troxel wrote:
>> - remove all packages and rebuild from scratch
>
> Yes, as I posted in the last mail, (finally) all packages were built from
> scratch, nothing installed from binary, nothing installed from any other
> system.
On Fri, Nov 27, 2020 at 10:56:01AM -0500, Greg Troxel wrote:
> - remove all packages and rebuild from scratch
Yes, as I posted in the last mail, (finally) all packages were built from
scratch, nothing installed from binary, nothing installed from any other
system.
--
Mayuresh
Mayuresh writes:
> On Fri, Nov 27, 2020 at 08:46:08PM +0530, Mayuresh wrote:
>> In the meantime, as the error showed libfribidi, I am just rebuilding it.
>
> PS: I did a make clean replace of fribidi which did not solve it.
You are posting about a lot of issues, and I wonder if you are
On Fri, Nov 27, 2020 at 08:46:08PM +0530, Mayuresh wrote:
> On Fri, Nov 27, 2020 at 01:52:02PM +0100, tlaro...@polynum.com wrote:
> > Then Mayuresh has to verify that his versions of the packages were
> > not built "long" ago. Because this is an "old" version of Firefox
> > that is been used,
On Fri, Nov 27, 2020 at 08:46:08PM +0530, Mayuresh wrote:
> In the meantime, as the error showed libfribidi, I am just rebuilding it.
PS: I did a make clean replace of fribidi which did not solve it.
--
Mayuresh
On Fri, Nov 27, 2020 at 01:52:02PM +0100, tlaro...@polynum.com wrote:
> Then Mayuresh has to verify that his versions of the packages were
> not built "long" ago. Because this is an "old" version of Firefox
> that is been used, hence its dependencies---the version of its
> dependencies---have not
On Fri, Nov 27, 2020 at 01:57:52PM +0100, Martin Husemann wrote:
> On Fri, Nov 27, 2020 at 01:52:02PM +0100, tlaro...@polynum.com wrote:
> > BTW, are these packages "cross-compiled" on a system with an arm
> > processor that is not the target one (a more "muscled" machine than is
> > generally
On Fri, Nov 27, 2020 at 01:52:02PM +0100, tlaro...@polynum.com wrote:
> BTW, are these packages "cross-compiled" on a system with an arm
> processor that is not the target one (a more "muscled" machine than is
> generally available with a earmv7)? Because the fix was for
> elf32-arm.h and I wonder
On Fri, Nov 27, 2020 at 12:54:06PM +0100, Martin Husemann wrote:
> On Fri, Nov 27, 2020 at 12:46:36PM +0100, tlaro...@polynum.com wrote:
> > The strtab errors come from the linking hence from binutils. The only
> > causes I can imagine is whether there is a lib used that has been
> > compiled with
On Fri, Nov 27, 2020 at 12:46:36PM +0100, tlaro...@polynum.com wrote:
> The strtab errors come from the linking hence from binutils. The only
> causes I can imagine is whether there is a lib used that has been
> compiled with an old version of the binutils, or a component was
> compiled requering
On Tue, Nov 17, 2020 at 08:24:29AM +0100, tlaro...@polynum.com wrote:
> You should first try to rebuild it with an up-to-data compiler
> framework before one could assert if there is indeed a problem.
I built firefox52 from scratch over several days. Now I still get strtab
errors, now with
On Fri, Nov 20, 2020 at 07:21:26PM +0100, Martin Husemann wrote:
>
> -rwxr-xr-x 0 root wheel 149056 Jun 22 21:00 lib/libdbus-glib-1.so.2.3.4
>
> (that is from
> http://cdn.NetBSD.org/pub/pkgsrc/packages/NetBSD/earmv7hf/9.1/All/dbus-glib-0.110nb1.tgz)
>
> and file says:
>
>
On Thu, Nov 19, 2020 at 05:46:53PM +0100, Martin Husemann wrote:
> On Thu, Nov 19, 2020 at 05:38:20PM +0100, tlaro...@polynum.com wrote:
> > Patches were commited on 27 Aug 2019 by Robert Swindells, and we were at
> > 8.99 at this time.
>
> Ok, the pkg builder runs with a 9.0_STABLE userland, so
On Fri, Nov 20, 2020 at 12:01:55AM +0530, Mayuresh wrote:
> On Thu, Nov 19, 2020 at 05:25:33PM +0100, tlaro...@polynum.com wrote:
> > It will allow you to know if the problem is with the packages
>
> Let me begin with that hypothesis.
>
> I'll try to do binary installation of firefox52 on a qemu
On Thu, Nov 19, 2020 at 08:42:58PM +0100, Bodie wrote:
> > A couple of more questions:
> >
> > 1. Which is the highest firefox version which is rust free? Is it 52
> > (may be that's why it's retained?)
Got a reference that says it's firefox 53 is highest without rust.
On 19.11.2020 19:31, Mayuresh wrote:
On Thu, Nov 19, 2020 at 05:25:33PM +0100, tlaro...@polynum.com wrote:
It will allow you to know if the problem is with the packages
Let me begin with that hypothesis.
I'll try to do binary installation of firefox52 on a qemu instance.
Then
try to
On Thu, Nov 19, 2020 at 05:25:33PM +0100, tlaro...@polynum.com wrote:
> It will allow you to know if the problem is with the packages
Let me begin with that hypothesis.
I'll try to do binary installation of firefox52 on a qemu instance. Then
try to build it by cutting down as many options as
On Thu, Nov 19, 2020 at 05:46:53PM +0100, Martin Husemann wrote:
> On Thu, Nov 19, 2020 at 05:38:20PM +0100, tlaro...@polynum.com wrote:
> > Patches were commited on 27 Aug 2019 by Robert Swindells, and we were at
> > 8.99 at this time.
>
> Ok, the pkg builder runs with a 9.0_STABLE userland, so
On Thu, Nov 19, 2020 at 05:38:20PM +0100, tlaro...@polynum.com wrote:
> Patches were commited on 27 Aug 2019 by Robert Swindells, and we were at
> 8.99 at this time.
Ok, the pkg builder runs with a 9.0_STABLE userland, so it should have
those fixes. Maybe something in the firefox build system
On 19.11.2020 17:25, tlaro...@polynum.com wrote:
On Thu, Nov 19, 2020 at 09:03:12PM +0530, Mayuresh wrote:
On Thu, Nov 19, 2020 at 04:22:11PM +0100, Bodie wrote:
> > I still wish to know whether strtab errors are necessarily from the
> > pkg layer or is something in the base wrong - and in
On Thu, Nov 19, 2020 at 05:04:42PM +0100, Martin Husemann wrote:
> On Thu, Nov 19, 2020 at 09:03:12PM +0530, Mayuresh wrote:
> > On Thu, Nov 19, 2020 at 04:22:11PM +0100, Bodie wrote:
> > > > I still wish to know whether strtab errors are necessarily from the
> > > > pkg layer or is something in
On Thu, Nov 19, 2020 at 09:03:12PM +0530, Mayuresh wrote:
> On Thu, Nov 19, 2020 at 04:22:11PM +0100, Bodie wrote:
> > > I still wish to know whether strtab errors are necessarily from the
> > > pkg layer or is something in the base wrong - and in turn armv7.img is
> > > faulty.
>
> And any
On Thu, Nov 19, 2020 at 04:22:11PM +0100, Bodie wrote:
> > I still wish to know whether strtab errors are necessarily from the
> > pkg layer or is something in the base wrong - and in turn armv7.img is
> > faulty.
And any comment / confirmation on this from anyone?
--
Mayuresh
On 19.11.2020 16:12, Mayuresh wrote:
On Thu, Nov 19, 2020 at 03:32:20PM +0100, Bodie wrote:
I do not know internals, but building those packages takes a lot of
time
on these platforms or somewhere in the chain wrong toolchain version
was
used so everything is possible.
Or because earm,
On Thu, Nov 19, 2020 at 03:32:20PM +0100, Bodie wrote:
> I do not know internals, but building those packages takes a lot of time
> on these platforms or somewhere in the chain wrong toolchain version was
> used so everything is possible.
>
> Or because earm, earmv6hf and evbarm does not have any
On 19.11.2020 10:54, Mayuresh wrote:
On Thu, Nov 19, 2020 at 10:14:29AM +0100, Bodie wrote:
And did you notice during those years how browsers requirements raised
regarding HW and got thin regarding range of supported OSs?
pkgsrc maintains older versions say firefox52 which helps.
They
On Thu, Nov 19, 2020 at 10:14:29AM +0100, Bodie wrote:
> And did you notice during those years how browsers requirements raised
> regarding HW and got thin regarding range of supported OSs?
pkgsrc maintains older versions say firefox52 which helps.
raspbian has a custom build of FF which is
On 19.11.2020 09:24, Mayuresh wrote:
On Thu, Nov 19, 2020 at 08:27:22AM +0100, Bodie wrote:
Based on discussion on other list you were given tips what to do,
did you test them?
If there are any tips that I missed, please do point out.
[ If you are referring to a post that says my
On Thu, Nov 19, 2020 at 08:27:22AM +0100, Bodie wrote:
> Based on discussion on other list you were given tips what to do,
> did you test them?
If there are any tips that I missed, please do point out.
[ If you are referring to a post that says my toolchain might be invalid,
I already pointed
On 19.11.2020 03:08, Mayuresh wrote:
On Wed, Nov 18, 2020 at 08:32:42AM +0530, Mayuresh wrote:
Is nobody else facing this problem? The image and packages both are
downloaded from above locations, I have built nothing at my end.
Have filed port-arm/55812. Request attention please. Stuck
On Wed, Nov 18, 2020 at 08:32:42AM +0530, Mayuresh wrote:
> Is nobody else facing this problem? The image and packages both are
> downloaded from above locations, I have built nothing at my end.
Have filed port-arm/55812. Request attention please. Stuck without a
browser totally.
--
Mayuresh
On Tue, Nov 17, 2020 at 05:35:05PM +0530, Mayuresh wrote:
> On Tue, Nov 17, 2020 at 08:24:29AM +0100, tlaro...@polynum.com wrote:
> > The binary is too old and has been made with an invalid toolchain.
>
> I installed everything using pkg_add[1]. The binaries there don't look
> that old to me.
On Tue, Nov 17, 2020 at 08:24:29AM +0100, tlaro...@polynum.com wrote:
> The binary is too old and has been made with an invalid toolchain.
I installed everything using pkg_add[1]. The binaries there don't look
that old to me. E.g. firefox is of 17 Aug 2020.
In case it matters, the flash card
On Mon, Nov 16, 2020 at 05:33:55PM +0530, Mayuresh wrote:
> This is using binary packages from
> http://cdn.NetBSD.org/pub/pkgsrc/packages/NetBSD/earmv7hf/9.1/All
>
> on NetBSD armv7 9.1_STABLE NetBSD 9.1_STABLE (GENERIC) #0: Tue Nov 10
> 11:45:35 UTC 2020
>
On Mon, Nov 16, 2020 at 05:33:55PM +0530, Mayuresh wrote:
> BFD: /usr/pkg/lib/libdbus-glib-1.so.2: invalid string offset 9426 >= 2737 for
> section `.strtab'
How critical is dbus as far as firefox on RPI is concerned? As a quick fix
will switching dbus off solve above problem?
--
Mayuresh
This is using binary packages from
http://cdn.NetBSD.org/pub/pkgsrc/packages/NetBSD/earmv7hf/9.1/All
on NetBSD armv7 9.1_STABLE NetBSD 9.1_STABLE (GENERIC) #0: Tue Nov 10
11:45:35 UTC 2020
mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/evbarm/compile/GENERIC evbarm
#/usr/pkg/bin/firefox52
52 matches
Mail list logo
