libc6-dbg for VUzero4K

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Source Code of VTi isn't public source, so no, I don't know. The source code of the Original Image is though.

      Kernel doesn't need to be compiled for a debug version of libc, but will be if you have to set up a build environment; starting point is Vu+ Update

      It might be much easier to compile the libc on your Zero4k instead. A compiler and some of the tools needed are available in the database. (See my database entries: vuplus-support.org/wbb4/fileba…entry-list/&userID=207487 - I'd recommend to use GCC-10.2)


      But honestly: I don't understand what you need a debug version of libc for - if you don't mind to explain, maybe there is a better/simpler solution.
      Diskutiere nie mit einem Idioten. Er zieht dich auf sein Niveau runter und schlägt dich mit seiner Erfahrung.

    • It is not secret:
      I want to have complete build environment on VUzero4k. I installed a lot including perl and openssl from source. I installed also (with all dependances) valgrid. It starts but then it needs libc6-dbg.
      I compiled on vuzero4k program (well known) but it fails for particular programs with alignment trap. I would like to find out where and why it fails. I hope valgrid can help?
      In a meantime a searched and is libc.so.6 but not stripped what I need? Is it from glibc source? Or the name is really libc6-dbg.so or something like this? Can I use the newest source of glibc.tar.gz or is it possible to find out what is the version used in the image?

    • Did you compile valgrind by yourself? If not, try to; although I don't think it will resolve the issue.

      If you have a not stripped libc.so.6, then yes, it might resolve the problem; check with file /lib/libc.so.6.

      For testing purposes you could even setup a chroot environment and install a minimal system under it (I have one with ~1GB under /media/hdd/devroot with an older compiler and older libc).

      Yes, libc6 is built from glibc sources. You can switch to a newer glibc version, but be aware that you won't be able to distribute binaries compiled with that version, because they most probably use symbols that the older libc doesn't have (e.g. objdump -R /lib/ld-linux-armhf.so.3 | grep @GLIBC - the symbols containing @@GLIBC were introduced with that specific glibc version. Mine looks like:

      Source Code

      1. root@vusolo4k:~# objdump -R /lib/ld-linux-armhf.so.3 |grep @GLIBC
      2. 00027014 R_ARM_GLOB_DAT __stack_chk_guard@@GLIBC_2.4
      3. 0002701c R_ARM_GLOB_DAT __rseq_offset@@GLIBC_2.35
      4. 00027030 R_ARM_GLOB_DAT __rseq_size@@GLIBC_2.35
      5. 0002700c R_ARM_JUMP_SLOT __tls_get_addr@@GLIBC_2.4
      I'm running glibc-2.38).

      For the version of Oscam you are trying to compile: my guess is a bug in the patch, good luck in finding it, with that you are on your own.
      Diskutiere nie mit einem Idioten. Er zieht dich auf sein Niveau runter und schlägt dich mit seiner Erfahrung.

      The post was edited 1 time, last by rdamas ().

    • Really thank you for your great help!

      Yes, I compiled valgrind from source. It needed a lot of other staff to be compiled from source, like M4, autocont...

      I also believe the problem is caused by patch. I had a quick look on patch file and I found 3 int variables followed by some tables. I do not say it is the problem...

      Now I have to make 'hagebutten marmelade' so when I have some progress later I will inform you here

      (on Ubuntu valgrind works well, I will also have a look at the libraries and whether are stripped or not)

    • In VTI 15.0.02 is libc.so.6 version 2.21 size about 1MB, stripped (checked on ubuntu)

      So I downloaded the same source version. After installing gawk I managed to compile glibc, but not made yet "make install" :) first I make image backup. The 'make' run for about 70 minutes.

      The result is libc.so with symbolic link libc.so.6 pointing on it. The size is about 9MB
      I compared both libraries and look very similar! (happy) So it seems compiled so is not stripped, I hope make install will not strip it.
      I hope vuzero4k stay alive :)
      Do you have any sugesstions what not to do? Am I correct it will install non stripped version? If I am wrong, where to look for changes?
      I can not simply replace original so with compiled one? Probably not permittion to do simple replacement?

    • Seems to be correct, I guess locale data has not been built yet. I usually build glibc with the following set of commands:

      Source Code

      1. ../glibc/configure --prefix=/usr --sysconfdir=/etc --sharedstatedir=/var --localstatedir=/var --disable-werror
      2. make
      3. make install DESTDIR=/media/hdd/install
      4. make localedata/install-locale-files DESTDIR=/media/hdd/install
      5. make check

      You can safely test your build in a chroot environment on your harddisk (at e.g /media/hdd/install).
      Diskutiere nie mit einem Idioten. Er zieht dich auf sein Niveau runter und schlägt dich mit seiner Erfahrung.

    • Hi,

      I made image backup.
      Unpacked glibc.tar.gz into /tmp
      Created folder bbb
      Entered /tmp/glibc2-21/bbb
      Started config:
      .. /configure --prefix=/usr --disable-werror
      Now make is running....

      The last should be make install?
      Or I need to do something more?

      Danke!

    • I wouldn't unpack and build in /tmp as that's a memory based tmpfs. That's just eating memory the you probably need for building.

      Second last step would be "make install", last step "make localedata/install-local-files". IIRC, locale-data will not be built by default ("make check" will build them as well), and you probably need them; but they should already be installed in your running system, so you might skip that step as well.
      Diskutiere nie mit einem Idioten. Er zieht dich auf sein Niveau runter und schlägt dich mit seiner Erfahrung.

    • After make install the new libc.so.6 with 9MB length is already in /lib
      I started also make check but after 40mins failed because of no space in /tmp :)

      But valgrind now works!

      Thank you for great help!
      Now I will continue with debugging program failing with aligmnent trap.

      I think that program failing with aligmnent trap is compiled as fastest possible for 2 reasons:
      - it is about double size compared witth publicly available binaries
      - it tries to access data with full bus width 32 bits (?) => so it traps if wrongly declared variables
      Am I right?

    • I started working oscam under valgrind just to see what happens. (allatched log)
      First I was shocked that libcrypto has a problem. After searching on net I found out it is a deliberate wrong instruction and libcrypto is testing on which ARM it is running.
      But then I switched on "program" and nothing happened. When I checked situation with top command, I could see memcheck started by valgrind is eating up to 106% CPU time- very ocasionally
      some pictures were shown on TV. May be one every 30 seconds...

      I hope when I start problematic oscam it will show where it crashed though no picture would be created on time... (or any other idea?)
      May be to use moments when a static picture is broadcast hoping no transport data stream is huge data.... ?

      Still happy to have full development environment running on VUzero4K :)
      Files

      • test.txt

        (13.39 kB, downloaded 2 times, last: )

      The post was edited 1 time, last by sky59 ().