[David Good]

I’ll stick to the tagged releases then.

Thanks!

[David Good]

Ok. The base-image has now finished building with no issues. Thanks!

[David Good]

Thanks! I was trying very hard to get bitbake to do this exact thing 🙂 They probably didn’t bother knowing that it was so easy from the command line.

About the larger issue of getting a clean compile… I ran into more errors (checksum of patch-2.6.35.14.bz2 could not be verified). After trying to fix that for awhile, I decided to do a fresh git clone and start over.

This brings me to a new question: How do you update the various layers under corecdp? git pull does some things, but in my case, bitbake corecdp-base-image was trying to bake linux-2.6.35, but when doing it from a fresh clone, linux-2.6.39 was built. In regular Angstrom, they have a script oebb.sh which will look for sources/layers.txt and then update everything it finds in that file.

Thanks again!

[David Good]

Hi Bryan,

I’m using Debian Squeeze (6.0).

This is not really a Openembedded issue per se, but one with guile 1.8.7. I found this on the Fedora mailing list, and similar things on Suse.

http://www.redhat.com/archives/rhl-list/2009-November/msg01533.html

It is a CoreCDP issue in that guile 1.8.7 will not always compile on a fresh system.

I’d be interested to know if you run into any issues on a fresh Debian 6.0 install following the instructions on the website vs one which has built guile before.

–David

[David Good]

I managed to get it to finish compiling by copying a symlink to a temporary shared lib by doing this:

cp /home/engin/dev/multitech/corecdp-2.2.2/build/tmp/work/i686-linux/guile-native-1.8.7-r1/guile-1.8.7/libguile/.libs/libguile.so.17 home/engin/dev/multitech/corecdp-2.2.2/build/tmp/sysroots/i686-linux/usr/lib/

The problem is with this line:

cat alist.doc arbiters.doc async.doc backtrace.doc boolean.doc chars.doc continuations.doc debug.doc deprecation.doc deprecated.doc discouraged.doc dynl.doc dynwind.doc environments.doc eq.doc error.doc eval.doc evalext.doc extensions.doc feature.doc fluids.doc fports.doc futures.doc gc.doc goops.doc gsubr.doc gc-mark.doc gc-segment.doc gc-malloc.doc gc-card.doc guardians.doc hash.doc hashtab.doc hooks.doc i18n.doc init.doc ioext.doc keywords.doc lang.doc list.doc load.doc macros.doc mallocs.doc modules.doc numbers.doc objects.doc objprop.doc options.doc pairs.doc ports.doc print.doc procprop.doc procs.doc properties.doc random.doc rdelim.doc read.doc root.doc rw.doc scmsigs.doc script.doc simpos.doc smob.doc sort.doc srcprop.doc stackchk.doc stacks.doc stime.doc strings.doc srfi-4.doc srfi-13.doc srfi-14.doc strorder.doc strports.doc struct.doc symbols.doc threads.doc throw.doc values.doc variable.doc vectors.doc version.doc vports.doc weaks.doc ramap.doc unif.doc dynl.doc filesys.doc posix.doc net_db.doc socket.doc regex-posix.doc | GUILE="/home/engin/dev/multitech/corecdp-2.2.2/build/tmp/work/i686-linux/guile-native-1.8.7-r1/guile-1.8.7/pre-inst-guile-env" ../scripts/snarf-check-and-output-texi          > guile-procedures.texi || { rm guile-procedures.texi; false; }

Evoked from:

corecdp-2.2.2/build/tmp/work/i686-linux/guile-native-1.8.7-r1/guile-1.8.7/libguile/Makefile

Doing a ldd on the complaining program revealed the problem:

ldd /home/engin/dev/multitech/corecdp-2.2.2/build/tmp/work/i686-linux/guile-native-1.8.7-r1/guile-1.8.7/libguile/.libs/lt-guile

linux-gate.so.1 =>  (0xb7770000)

libguile.so.17 => not found

libgmp.so.10 => /home/engin/dev/multitech/corecdp-2.2.2/build/tmp/sysroots/i686-linux/usr/lib/libgmp.so.10 (0xb76ed000)

libcrypt.so.1 => /lib/i386-linux-gnu/i686/cmov/libcrypt.so.1 (0xb76bb000)

libm.so.6 => /lib/i386-linux-gnu/i686/cmov/libm.so.6 (0xb7695000)

libltdl.so.7 => /home/engin/dev/multitech/corecdp-2.2.2/build/tmp/sysroots/i686-linux/usr/lib/libltdl.so.7 (0xb768b000)

libdl.so.2 => /lib/i386-linux-gnu/i686/cmov/libdl.so.2 (0xb7687000)

libpthread.so.0 => /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 (0xb766d000)

libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb7510000)

/lib/ld-linux.so.2 (0xb7771000)

lt-guile couldn’t find libguile.so.17 when it needed it before it was installed in the tree. I was afraid to start messing with ldconfig for fear of doing something really wrong, so I symlinked the library as above.

I have no idea how to fix it or patch it permanently, but hopefully this helps someone else get over this situation.

[David Good]

Hello,

Is there a way to redirect data coming into the serial through some utility to a remote port? I looked into nc (netcat), but the following script doesn’t seem to send the information through the socket.

nc x.x.x.x 12345 < /dev/ttyS2

I can cat ttyS2 and see my data, and I can telnet over to the remote server and manually input data (tested using keystrokes as input), but I can’t seem to get something that ties the two together. I was hoping that I wouldn’t need to write a C network socket program just send data along.

Any ideas?

Thanks!

[Author]

Posts