Official SDK from PocketBook

[rkomar]

Originally Posted by gshank

I got it working. I had converted to a tar.gz and moved the folder into place, because I was using a CentOS VM. Apparently I somehow missed the /usr/lib/libinkview.so in that process. Then it was having a hard time because of different curl linkages. So I switched to using Ubuntu and installing the deb. So far it looks good.

So, I finally got around to upgrading to this version of the SDK, and I'm having the same problems within a Slackware 13.37 distribution. The missing libinkview.so was easy to fix; you just have to run ldconfig as root after installing the SDK. However, I still have the curl linkages problem. I was able to get something working by replacing /usr/lib/libinkview.so with the one that came in the PBSDK/lib directory in the original SDK, and adding some extra static libcurl-related libs to LIBS in common.mk, but I would rather be able to use the FRSCSDK version of libinkview.so. Can anyone tell me what versions of curl and openssl they have on working systems?

[rkomar]

I wanted to point out that, on non-debian based systems, an easy way of unpacking the contents of the deb file without installing alien is:

ar x pbsdk-linux-1.0.6_i386.deb data.tar.gz

and the data.tar.gz file can be untarred directly into the root directory:

cd /; tar zxf <wherever-it-is>/data.tar.gz; ldconfig

[rkomar]

I tried installing pbsdk-linux-1.0.6_amd64.deb on my 64-bit linux system, but all the executables installed into /usr/bin are 32-bit. I don't have 32-bit compatibility libraries installed, so nothing really works. I don't really understand what the point of the pbsdk-linux-1.0.6_amd64.deb package is. Is the "amd64" part just there in the name to allow it to be installed on a 64-bit debian-based system?

[MartinZ]

I don't really understand what the point of the pbsdk-linux-1.0.6_amd64.deb package is. Is the "amd64" part just there in the name to allow it to be installed on a 64-bit debian-based system?

Good question. I think we should compare the .amd64 to the .x86 file by file to get to know this.
But i think for sure only two things can really differ:

• xxx.so files in "/usr/lib", "/usr/lib64" or "/usr/lib32", and not the xxx.so inside the "/usr/arm-linux" or the "usr/arm-none-linux-gnueabi" -forks. Cause those xxx.so are all ARM-code and not x86/amd64-code anyway.
• The Compiler tools like "g++", "gcc" or "ld", because this SDK uses a cross-compiler and for this reason these tools have to run on the PC's processor (which is a x86 or amd64)

I used 64-Bit-OpenSuse Linux 11.4 and (as far as I remember) after using YaST to add some missing libs (in the right version) and adding a few static links inside "/lib" (e.g. "xxx.so" pointing to "xxx.so.62") I got it mostly working.
I had compared /lib to /lib64 before and had spotted, that in the "/lib64" there already existed such static links, that were missing in the "/lib".

Moreover i am quite sure, that the emulator (make BUILD=emu) does not work on 64-Bit Linux (at least not "out of the box"). I can get the emulator running on my UBUNTU 32-Bit, but not on my OpenSuse 64-Bit.

I don't have 32-bit compatibility libraries installed

Where can i get something like that? Perhaps i would get emulator running on 64Bit this way. (It seems to be only the 32-Bit-"libinkview.so" that prevents emulator to run on 64Bit.)

The missing libinkview.so was easy to fix; you just have to run ldconfig as root after installing the SDK.

How exactly did you do that?

Do you know, how to configure QtCreator as an IDE for the SDKs?

[rkomar]

I downloaded both (i386 and amd64) versions, and the only difference is that libinkview.so has been moved from /usr/lib/ to /lib32/ in the amd64 version. Everything else is the same. I was previously running sergeyvl12's older SDK under a 32-bit system inside VirtualBox. I don't mind using the VirtualBox emulator for the BUILD=emu stuff, since I don't do it that often. But I was hoping to be able to build the BUILD=arm and BUILD=arm_gnueabi targets natively on my 64-bit system. Oh well.

If you can cross-compile to the ARM targets now, then you already have the 32-bit compatibility libraries installed on your system. The /usr/bin/arm-* programs would not run without them on a 64-bit system.

If you are installing using a package manager, then 'ldconfig' is probably already being executed on your system. Running /sbin/ldconfig -p | grep inkview will show you if libinkview.so is already cached and can be used for building. If it isn't, then just run 'ldconfig' as root, and it will be.

I don't know how to set up QtCreator or any other IDE. I'm a command-line kind of guy .

[MartinZ]

I don't know how to set up QtCreator or any other IDE. I'm a command-line kind of guy .

But how do you cope with compiler error messages then?

I am used to click on the error message and get the editor opened at the corrrect (or better say not correct) source line.

And to set breakpoints in source or to step my program inside the editor would be really fine.

