Sqlite and libreadline 6.2

[Giulio Sichel]

Hi,
I think that the sqlite package must be updated to link with libreadline 6.2.

$ sqlite3
sqlite3: can't load library 'libreadline.so.5'

In order to create an updated package for sqlite and to create some other packages I'd like to play with, I've tried to build Alt-F following the instructions in the wiki, but, so far,
the cross-compilation process has failed for some reason apparently tied to machine code generation for arm.

[João Cardoso]

On Monday, May 19, 2014 11:26:54 AM UTC+1, Giulio Sichel wrote:

Hi,
I think that the sqlite package must be updated to link with libreadline 6.2.

$ sqlite3
sqlite3: can't load library 'libreadline.so.5'

What box model? What Alt-F version?

[Giulio Sichel]

Il giorno lunedì 19 maggio 2014 12:40:20 UTC+2, João Cardoso ha scritto:

On Monday, May 19, 2014 11:26:54 AM UTC+1, Giulio Sichel wrote:

Hi,
I think that the sqlite package must be updated to link with libreadline 6.2.

$ sqlite3
sqlite3: can't load library 'libreadline.so.5'

What box model? What Alt-F version?

DNS-320 A1 with Alt-F 0.1RC4.

[João Cardoso]

Thanks, it's working for me now, it should be some Experimental release glitch:

[root@DNS-325]# sqlite3 

SQLite version 3.8.2 2013-12-06 14:53:30

Enter ".help" for instructions

Enter SQL statements terminated with a ";"

sqlite> 

I've tried to build Alt-F following the instructions in the wiki, but, so far, the cross-compilation process has failed for some reason apparently tied to machine code generation for arm.

For RC4 the build instructions has yet to be updated (and RC3 does not works on the DNS-320).

In any case, a build log is necessary to diagnose issues, do a 'make >& build.log'

[Added: in trunk, README.BUILD now contains terse build instructions for RC4 (it should work for trunk with minor changes to the svn checkout command)]

[Giulio Sichel]

Il giorno lunedì 19 maggio 2014 15:11:35 UTC+2, João Cardoso ha scritto:

Thanks, it's working for me now, it should be some Experimental release glitch:

[root@DNS-325]# sqlite3 

SQLite version 3.8.2 2013-12-06 14:53:30

Enter ".help" for instructions

Enter SQL statements terminated with a ";"

sqlite> 

It sounds strange. This is what I get from ldd:

$ ldd /usr/bin/sqlite3
        libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0xb6f63000)
        libreadline.so.5 => not found
        libncurses.so.5 => /usr/lib/libncurses.so.5 (0xb6f25000)
        libdl.so.0 => /lib/libdl.so.0 (0xb6f1b000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xb6f02000)
        libc.so.0 => /lib/libc.so.0 (0xb6ea1000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6e8e000)
        ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb6fea000)

$ ls -l /usr/lib/libreadline.so*
lrwxrwxrwx    1 root     root            16 Feb 27 16:53 /usr/lib/libreadline.so -> libreadline.so.6*
lrwxrwxrwx    1 root     root            18 Feb 27 16:53 /usr/lib/libreadline.so.6 -> libreadline.so.6.2*
-rwxrwxr-x    1 root     root        216964 Feb 27 16:53 /usr/lib/libreadline.so.6.2*

Thus I've tried by forcing a symbolic link:

sudo ln -s /usr/lib/libreadline.so.6.2 /usr/lib/libreadline.so.5

and now it works. I suppose I''ve to add this operation to my personal user script to recreate the link at boot.
 

I've tried to build Alt-F following the instructions in the wiki, but, so far, the cross-compilation process has failed for some reason apparently tied to machine code generation for arm.

For RC4 the build instructions has yet to be updated (and RC3 does not works on the DNS-320).

In any case, a build log is necessary to diagnose issues, do a 'make >& build.log'

[Added: in trunk, README.BUILD now contains terse build instructions for RC4 (it should work for trunk with minor changes to the svn checkout command)]

