LXR for Ruby interpreter? - c

I'm trying to track down a bug caused by the intersection of MRI 1.8.7 and libxml-1.1.3, and I need to do some digging around in the codebase of the Ruby interpreter itself. The SVN browser is of limited utility; what I'd really like is to use LXR, which hyperlinks a C codebase for easy navigation, e.g. http://lxr.linux.no/perl+perl-5.10.1/utf8.c
I can certainly set up LXR on my machine, but does anyone know if there's a public LXR for Ruby out there? Google is not very helpful: http://www.google.com/search?ie=UTF-8&q=lxr+ruby

I still haven't found a public LXR for MRI, so I set up one on my machine. Here's how to do it on Ubuntu 10.10:
: josh#josh; cat /etc/issue
Ubuntu 10.10 \n \l
: josh#josh; sudo aptitude install apache2 lxr
: josh#josh; sudo vim /etc/apache2/sites-available/default
: josh#josh; tail -6 /etc/apache2/sites-available/default
Alias /lxr /usr/share/lxr
Options All
AllowOverride All
: josh#josh; sudo vim /usr/share/lxr/http/.htaccess
: josh#josh; sudo cat /usr/share/lxr/http/.htaccess
SetHandler cgi-script
: josh#josh; sudo mkdir -p /usr/share/lxr/source/1.8.7-p334
: josh#josh; cd /usr/share/lxr/source/1.8.7-p334
: josh#josh; sudo tar xvjf /tmp/ruby-1.8.7.tar.bz2
: josh#josh; sudo mv ruby-1.8.7 ruby
: josh#josh; sudo vim /usr/share/lxr/source/versions
: josh#josh; sudo cat /usr/share/lxr/source/versions
1.8.7-p334
: josh#josh; sudo ln -s /usr/share/lxr/source/1.8.7-p334 /usr/share/lxr/source/defversion
: josh#josh; sudo genxref ruby
Starting pass 1: Collect identifier definitions.
(Pass 1) vms/vmsruby_private.c (993), file 1 of 262…
[...]
(Pass 3) identifier 8200 of maximum 17136…
(Pass 3) identifier 8300 of maximum 17136…
Completed pass 3 (0s):Information on 8316 identifiers dumped to disk.
: josh#josh; sudo chmod -R o+r .
: josh#josh; sudo vim /usr/share/lxr/http/lxr.conf
: josh#josh; sudo cat /usr/share/lxr/http/lxr.conf
# Configuration file.
# [...]
# The source is here.
sourceroot: /usr/share/lxr/source/$v/ruby/
srcrootname: Ruby
# [...]

Its not LXR, but I did a lot of that recently and found Understand extremely helpful. It'll let you click on any symbol and go to a definition/declaration and do simple call graphing and other static analysis. I just wish it supported Ruby source too.
On another note, libxml is still hopelessly broken, if you can migrate to Nokogiri it'll save you a lot of grief. Their APIs are very similar.

Introducing another code cross reference site, for general use besides linux kernel
https://code-grep.com

Related

MOTIF compiling error / X11/intrinsic.h missing