Have you seen this ?
http://radikal.ru/F/s013.radikal.ru/...6b24d.png.html
He has got the "calc"-source in this QTCreator IDE including emulation and debugging.
That's what I want!
By the way: seen my improved "calcplus" ?

If you can cross-compile to the ARM targets now, then you already have the 32-bit compatibility libraries installed on your system. The /usr/bin/arm-* programs would not run without them on a 64-bit system.

I have not installed compatibility libraries (think you mean ia32-libs or so) actively myself. Perhaps OpenSuse has something like that with it by default. But i don't think so.

But I was hoping to be able to build the BUILD=arm and BUILD=arm_gnueabi targets natively on my 64-bit system

I am able to build arm_gnueabi targets as well as arm-(oABI) targets natively in 64Bit-OpenSuse11. The /usr/bin/arm-* programs is exactly what I think differs in the amd64 and the x86 package of Sergey'S SDK. Have you compared these files thoroughly?

But I was hoping to be able to build the BUILD=arm and BUILD=arm_gnueabi targets natively on my 64-bit system

If compatibility-libraries are necessary, why don't you install them?

[rkomar]

The editor I use is able to jump to source lines with errors if you run the make command inside it (I use vim, but I'm sure emacs would do the same). But I usually don't bother with this. I just run make in another terminal, look at the line number in the error output, and jump there in the editor. It's no big deal. Honestly, fixing compiler errors is a tiny part of the time it takes me write a program. Fixing logical errors is where most of my time is spent.

I haven't looked at calcplus yet, although it is on my list of things to do. However, I've never even used the default calculator on the PB device yet, so I'm not in a big hurry. I think I should put learning how to multi-quote somewhere higher on my list.

I use Slackware linux, and 32-bit compatibility libraries aren't part of the standard distribution. Eric Hameleers has made some packages and scripts available for creating your own 32-bit compatibility packages, and I have used them in the past (when Adobe's flash was only available as a 32-bit executable). However, the packages caused subtle problems when building 64-bit programs on my system (mostly through the pkgconfig system, and similar type configuration systems), so I just removed them. I've been using VirtualBox to run a 32-bit Slackware system for those times when I really need it, and that's where I've been building my PocketBook programs so far.

Anyway, I think I'll try building my own 64-bit cross-compiler suite and remove the need for the 32-bit compatibility libraries. The emulation stuff won't work, but that's okay for me.

[yuryfdr]

i wrote ebuild for gentoo for pbsdk. it get some library from ubuntoo that solve version incompatability of png and jpeg etc. sucsessfully tested at x86 and amd64 - emulator works. http://fedorchenko.net/ebuilds.php

[sergeyvl12]

Originally Posted by rkomar

I tried installing pbsdk-linux-1.0.6_amd64.deb on my 64-bit linux system, but all the executables installed into /usr/bin are 32-bit. I don't have 32-bit compatibility libraries installed, so nothing really works. I don't really understand what the point of the pbsdk-linux-1.0.6_amd64.deb package is. Is the "amd64" part just there in the name to allow it to be installed on a 64-bit debian-based system?

Hi!

I don't receive notifications for this thread through I'm subscribed ....

Actually, all the applications/libraries in this package are 32-bit.

There were 2 reasons why I did 32 and 64 bit packages:

1. alien needs architecture to make rpm. And if it will be only 32 bit package, there are no chances to install it on ubuntu or debian 64 bit;
2. 64-bit ubuntu uses lib32 for 32-bit libs but all the libs are going to "lib" in the 32-bit ubuntu.

Originally Posted by rkomar

Anyway, I think I'll try building my own 64-bit cross-compiler suite and remove the need for the 32-bit compatibility libraries. The emulation stuff won't work, but that's okay for me

Not a good idea, I think.

1. They implemented a good emulator (uses only gtk+, without libwine!!!);
2. You can easily create the build environment on you 64bit Slackware, using ia32-libs package from ubuntu and making the chroot environment. It was successfully installed on arch linux 64 by ava1ar (from russian forum);
3. Or even - without chroot! Just copy ia32-libs to /usr/lib32 directory; use LD_lIBRARY_PATH and -L/usr/lib32 to run compiler and LD_LIBRARY_PATH - to run "emu" application.

[sergeyvl12]

Originally Posted by MartinZ

Do you know, how to configure QtCreator as an IDE for the SDKs?

Eclipse - the best!

[rkomar]

Originally Posted by sergeyvl12

...Not a good idea, I think.

1. They implemented a good emulator (uses only gtk+, without libwine!!!);
2. You can easily create the build environment on you 64bit Slackware, using ia32-libs package from ubuntu and making the chroot environment. It was successfully installed on arch linux 64 by ava1ar (from russian forum);
3. Or even - without chroot! Just copy ia32-libs to /usr/lib32 directory; use LD_lIBRARY_PATH and -L/usr/lib32 to run compiler and LD_LIBRARY_PATH - to run "emu" application.