Regarding the Alt-F building procedure, these are the steps I've made:

svn checkout http://alt-f.googlecode.com/svn/trunk/alt-f alt-f-read-only
cd alt-f-read-only
export BLDDIR=$PWD/build
export PATH=$PATH:$PWD/bin:$BLDDIR/build_arm/staging_dir/usr/bin:
make O=$BLDDIR menuconfig
make O=$BLDDIR

I see no mkprepare.sh script in current dir. I've attached the build.log file as you suggested.

Thank you.

 

[João Cardoso]

On Monday, May 19, 2014 4:18:47 PM UTC+1, Giulio Sichel wrote:

Il giorno lunedì 19 maggio 2014 15:11:35 UTC+2, João Cardoso ha scritto:

Thanks, it's working for me now, it should be some Experimental release glitch:

[root@DNS-325]# sqlite3 

SQLite version 3.8.2 2013-12-06 14:53:30

Enter ".help" for instructions

Enter SQL statements terminated with a ";"

sqlite> 

It sounds strange. This is what I get from ldd:

$ ldd /usr/bin/sqlite3
        libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0xb6f63000)
        libreadline.so.5 => not found
        libncurses.so.5 => /usr/lib/libncurses.so.5 (0xb6f25000)
        libdl.so.0 => /lib/libdl.so.0 (0xb6f1b000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xb6f02000)
        libc.so.0 => /lib/libc.so.0 (0xb6ea1000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6e8e000)
        ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb6fea000)

The issue is  libreadline.so.5, it should be libreadline.so.6. I currently have

[root@DNS-325]# ldd /usr/bin/sqlite3

        libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0xb6e71000)

        libreadline.so.6 => /usr/lib/libreadline.so.6 (0xb6e33000)

        libncurses.so.5 => /usr/lib/libncurses.so.5 (0xb6df5000)

        libdl.so.0 => /lib/libdl.so.0 (0xb6deb000)

        libpthread.so.0 => /lib/libpthread.so.0 (0xb6dd2000)

        libc.so.0 => /lib/libc.so.0 (0xb6d71000)

        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6d5e000)

        ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb6f1a000)