i have MOTIF installed X11
a easy program is saved as hello.c
there is the following message
where can i get the X11/intrinsic.h , file ???
need help to compile
my system : MX-16 Linux Debian Jessie / i386
Code:
hans#mx1:~/Documents
$ cc push.c -o push -lXm -lXt -lX11
In file included from push.c:2:0:
/usr/include/Xm/Xm.h:59:27: fatal error: X11/Intrinsic.h: No such file or directory
#include <X11/Intrinsic.h>
^
compilation terminated.
hans#mx1:~/Documents
I installed the libxt-dev package on my Debian box:
apt-get install libxt-dev
Then the proper header will be installed:
# find /usr -name "Intrinsic.h" -print
/usr/include/X11/Intrinsic.h
Been using xv for several decades now -- I always find myself trying to rebuild it.
The copy on my system came from libxt-dev
$ locate Intrinsic
/usr/include/X11/Intrinsic.h
/usr/include/X11/IntrinsicI.h
/usr/include/X11/IntrinsicP.h
$ dpkg-query -S /usr/include/X11/Intrinsic.h
libxt-dev:amd64: /usr/include/X11/Intrinsic.h
You may want to install and use apt-file - you can ask it for a filename and it will tell you which packages (that you don't even have to have installed - just from the repos in your sources.lists) contain a file with that name

Libraries compatibilty by cross-compiling node for armv5

I try to cross-compile node for my QNAP armv5te machine, on my Ubuntu 14.04 Desktop x64.
A node QPKG exists in QNAP App-center, but its version is old (0.8.22).
Here are informations about the server :
Linux SERVERNAME 3.4.6 #1 Mon Dec 29 06:00:47 CST 2014 armv5tel unknown
Processor name : Feroceon 88F6281 rev 1 (v5l) # 1.2 GHz
BogoMIPS : 1196.85
Features : swp half thumb fastmult edsp
CPU implementer : 0x56
CPU architecture: 5TE
CPU variant : 0x2
CPU part : 0x131
CPU revision : 1
Hardware : Feroceon-KW
ARM Revision : 0000
Serial : 0000000000000000
Here's the command I used on my desktop :
apt-get update
apt-get upgrade
apt-get install emdebian-archive-keyring
apt-get install libc6-armel-cross libc6-dev-armel-cross
apt-get install binutils-arm-linux-gnueabi
apt-get install gcc-4.7-arm-linux-gnueabi
apt-get install g++-4.7-arm-linux-gnueabi
apt-get install u-boot-tools
apt-get install libncurses5-dev
ln -s /user/bin/arm-linux-gnueabi-gcc-4.7 /usr/bin/arm-linux-gnueabi-gcc
ln -s /user/bin/arm-linux-gnueabi-g++-4.7 /usr/bin/arm-linux-gnueabi-g++
wget http://nodejs.org/dist/node-v0.10.35/node-v0.10.35.tar.gz
tar -zxf node-v0.10.35.tar.gz
cd node-v0.10.35
export TOOL_PREFIX="arm-linux-gnueabi"
export CC="${TOOL_PREFIX}-gcc"
export CXX="${TOOL_PREFIX}-g++"
export AR="${TOOL_PREFIX}-ar"
export RANLIB="${TOOL_PREFIX}-ranlib"
export LINK="${CXX}"
export CCFLAGS="-march=armv5te -mfpu=softfp -marm"
export CXXFLAGS="-march=armv5te -mno-unaligned-access"
export OPENSSL_armcap=5
export GYPFLAGS="-Darmeabi=soft -Dv8_can_use_vfp_instructions=false -Dv8_can_use_unaligned_accesses=false -Darmv7=0"
export VFP3=off
export VFP2=off
./configure --without-snapshot --dest-cpu=arm --dest-os=linux --prefix="/root/.nvm/v0.10.35"
make -j 4
make install
tar -zcf node-v0.10.35-linux-armv5.tar.gz v0.10.35
The compilation doesn't show any failures with these parameters. So after that I send the tarball to my QNAP server:
scp /root/.nvm/node-v0.10.35-linux-armv5.tar.gz admin#SERVERNAME:/share/HDA_DATA/.qpkg/nodejs
ssh SERVERNAME -l admin
cd /share/HDA_DATA/.qpkg/nodejs
tar -zxf node-v0.10.35-linux-armv5.tar.gz
ln -s v0.10.35 node
All my env variables are already set on my server. Now I can test node binary...
# node -v
node: /usr/lib/libstdc++.so.6: version `CXXABI_ARM_1.3.3' not found (required by node)
node: /lib/libc.so.6: version `GLIBC_2.15' not found (required by node)
node: /lib/libc.so.6: version `GLIBC_2.11' not found (required by node)
node: /lib/libc.so.6: version `GLIBC_2.7' not found (required by node)
Finally I have an error because C libraries are not the same on Ubuntu and Qnap, for Ubuntu desktop I have ldd (Ubuntu EGLIBC 2.19-0ubuntu6.5) 2.19 and on QNAP ldd (GNU libc) 2.5.
libc-dev and libstdc++ are packages handled by Optware ipkg on Qnap, (old versions too).
My question is what is the better way to fix this problem ? Force updating libs on server ? (and how to do that ?) Or maybe use static libs during compilation ? ( and how to do that too ?) Or other options ?
EDIT:
After my conversation with artless-noise, I understood I had several ways to fix library dependencies...
Dependencies in question:
# ldd /opt/bin/node
/opt/node/bin/node: /usr/lib/libstdc++.so.6: version `CXXABI_ARM_1.3.3' not found (required by /opt/node/bin/node)
/opt/node/bin/node: /lib/libc.so.6: version `GLIBC_2.15' not found (required by /opt/node/bin/node)
/opt/node/bin/node: /lib/libc.so.6: version `GLIBC_2.11' not found (required by /opt/node/bin/node)
/opt/node/bin/node: /lib/libc.so.6: version `GLIBC_2.7' not found (required by /opt/node/bin/node)
libdl.so.2 => /lib/libdl.so.2 (0xb6ed2000)
librt.so.1 => /lib/librt.so.1 (0xb6ec3000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb6de2000)
libm.so.6 => /lib/libm.so.6 (0xb6d32000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6d1e000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb6cfe000)
libc.so.6 => /lib/libc.so.6 (0xb6bca000)
/lib/ld-linux.so.3 (0xb6ee4000)
Copy libraries from Ubuntu GCC to the target machine, and override default ones :
It could be really dangerous, and may brick the system. To more, my goal is to create a QPKG for QNAP community, so ask people to override their C libs is not a really nice method.
Copy libraries and cohabit with original ones :
A nice method, just need to set LD_LIBRARY_PATH to a dir containing newest libs for the application. But I found an error using this method, again with c++ lib.
The error:
node: symbol lookup error: /opt/node/lib/c/libstdc++.so.6: undefined symbol: _ZNSt11__timepunctIcE2idE, version GLIBCXX_3.4
Create a static application :
Finally, I found the way to do it without any errors during compilation, and during execution on the target machine. Just need to add some flags.
New flags:
export CCFLAGS="-march=armv5te -mfpu=softfp -marm -static-libgcc"
export CXXFLAGS="-march=armv5te -mno-unaligned-access -static-libstdc++"
export LDFLAGS="-static"
Checking dynamic library links:
# ldd /opt/bin/node
not a dynamic executable
# npm version
{ test: '1.0.0',
npm: '2.3.0',
ares: '1.9.0-DEV',
http_parser: '1.0',
modules: '11',
node: '0.10.35',
openssl: '1.0.1j',
uv: '0.10.30',
v8: '3.14.5.9',
zlib: '1.2.8' }
EDIT: Finally a problem is again here, most of the node functions work, but not http...
i tested a simple script (from NodeJS API) to get info about a web page:
http.get("http://www.google.com/index.html", function(res) {
console.log("Got response: " + res.statusCode);
}).on('error', function(e) {
console.log("Got error: " + e.message);
});
And I got Got error: getaddrinfo ENOTFOUND, is it possible because node is static some features can't work ?
Finally, instead of trying to change libraries, I decided to have a better cross-compiler which matches with my target perfectly.
I used Crosstools-NG for that, but I could use the official QNAP Maxwell-ARM Toolchain too (I saw it too late...)
gcc (GCC) 4.2.4
g++ (GCC) 4.2.4
GNU ld (crosstool-NG 1.20.0) 2.19.1
ldd (crosstool-NG) 1.20.0
Python 2.7.6 (with gyp)
But a problem was always here, there's a node dependecy (libuv) which uses a library named linux-atomic, and that library was introduced in GCC since version 4.4.X. So here is the workaround I made to fix it :
cd /src
wget -q https://ftp.gnu.org/gnu/gcc/gcc-4.6.3/gcc-core-4.6.3.tar.gz
tar -zxf gcc-core-4.6.3.tar.gz
sed -i -e 's/define HIDDEN.*/define HIDDEN/' /src/gcc-4.6.3/gcc/config/arm/linux-atomic.c
export CC=arm-none-linux-gnueabi-gcc
export AR=arm-none-linux-gnueabi-ar
export RANLIB=arm-none-linux-gnueabi-ranlib
cd /src/gcc-4.6.3/gcc/config/arm
libtool --tag=CC --mode=compile $CC -g -O2 -MT linux-atomic.lo -MD -MP -MF linux-atomic.Tpo -c -o linux-atomic.lo linux-atomic.c
$AR cru /src/gcc-4.6.3/gcc/config/arm/.libs/liblinux-atomic.a /src/gcc-4.6.3/gcc/config/arm/.libs/linux-atomic.o
$RANLIB /src/gcc-4.6.3/gcc/config/arm/.libs/liblinux-atomic.a
# IMPORTANT: Assign environment variables like I made in my question above.
# Go to node src dir and configure
./configure --without-snapshot --dest-cpu=arm --dest-os=linux --prefix="${PREFIX_DIR}"
# When configuration is done, edit out/node.target.mk
vi out/node.target.mk
# Find LD_INPUTS files list and add your new library as last one:
# -> /src/gcc-4.6.3/gcc/config/arm/.libs/liblinux-atomic.a
# Now you can build node !
make -j4 #-jX where X is the number of available cores
make install DESTDIR=$TEMPDIR # Use DESTDIR to avoid installation directly in $PREFIX_DIR path
Workaround reference
With that configuration, I also could compile node with GCC 4.1.3 for x86 processors. And I made QPKG for QNAP users who doesn't want to compile by themselves : https://github.com/jbltx/nodejs-QPKG/tree/master/node-v0.10.35

binutils for compiling/cross compiling gcc for sony reader prs900

I have a rooted Sony reader PRS900, running an OEM linux kernel 2.6.23, and I can run arbitrary bash/sh scripts from the SD memory card drive on it.
I want to compile and execute C programs ... but am having dynamic linker problems.
I first tried loading gcc for arm (slackware 14's) on the SD card, but even when using LD_LIBRARY_PATH, the sony will fail to "find" most newer elf .so libraries, although newer programs which use old libraries do in fact run properly. ( I can run slackware-14's "readelf" just fine. but not ar, or gcc...) If I try to upgrade /lib/ld-linux.so.3, I get a "kernel too old" error message.
I then tried an old slackware 10 version of gcc, and although that solves the elf library "finding" problem -- I then get an "illegal instruction" error when running programs.
So -- I need to make a gcc cross compiler on my x86 for the proper ARM processor and then use it to recompile gcc for the sony.
But I don't know what legacy version of binutils I must use since it assembles and links to ELF format that either works or breaks on the sony.
The Sony is running an arm6 compatible MX31 EBX5016 processor.
and some relevant OEM file names on the sony are:
/lib/ld-2.5.so
/lib/ld-linux.so.3 -> ld-2.5.s
/lib/libc-2.5.so
/lib/libgcc_s.so.1
I know, from the kernel, that gcc-4.2.0 was used.
I would prefer to use the newest version of gcc which will work with whatever legacy binutils package I need to install.
How do I figure out which version of binutils that I need, and what options I have for gcc?
Thanks!
You can find the toolchain Sony used over at their Source Code Distribution Service site:
http://www.sony.net/Products/Linux/Audio/PRS-900.html
It seems sourceryg++-4.2-28armeabi.src.rpm is the compiler.
I would not recommend running the compiler on the device itself; it will be very slow.
Regarding the "Illegal instruction" issue, it's possible that your compiler is generating too new instructions, and passing -march=armv6 might just solve it.
Sony is using a kernel put out by motavista linux; According to montavista, the compiler for that kernel was made with binutils 2.17. I wasn't able to find any way to figure out which binutils originally developed with which version of GCC from the gnu project itself. Even the repository upload dates vary inconsistently... but I did find which binutils montavista was developed with.
The minimum version of a working cross compiler from stock GCC source code that I was able to make, came from gcc-4.2.0 with binutils 2.19.1 and glibc-2.5 using glibc-ports-2.5 for the arm processor/linux extensions.
The rest of this answer details building that cross compiler from scratch, as a reference for other people wanting to build a linux cross compiler for arm with the gnu c library included; eg: gcc with eabi and glibc for linux: arm-linux-gnueabi- tool.
It's a totally non-trivial problem, and I hope my notes are useful to others.
The sony reader PRS900 uses an EABI compiler to make the kernel, and it is also configured as little endian.
Binutils was switching from arm eabi-V4 to eabi-V5 at the time, and Sony's PRS-900 /lib/ld-* appears to expect the eabi-5 flag to be set or else it gets confused. when linking with binutils, people can accidentally mix eabi 4 and 5 object files which causes most of the problems, because it will default back to eabi-version 4 for the link: so, the way to make sure that eabi 4 is never produced accidentally, is to edit the default header files for the gas (Gnu ASsmebler) so it always defaults to eabi-5 even when building the cross compiler libraries unless explicitly told to do otherwise.
eg: these two files in binutil:
gas/config/te-armeabi.h <--change EABI_VER4 to --> #define EABI_DEFAULT EF_ARM_EABI_VER5
gas/config/te-armlinuxeabi.h <--do same--> #define EABI_DEFAULT EF_ARM_EABI_VER5
It would in fact be easier to use the code-sourcery tools than to build a gcc toolchain,
from scratch (I'm going to test them to see if they work on kernel modules, too) -- but as I intend to upgrade to newer tools -- I needed to know how to do this from scratch.
Below: I've included a script which is more important for the notes it contains than for it's usability; eg: It is NOT intended to be run and is not automatic -- but rather, it's to be cut and pasted into a shell and used as a cheat sheet outlining the flags which work and the files which must be manipulated to circumvent bugs. It has comments which are meant to be read, and although imperfect -- a human reading error messages should be able to figure out the rest from the shell's error messages.
I could not get libmudflap, libgomp, or libssp to work in gcc -- no matter how I tried, so they are disabled in the GCC build because all three cause insoluble compiling problems; but other than that, this script shows what is needed to build a "C" cross compiler arm-linux-gnueabi- toolchain which will compile and link Sony PRS-900 binary executables that run without segfaults, or errors.
One note:
It does NOT build kernel modules with the correct CRC codes, and it seems that the kernel that sony releases on their website (see previous post) is slightly different than the one on my sony; although the dates are identical and I used the /proc/config.gz from my actual sony. I intend to open a separate thread to solve that problem... but at least one can build user space executables with this cross compiler with no problems.
#!/bin/false
# Do not run this script directly, until you have read and edited source
# files appropriately. It's not automated. vim is a text editor...
# This script creates a toolchain in a local directory (not root).
# I made it to build a gcc toolchain on a USB memory stick,
# mounted under /media/memory1 on slackware14.
#
# Needed source files:
#
# binutils-2.19.1.tar.bz2
# gcc-core-4.2.0.tar.bz2
# linux-2.6.23_091126.tgz
# glibc-2.5.tar.bz2
# glibc-ports-2.5.tar.bz2
#
# and from the sony PRS-900, itself, you need file: /proc/config.gz
# To guarantee the kernel is compiled the same.
# First make a local script to set paths for the toolchain once it it built
# --------------
echo -e "\
#!--/bin/bash-- # but must run as . setArmEnvironment.rc \n\
# There are two kinds of binaries for cross compilation, the tool binaries\n\
# and libraries, and the target headers, libraries, etc.\n\
export CROSSROOT="\$PWD/.local"\n\
export TARGETROOT="\$PWD/.target"\n\
export PATH="\$PATH:\$CROSSROOT/bin"\n\
export LD_CONFIG_PATH="\$CROSSROOT/lib:\$LD_CONFIG_PATH"\n\
" > setArmEnvironment.rc
# ----------
# Next:
# Create the local binary and header directories for the cross compiler toolchain
# .local is the buld machines' local tools for arm development
# This is for the binaries for the machine doing the cross compiling.
mkdir .local
cd .local
ln -s . usr
ln -s . local
mkdir include
mkdir lib
mkdir bin
ln -s include sys-linux
cd ..
# Target is for the host tools, headers, etc. it is a pure ARM directory.
# Everthing here is potentially installable on the sony itself.
# And is what would appear on the SONY PRS-900 if it had a toolchain.
mkdir .target
cd .target
ln -s . usr
ln -s . local
mkdir include
mkdir lib
mkdir bin
ln -s include sys-linux
cd ..
# Now, we need to set the paths so that as we make build tools, we can
# use them from the shell we are in.
. setArmEnvironment.rc
# FIRST! ----------------------------------------------------------------------
# Problem: GCC supposedly needs some g-libc header files for proper target code
# generation...
# but they don't really exist until compiled -- so chicken-egg-rooster prob !
# Which to make first...
#
# Solve it by installing headers from uncompiled packages, using a broken gcc/binutils
# then, re-build and re-install proper header files -- re-build proper gcc... etc.
# build a broken binutils package.
tar -xf /tmp/binutils-2.19.1.tar.bz2
mkdir build.binutils.eabi
cd build.binutils.eabi
../binutils-2.19.1/configure --target=arm-eabi --prefix=$CROSSROOT
# Make with flags to prevent warning creep on newer GCC's compiling older code.
make CFLAGS="-Os -w"
make install
cd ..
# build a broken gcc core.
tar -xf /tmp/gcc-core-4.2.0.tar.bz2
mkdir build.gcc.eabi
cd build.gcc.eabi
../gcc-4.2.0/configure --target=arm-eabi --prefix=$CROSSROOT --enable-multilib --disable-libssp
make CFLAGS="-Os -w"
make install
cd ..
# Install kernel headers using first pass (broken) cross-compiler -------------
tar -xf /tmp/linux-2.6.23_091126.tgz
gzip -d config.gz
cp config linux-2.6.23_091126/.config
cd linux-2.6.23_091126
# The makefile is a little broken for use on slackware 14...
# edit so that:
# CROSS_COMPILE ?= arm-eabi-
# and make the two implicit rules explicit:
# eg: lines 425 and 1476 contain rules that need to be broken into two rules each:
# Here's a patch file to do it automatically -- paste as one quoted unit to shell:
# ******************** START ECHO DIFF COPY/PASTE
echo '192c192
< CROSS_COMPILE ?= /opt/timesys/toolchains/armv6j-linux/bin/armv6j-linux-
---
> CROSS_COMPILE ?= arm-eabi-
422c422
< config %config: scripts_basic outputmakefile FORCE
---
> %config: scripts_basic outputmakefile FORCE
424a425,428
> config: scripts_basic outputmakefile FORCE
> $(Q)mkdir -p include/linux include/config
> $(Q)$(MAKE) $(build)=scripts/kconfig $#
>
1472c1476,1479
< / %/: prepare scripts FORCE
---
> %/: prepare scripts FORCE
> $(Q)$(MAKE) KBUILD_MODULES=$(if $(CONFIG_MODULES),1) \
> $(build)=$(build-dir)
> /: prepare scripts FORCE
1475c1482
< %.ko: prepare scripts FORCE
---
> %%.ko: prepare scripts FORCE' > Makefile.diff
# ******************** END ECHO DIFF COPY/PASTE
# now apply the patch to the Makefile
patch Makefile Makefile.diff
# You might also need to edit
# vim linux scripts/unidef.c and search all instances of getline, replacing it with _getline to avoid stdio.h overloading conflict.
# This is not always necessary... but if you have the problem... that's the solution.
make ARCH=arm INSTALL_HDR_PATH=$TARGETROOT headers_install
cd ..
# DONE installing kernel header files somewhat sanitized...
------------------------ GLibc, headers install
## Create aliases for binutils so I don't need to fight with glibc...
cd .local/bin
for i in `ls arm-eabi-*`; do ln -s $i arm-linux${i##arm-eabi} ; done
cd ../..
# Now we need to build glibc-2.5 with the arm port (glibc-ports-2.5.tar.gz)
tar -xzf glibc-2.5.tar.gz
cd glibc-2.5
tar -xzf ../glibc-ports-2.5.tar.gz
mv glibc-ports-2.5 ports
# Steal configuration for arm from other processors... probably not needed.
cp sysdeps/wordsize-32/bits/wordsize.h bits # 32bits
cp sysdeps/i386/bits/endian.h bits # little endian
cd ..
# For the first pass, just make enough of libc to install the header files.
mkdir build.glibc.eabi
#bash # Enter a new shell, because path needs to be forced.
# CAUTION: You must not do this as superuser, or with write priveleges to
# the system directores, as there are bugs in the GLIBC install that
# will try to put them there even though they don't belong there in a cross
# compiler..!
(
cd build.glibc.eabi
export LD_LIBRARY_PATH=""
export PATH=$CROSSROOT/bin:$PATH
echo "libc_cv_forced_unwind=yes" > config.cache
echo "libc_cv_c_cleanup=yes" >> config.cache
echo "libc_cv_arm_tls=yes" >> config.cache # For posix threads, but maybe not.
../glibc-2.5/configure --with-binutils=$CROSSROOT/arm-eabi/bin --build=i686-linux --host=arm-linux --prefix=/usr --enable-kernel=2.6.23 --with-headers=$TARGETROOT/include --enable-add-ons --disable-profile --config-cache --disable-sanity-checks --with-tls --with-__thread
# Caution, this install will attempt to install to both --prefix=/usr AND install_root.
# Because any directories where actual compilation is unfinished will
# not make install_root= correctly, but default back to prefix.
# Therefore,
# Do not allow writes to local system directories, by not installing as root!
# ... AND ...
# You must run make install_headers twice so everything does end up in $TARGETROOT
make -k install-headers install_root=$TARGETROOT
make -k install-headers install_root=$TARGETROOT
# Manually install two files, ... or GCC won't build. Three if you want it all.
# Glibc has a *REAAAALY* crappy installer script ...
cp bits/stdio_lim.h $TARGETROOT/include/bits
touch $TARGETROOT/include/gnu/stubs.h
cp nptl/sysdeps/pthread/pthread.h $TARGETROOT/include
# Long-double is messed up ... I ran into this. :)
( cd $TARGETROOT/include/bits
sed '/ifndef.*NO_LONG_DOUBLE/,/#endif/d' < mathdef.h > mathdef.h.new
mv mathdef.h.new mathdef.h
)
# LIB-C woes.
# We don't have the core files made yet, but generally, linking for arm needs:
# ... elf-init.o crt1.o crti.o crtbegin.o [-L] [user.o's] [gcc lb] [C lb] crtend.o crtn.o
# Unfortunately, GCC uses these during configuration tests and to make libgcc.o
# so we need them NOW, even if they are a little wrong, to make gcc.
# What they are:
# crt1.o -- from glibc's Start.S --calls libc's __libc_csu_init, __libc_csu_fini
# crti.o -- gcc's default version is no good; but libc's is. defines prolog _init
# crtn.o -- ... ; defines function epilog _fini
# crtbegin.o and crtend.o are supplied by gcc, for constructors/destructors.
# elf-init.o -- I don't remember what it is, but it has fn's that gcc needs.
#
# so, we need to build the crt files -- and only them... as the rest can't be
# done yet. So we 'make' the crt's subdirectory.
make CFLAGS="-Os -w" ARCH=arm cross-compiling=yes csub/subdir_lib
# Manually install them in a place where the linker will find them...
cp csu/crt*.o $TARGETROOT/lib
# elf-init.o is only needed during the build of GCC. It should be removed
# after the new gcc is made, or if it causes errors when gcc is made for
# redundant symbols.
cp csu/elf-init.o $TARGETROOT/lib
) # finished with bash subtask. restore environment to normal.
# The .local tools we built previously are now basically useless
# I'll just move them, although you might want to remove them...
mv .local .local.eabi
# ****************************************************************************
# ----------------------------------------------------------------------------
# Build actual tools
# We must build gcc.linux.gnueabi in order for glibc programs to compile right...
# ----------------------------------------------------------------------------
# Create a clean .local directory
mkdir .local
cd .local
ln -s . usr
ln -s . local
mkdir include
mkdir lib
mkdir bin
ln -s include sys-linux
cd ..
# Rebuild the toolchain with the basic headers we just installed.
# First do bintools
# Be sure to Change the DEFAULT_EABI to version 5 before compiling gas.
mkdir build.binutils2.19.1.linux.gnueabi
cd build.binutils2.19.1.linux.gnueabi
../binutils-2.19.1/configure --target=arm-linux-gnueabi --prefix=$CROSSROOT --with-sysroot=$TARGETROOT
# Make with flags to prevent warning creep on newer GCC's compiling older code.
make CFLAGS="-O2 -w"
make install
cd ..
# !!!! Now for GCC.
mkdir build.gcc.linux.gnueabi
cd build.gcc.linux.gnueabi
../gcc-4.2.0/configure --target=arm-linux-gnueabi --prefix=$CROSSROOT --enable-multilib --disable-libssp --enable-shared --disable-libgomp --disable-werror --disable-libmudflap --with-sysroot=$TARGETROOT
make -j2
make install
cd ..
# Create the specs file for editing GCC's configuration if we want to...
arm-linux-gnueabi-gcc -dumpspecs > .local/arm-linux-gnueabi/lib/specs
# Edit the specs file, and make *startfile command read:
#
# %{!shared: %{pg|p|profile:gcrt1.o%s;pie:Scrt1.o%s;:crt1.o%s}} elf-init.o%s crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}
vim .local/arm-linux-gnueabi/lib/specs
# This edit will cause GCC to link the elf-init.o crti.o crt1.o crtn.o files (happily) from $TARGETROOT/lib where a user can easily install them.
# There are a few abused/problem header files... so fix them!
vim glibc-2.5/posix/regex_internal.h # line 393, changed static int to
#static reg_errcode_t build_wcs_upper_buffer (re_string_t *pstr) internal_function;
vim .target/include/asm/unistd.h # find line 410, comment it out...
# And do a softlink to fake out an abused header...
ln -s hwcap.h .target/include/asm/procinfo.h
# Now we can finally build a true libc...
mkdir build.glibc.gnueabi
( # Enter a new shell, because path needs to be forced.
rm -rf build.glibc.gnueabi/*
cd build.glibc.gnueabi
# GLibc errors out if it thinks LD_LIBRARY_PATH is set wrong, even if it's not.
# So disable it temporarily.
export LD_LIBRARY_PATH=""
echo "libc_cv_forced_unwind=yes" > config.cache # No crt1.o exists, yet...force
echo "libc_cv_ctors_header=yes" >> config.cache # constructor headers, yes?
echo "libc_cv_c_cleanup=yes" >> config.cache
echo "cross_compiling=yes" >> config.cache
echo "install_root=$TARGETROOT" > configparms # Where to really install target
export CFLAGS="-fgnu89-inline -D__OPTIMIZE__ -O2 "
../glibc-2.5/configure --build=i686 --host=arm-linux-gnueabi --prefix=/ --enable-kernel=2.6.23 --with-headers=$TARGETROOT/include --enable-add-ons --disable-profile --with-tls --with-__thread --cache-file=config.cache
make
make install-headers install_root=$TARGETROOT
make localedata/install-locales install_root=$TARGETROOT
) # End of subshell

extracting and creating ipk files

ipk packages are the intallation packages used by opkg.
I'm trying to extract the contents of one of them and also create my own ipk.
I've read that I should be able to untar them but that is not true.
I've tried:
tar -zxvf mypack.ipk
and I get:
zip: stdin: not in gzip format
I've also tried:
tar -xvf mypack.ipk
and I get:
tar: This does not look like a tar archive
I've found that most of the information on the internet regarding ipk's are inaccurate.
My ipk was generated by bitbake. I'm having a hard time with bitbake and want to avoid using it.
Any ideas on how to extract and how to create ipk files? A simple template with a single package would be useful to have.
I figured it out.
You can extract the main package with the ar x command, then extract the control.tar.gz with the tar -zxf command.
I have tested "ar x package-name.ipk" command but it didn't help
I found bellow command which worked perfectly
tar zxpvf package-name.ipk
This extracts three files:
debian-binary
data.tar.gz
control.tar.gz
use the same command to open data.tar.gz and control.tar.gz files
for more information refer to
https://cognito.me.uk/computers/manual-extractioninstallation-of-ipk-packages-on-gargoyleopenwrt/
You need to create a control file, and then do some archiving using tar and ar. In my case, I was distributing just python scripts, so there was no architecture dependency. You should check the control and Makefile into version control, and delete all the other intermediate files.
Here are the contents of control
Package: my-thing-python
Version: 1.0
Description: python scripts for MyCompany
Section: extras
Priority: optional
Maintainer: John
License: CLOSED
Architecture: all
OE: my-thing-python
Homepage: unknown
Depends: python python-distutils python-pyserial python-curses python-mmap python-ctypes
Source: N/A
Here is my Makefile which sits in the same directory as all my python scripts.
all: my-thing-python.ipk
my-thing-python.ipk:
rm -rf ipk
mkdir -p ipk/opt/my-thing-python
cp *.py ipk/opt/my-thing-python
tar czvf control.tar.gz control
cd ipk; tar czvf ../data.tar.gz .; cd ..
echo 2.0 > debian-binary
ar r my-thing-python.ipk control.tar.gz data.tar.gz debian-binary
clean: FORCE
rm -rf ipk
rm -f control.tar.gz
rm -f data.tar.gz
rm -f my-thing-python.ipk
FORCE:
Extracting with these commands:
Extract the file by running the command:
ar -xv <.ipk file>
Extract the control.tar.gz file by running the command:
tar -zxvf control.tar.gz
data.tar.gz : untar by running the command:
tar –zxvf data.tar.gz
If you want a list of files in an ipk, you can do something like:
#!/bin/sh
for f
do
tar -x -z -f $f ./data.tar.gz -O | tar tvzf -
done
-O is extract to standard output.
ipk files used to be AR (like DPKG), but are now tgz.
I feel that some dpkg utility ought to cope with ipkg files, but I haven't found the right one.

How to replace MacPort's libiconv with Mac's default 64-bit version?

MacPorts installed "libiconv #1.14_0+universal" as a dependency on my system. This happens to be a 32-bit flavor and it started causing issue when I tried to compile a voice recognition software called Simon Listens.
While googling I found out that that Mac actually ships with a 64-bit flavor of libiconv by default and I was able to locate the said files on my system:
$ find /usr/lib -name libiconv*
/usr/lib/libiconv.2.4.0.dylib
/usr/lib/libiconv.2.dylib
/usr/lib/libiconv.dylib
In order to use the system library, the quickest way I could think of was to uninstall MacPort's version of libiconv so that the system's library would end up getting selected as a fallback as it has to present (my guess) somewhere downstairs on the PATH already.
But that failed due to dependecies:
$ sudo port uninstall libiconv #1.14_0+universal
Unable to uninstall libiconv #1.14_0+universal, the following ports depend on it:
...
So now my question is how can I tell MacPort to replace its dependency graph to point to and use the library already on my system?
Another approach to avoid MacPorts libiconv issues would be to build simon against a fresh MacPorts system plus the necessary packages such as cyrus-sasl2, zlib, portaudio and kdesdk4 in a custom location, e. g. /opt/macports-simon.
The following code worked for me on my machine running Mac OS X 10.6.8:
# compile simon on Mac OS X 10.6.8 using MacPorts for the installation of zlib, portaudio and kdesdk4
# http://www.simon-listens.org
# http://sourceforge.net/projects/speech2text/
# get a root shell
sudo -H -i
# prevent idle sleep
pmset -a force sleep 0 displaysleep 0 disksleep 0
mv -i /opt/local /opt/local-off
mv -i /usr/local /usr/local-off
cd /tmp
mkdir buildsimon || exit 1
cd buildsimon || exit 1
# create custom /opt/macports-simon to install zlib, portaudio and kdesdk4
# cf. http://guide.macports.org/#installing.macports.source.multiple
MP_PREFIX='/opt/macports-simon'
unset PATH
export PATH='/bin:/sbin:/usr/bin:/usr/sbin'
curl -L -O https://distfiles.macports.org/MacPorts/MacPorts-2.0.4.tar.bz2
tar -xjf MacPorts-2.0.4.tar.bz2
cd MacPorts-2.0.4 || exit 1
./configure --prefix="${MP_PREFIX}" --with-applications-dir="${MP_PREFIX}/Applications"
make
make install
cd /tmp/buildsimon
unset PATH
export PATH="${MP_PREFIX}/bin:/bin:/sbin:/usr/bin:/usr/sbin"
# get the Portfiles and update the system
port -v selfupdate
# install cyrus-sasl2
port -f uninstall cyrus-sasl2
port clean --all cyrus-sasl2
port extract cyrus-sasl2
cd "$(port dir cyrus-sasl2)"/work/cyrus-sasl-2.1.23
printf '%s\n' H '/\(darwin\[15\]\)/s//\1./g' wq | sudo ed -s config/ltconfig
printf '%s\n' H '/\(darwin\[15\]\)/s//\1./g' wq | sudo ed -s saslauthd/config/ltconfig
cd /tmp/buildsimon
port -f -s install cyrus-sasl2
otool -L /opt/macports-simon/lib/libsasl2.dylib
port -f install zlib
port -f install portaudio
port -f install kdesdk4
port installed zlib portaudio kdesdk4 cyrus-sasl2
# enable dbus with launchd
# http://www.freedesktop.org/wiki/Software/dbus
# open -e dbus-1.5.8/README.launchd
launchctl load -w /Library/LaunchDaemons/org.freedesktop.dbus-system.plist
launchctl load -w /Library/LaunchAgents/org.freedesktop.dbus-session.plist
sudo -u _mysql mysql_install_db5
sudo port load mysql5-server
# todo: how to configure simon to use /opt/macports-simon directly?
ln -isv "${MP_PREFIX}" /usr/local
cd /tmp/buildsimon
# http://sourceforge.net/projects/speech2text/
curl -L -O http://netcologne.dl.sourceforge.net/project/speech2text/simon/0.3.0/simon-0.3.0.tar.bz2
tar -xjf simon-0.3.0.tar.bz2
cd simon-0.3.0 || exit 1
# Note that /usr/local got symlinked to "${MP_PREFIX}" above!
unset PATH
export PATH='/usr/local/bin:/bin:/sbin:/usr/bin:/usr/sbin'
# the following commands are taken from simon-0.3.0/build.sh
mkdir build 2> /dev/null
cd build || exit 1
cmake -DCMAKE_INSTALL_PREFIX=`kde4-config --prefix` ..
# append ${MP_PREFIX}/lib/libiconv.dylib to gcc command in link.txt file
printf '%s\n' H '/\/usr\/bin\/gcc/s|\(.*\)|\1 '"${MP_PREFIX}"'/lib/libiconv.dylib|' wq |
ed -s julius/julius/CMakeFiles/juliusexe.dir/link.txt
# replace gcc option ' -bundle ' with ' -dynamiclib '
egrep -Ilsr -Z -e ' -bundle ' . |
xargs -0 -n 1 /bin/sh -c 'printf "%s\n" H "g/ -bundle /s// -dynamiclib /g" wq | /bin/ed -s "${1}"' argv0
make
touch ./julius/gramtools/mkdfa/mkfa-1.44-flex/*
make
make install
# ldconfig # not needed on Mac OS X
kbuildsycoca4
echo -e "**** Build completed ****\n\nThe executable file \"simon\" is now ready and has been installed.\n\nIssue \"simon\" to start it."
unset PATH
export PATH="${MP_PREFIX}/bin:/bin:/sbin:/usr/bin:/usr/sbin"
otool -L "${MP_PREFIX}/bin/simon"
simon
mv -i /opt/local-off /opt/local
mv -i /usr/local-off /usr/local

Resources