I noticed that libwine was no longer needed, and am pleasantly surprized by that. I'm hoping that I will be able to use it sometime in the future.

As I wrote above, I have linking problems with i386-libinkview on my 32-bit Slackware system. So, I have to assume that the ia32-libs use quite different header files from what is on my current Slackware 64-bit system (which has the same source packages as the 32-bit one). I'm not sure how I would install the header files for ia32-libs without interfering with my 64-bit system if I don't use a chroot system. And running a chroot system is more work than I want to take on.

I've got the 64-bit cross-compiler environment working for arm_gnueabi already, so I think I'll stick to that for now. No emu for me.

[MartinZ]

sergeyvl12 wrote:

Eclipse - the best!

could be true. But I think it is very big and complex, isn't it?

But my problem is not the decision for an IDE (though i would prefer an easy to use IDE), but how to get your or the "official" SDK working at all - in what IDE ever.

About 64Bit:

I get everything running (ARM, ARM-EABI as well as Emulator) on 32-Bit Ubuntu.
My "normal" system is 64-Bit OpenSuse and I would prefer to use this.
But, if I build for Emulator, I can not stable convince the gcc-system to
either:
-make a 64-Bit target, beacause of the (32-Bit) "libinkview.so"
or
-make a 32-bit target (adding "-m32" to gxx and gcc commandlines), because it always uses wrong libraries: sometimes it is the 64-Bit "glibc" (libgcc.a and some .o -files) that are wrong, sometimes it's libcurl.so. Adding -L\usr\lib or
-L\usr\lib32 does not solve this problem.
I got it running only once, when I renamed and replace the folder that contains the "libgcc.a" with the 32-Bit version. But after that, the cmake's check for a working gcc fails.
It's all in all does not seem easy to use the emulator on 64-Bit Systems.

Isn't there a posssibility to get a 64-Bit "libinkview.so" ??
Perhaps some kind of wrapper that is 64Bit but internally uses 32Bit-libinkview?

[rkomar]

Originally Posted by MartinZ

Perhaps some kind of wrapper that is 64Bit but internally uses 32Bit-libinkview?

I think that is impossible. The CPU runs in different modes in 32 and 64-bit modes.

[sergeyvl12]

Originally Posted by MartinZ

sergeyvl12 wrote:
could be true. But I think it is very big and complex, isn't it?

No. You can import makefile project in a minute.

Originally Posted by MartinZ

Isn't there a posssibility to get a 64-Bit "libinkview.so"
??

I asked, but without reply.

Please, try the following steps:
1. Install http://pbsdk.vlasovsoft.net/files/pb....0.6_amd64.deb
2. Download and unpack the ia32-libs (with deps) to your /usr/lib32 (ia32-libs is just libs). Or even better - you can borrow the these libs from your 32-bit Ubuntu.
3. Add -L/usr/lib32 to LDFLAGS of "emu";
4. Use LD_LIBRARY_PATH=/usr/lib32:$LD_LIBRARY_PATH when your run make;
5. Use LD_LIBRARY_PATH=/usr/lib32:$LD_LIBRARY_PATH when your run built application;

Please report the problems to this thread.

[MartinZ]

Hi Sergey,

I still got trouble with SDK and 32-Bit emulator-Build on 64-Bit OpenSuse:

./makepc.sh

...

[66%] Building C object CMakeFiles/inkdemo.dir/cimages/images.c.o
Linking C executable inkdemo                                                                                                  
/root/projects/sources/inkdemo/../../FRSCSDK/lib/libinkview.so: undefined reference to `curl_easy_cleanup@CURL_OPENSSL_3'     
/root/projects/sources/inkdemo/../../FRSCSDK/lib/libinkview.so: undefined reference to `curl_easy_perform@CURL_OPENSSL_3'
/root/projects/sources/inkdemo/../../FRSCSDK/lib/libinkview.so: undefined reference to `curl_easy_setopt@CURL_OPENSSL_3'
/root/projects/sources/inkdemo/../../FRSCSDK/lib/libinkview.so: undefined reference to `png_set_gray_1_2_4_to_8'
/root/projects/sources/inkdemo/../../FRSCSDK/lib/libinkview.so: undefined reference to `curl_easy_pause@CURL_OPENSSL_3'
/root/projects/sources/inkdemo/../../FRSCSDK/lib/libinkview.so: undefined reference to `curl_easy_init@CURL_OPENSSL_3'
/root/projects/sources/inkdemo/../../FRSCSDK/lib/libinkview.so: undefined reference to `curl_easy_getinfo@CURL_OPENSSL_3'
collect2: ld returned 1 exit status
make[2]: *** [inkdemo] Error 1
make[1]: *** [CMakeFiles/inkdemo.dir/all] Error 2
make: *** [all] Error 2

Perhaps "libinkview.so" was linked to a different "libcurl.so" than the one my compiler uses, or what's up here?