Probably a experimental release link flaw, as you suggested (you haven't downloaded and installed any Alt-F package, have you? RC3 packages might be incompatible with RC4)

$ ls -l /usr/lib/libreadline.so*
lrwxrwxrwx    1 root     root            16 Feb 27 16:53 /usr/lib/libreadline.so -> libreadline.so.6*
lrwxrwxrwx    1 root     root            18 Feb 27 16:53 /usr/lib/libreadline.so.6 -> libreadline.so.6.2*
-rwxrwxr-x    1 root     root        216964 Feb 27 16:53 /usr/lib/libreadline.so.6.2*

Thus I've tried by forcing a symbolic link:

sudo ln -s /usr/lib/libreadline.so.6.2 /usr/lib/libreadline.so.5

and now it works. I suppose I''ve to add this operation to my personal user script to recreate the link at boot.
 

I've tried to build Alt-F following the instructions in the wiki, but, so far, the cross-compilation process has failed for some reason apparently tied to machine code generation for arm.

For RC4 the build instructions has yet to be updated (and RC3 does not works on the DNS-320).

In any case, a build log is necessary to diagnose issues, do a 'make >& build.log'

[Added: in trunk, README.BUILD now contains terse build instructions for RC4 (it should work for trunk with minor changes to the svn checkout command)]

Regarding the Alt-F building procedure, these are the steps I've made:

svn checkout http://alt-f.googlecode.com/svn/trunk/alt-f alt-f-read-only
cd alt-f-read-only
export BLDDIR=$PWD/build
export PATH=$PATH:$PWD/bin:$BLDDIR/build_arm/staging_dir/usr/bin:
make O=$BLDDIR menuconfig
make O=$BLDDIR

Basically correct, but you also have to add $HOSTDIR/usr/bin to the path. The 'export' script does that (and more).

The issue is happening at 'makeinfo', I'm using version 4.13, both at opensuse-12.1 and opensuse-13.1. What's your's? and what linux distro?

The current README.BUILD says:

. exports dns323 # defines the firmware to be built and some needed variables

make >& build-dns323.log # make it all, logging to build-dns323.log

./mkinitramfs.sh # create the root filesystem

./mkfw.sh # create the firmware files

'exports' must be sourced, not executed.

Some mk*.sh scripts will ask for the root password; this is needed to

mount the generated ext2 rootfs as a loop device and manipulate it. See

the source.

When finished, you should find:

-in $BINARIES, the kernel, "zImage", the root filesystem image, "rootfs.arm.ext2",

 and the firmware files, "Alt-F-RC4-<model>.bin"

-in $ROOTFS you will find the directory structure used to create the

 root filesystem image, "rootfs.arm.ext2".

-in $KERNEL the built linux kernel

You should remove the current '.config' file, 'exports'  copies the correct one from local/..., depending on its arguments, which can be any of dns323, dns321, dns325 (you want this), or pkgs. Without a '.config' file or arguments 'exports' prints a usage message.

Does it works for you? (a fresh build is recommended, do a 'rm -rf build', the download dir 'dl' will be preserved saving all packages download time)

Thanks

[Giulio Sichel]

Il giorno lunedì 19 maggio 2014 18:04:06 UTC+2, João Cardoso ha scritto:

Probably a experimental release link flaw, as you suggested (you haven't downloaded and installed any Alt-F package, have you? RC3 packages might be incompatible with RC4)

 

I've installed some packages with the Alt-F package manager (both through the administration page and the ipkg command). Did I make a mistake?
The repos used are these:
http://sourceforge.net/projects/alt-f/files/pkgs/stable

http://sourceforge.net/projects/alt-f/files/pkgs/unstable

 

 Basically correct, but you also have to add $HOSTDIR/usr/bin to the path. The 'export' script does that (and more).

The issue is happening at 'makeinfo', I'm using version 4.13, both at opensuse-12.1 and opensuse-13.1. What's your's? and what linux distro?

My makeinfo version is 5.2 on Archlinux.
 

The current README.BUILD says:

. exports dns323 # defines the firmware to be built and some needed variables

make >& build-dns323.log # make it all, logging to build-dns323.log

./mkinitramfs.sh # create the root filesystem

./mkfw.sh # create the firmware files

'exports' must be sourced, not executed.

Some mk*.sh scripts will ask for the root password; this is needed to

mount the generated ext2 rootfs as a loop device and manipulate it. See

the source.

When finished, you should find:

-in $BINARIES, the kernel, "zImage", the root filesystem image, "rootfs.arm.ext2",

 and the firmware files, "Alt-F-RC4-<model>.bin"

-in $ROOTFS you will find the directory structure used to create the

 root filesystem image, "rootfs.arm.ext2".

-in $KERNEL the built linux kernel

You should remove the current '.config' file, 'exports'  copies the correct one from local/..., depending on its arguments, which can be any of dns323, dns321, dns325 (you want this), or pkgs. Without a '.config' file or arguments 'exports' prints a usage message.

Does it works for you? (a fresh build is recommended, do a 'rm -rf build', the download dir 'dl' will be preserved saving all packages download time)

 
I did:

rm .config
export BLDDIR=$PWD/build
. exports dns323
make &> build-dns323.log

and it compiles but it halts with the same errors. Should I replace "dns323" with "dns325" also?
If compilation errors depend on the makeinfo version, I could build the whole thing on a debian system.

[João Cardoso]

On Monday, May 19, 2014 8:17:32 PM UTC+1, Giulio Sichel wrote:

Il giorno lunedì 19 maggio 2014 18:04:06 UTC+2, João Cardoso ha scritto:

Probably a experimental release link flaw, as you suggested (you haven't downloaded and installed any Alt-F package, have you? RC3 packages might be incompatible with RC4)

 

I've installed some packages with the Alt-F package manager (both through the administration page and the ipkg command). Did I make a mistake?
The repos used are these:
http://sourceforge.net/projects/alt-f/files/pkgs/stable

http://sourceforge.net/projects/alt-f/files/pkgs/unstable

 

 Basically correct, but you also have to add $HOSTDIR/usr/bin to the path. The 'export' script does that (and more).

The issue is happening at 'makeinfo', I'm using version 4.13, both at opensuse-12.1 and opensuse-13.1. What's your's? and what linux distro?

My makeinfo version is 5.2 on Archlinux.

I have installed makeinfo 5,2 and I can reproduce the issue.

According to the reply to [bug #38997] "@itemx must follow @item"  http://osdir.com/ml/bug-texinfo-gnu/2013-05/msg00003.html this is now the expected behaviour and will not be "fixed", so the only solution is to use makeinfo 4.13. I will try a fix for this.

 

 

The current README.BUILD says:

. exports dns323 # defines the firmware to be built and some needed variables

make >& build-dns323.log # make it all, logging to build-dns323.log

./mkinitramfs.sh # create the root filesystem

./mkfw.sh # create the firmware files

'exports' must be sourced, not executed.

Some mk*.sh scripts will ask for the root password; this is needed to

mount the generated ext2 rootfs as a loop device and manipulate it. See

the source.

When finished, you should find:

-in $BINARIES, the kernel, "zImage", the root filesystem image, "rootfs.arm.ext2",

 and the firmware files, "Alt-F-RC4-<model>.bin"

-in $ROOTFS you will find the directory structure used to create the

 root filesystem image, "rootfs.arm.ext2".

-in $KERNEL the built linux kernel

You should remove the current '.config' file, 'exports'  copies the correct one from local/..., depending on its arguments, which can be any of dns323, dns321, dns325 (you want this), or pkgs. Without a '.config' file or arguments 'exports' prints a usage message.

Does it works for you? (a fresh build is recommended, do a 'rm -rf build', the download dir 'dl' will be preserved saving all packages download time)

 
I did:

rm .config
export BLDDIR=$PWD/build

You don't need to define BLDDIR., it's 'exports' optional second argument, and will be $PWD/build if not specified.:

Usage: . exports.sh [-f (force)] [board (dns321 dns323 dns325 pkgs )] [build dir]

 

. exports dns323
make &> build-dns323.log

and it compiles but it halts with the same errors. Should I replace "dns323" with "dns325" also?

Yes.

dns323: creates fw for the 323, CH3SNAS and DUO-35LR

dns321: for the DNS-321

dns325: for the DNS-320/DNS-325

pkgs: create all packages

 

If compilation errors depend on the makeinfo version, I could build the whole thing on a debian system.

You can just download, configure, build and install (in /usr/local/bin by default) textinfo-4.13, and make sure that /usr/local/bin is ahead of /usr/bin in your PATH

[João Cardoso]

My makeinfo version is 5.2 on Archlinux.

I have installed makeinfo 5,2 and I can reproduce the issue.

According to the reply to [bug #38997] "@itemx must follow @item"  http://osdir.com/ml/bug-texinfo-gnu/2013-05/msg00003.html this is now the expected behaviour and will not be "fixed", so the only solution is to use makeinfo 4.13. I will try a fix for this.

 

I think that I found a fix -- it works for me when I uninstall my system's texinfo-4.13 and install texinfo-5.2 from source.

Can you please try: [edited]

if test -n "$OPATH"; then PATH=$OPATH; fi
rm -rf .config build
svn update
. exports dns325
make >& build-dns325.log && echo OK || echo FAIL

if the make succeeds, to create the firmware do:

./mkinitramfs.sh sqsplit # sqsplit only applies to the DNS-320/325
./mkfw.sh sqsplit        # sqsplit only applies to the DNS-320/325

However, even if it all succeeds, I don't advise you to flash the resulting firmware if you don't have a serial adapter.

Unfortunately kexec is not working for the DNS-320/325, so you will not be able to try the firmware without flashing it.

RC4 release is really soon now, unless another show-stop issue appears.

Thanks

PS: if you want to build all packages (in order to discover other issues), just do:

. exports pkgs
make >& build-pkgs.log && echo OK || echo FAIL
./mkpkgs.sh -all

You current build and downloads will be preserved and reused

[Giulio Sichel]

Il giorno mercoledì 21 maggio 2014 21:10:00 UTC+2, João Cardoso ha scritto:

Can you please try: [edited]

if test -n "$OPATH"; then PATH=$OPATH; fi
rm -rf .config build
svn update
. exports dns325
make >& build-dns325.log && echo OK || echo FAIL

This time errors are encountered in building e2fsprogs, so we have definitely moved forward. I've attached only the part of
the log file containing errors.
I'm sorry but these days spare time is lacking to dig deeper by myself.
 

if the make succeeds, to create the firmware do:

./mkinitramfs.sh sqsplit # sqsplit only applies to the DNS-320/325
./mkfw.sh sqsplit        # sqsplit only applies to the DNS-320/325

However, even if it all succeeds, I don't advise you to flash the resulting firmware if you don't have a serial adapter.

Unfortunately kexec is not working for the DNS-320/325, so you will not be able to try the firmware without flashing it.

RC4 release is really soon now, unless another show-stop issue appears.

Thanks

My real intention was not to flash a new firmware but just to rebuild all those packages that are not properly working, like sqlite3,
and to build some new packages, like an IRC client. I suppose that the construction process for preparing an ipkg file to be installed
on the file system needs, al least, that all the core packages included in firmware have been built successfully, am I wrong?

Thank you

[João Cardoso]

On Thursday, May 22, 2014 11:18:19 PM UTC+1, Giulio Sichel wrote:

Il giorno mercoledì 21 maggio 2014 21:10:00 UTC+2, João Cardoso ha scritto:

Can you please try: [edited]

if test -n "$OPATH"; then PATH=$OPATH; fi
rm -rf .config build
svn update
. exports dns325
make >& build-dns325.log && echo OK || echo FAIL

This time errors are encountered in building e2fsprogs, so we have definitely moved forward. I've attached only the part of
the log file containing errors.

Sorry, the last SVN commit raised a lot of problems, update to rev 2955 first, then build it all again:

rm -rf build
svn -r 2955 update
. exports -f dns325
make >& build-dns325.log && echo OK || echo FAIL

 

I'm sorry but these days spare time is lacking to dig deeper by myself.
 

if the make succeeds, to create the firmware do:

./mkinitramfs.sh sqsplit # sqsplit only applies to the DNS-320/325
./mkfw.sh sqsplit        # sqsplit only applies to the DNS-320/325

However, even if it all succeeds, I don't advise you to flash the resulting firmware if you don't have a serial adapter.

Unfortunately kexec is not working for the DNS-320/325, so you will not be able to try the firmware without flashing it.

RC4 release is really soon now, unless another show-stop issue appears.

Thanks

My real intention was not to flash a new firmware but just to rebuild all those packages that are not properly working, like sqlite3,
and to build some new packages, like an IRC client. I suppose that the construction process for preparing an ipkg file to be installed
on the file system needs, al least, that all the core packages included in firmware have been built successfully, am I wrong?

You only need to build the package in cause, and its requirements. But its's safer to compile it all, as some dependencies are not explicit, as it is assumed that they exists in the base firmware. The base firmware is the dns323, so you only need to do a '. exports -f dns323' followed by a make.

For building a specific package, do afterwards a 'make <package_name>' (*), such as 'make sqlite3', and hopefully its requirements will also be built.

After the build, verify that its OK by doing './mkpkg.sh <package_name'. (*) or do a 'make menuconfig'

For new packages you need to build the whole package set, i.e., '. exports -f pkgs', as the new package might need other, already existing, packages.

In the above you can reuse the build directory, as long as there are no changes to the base toolchain configuration. Tricky.

 

Thank you