Solved

gphoto2 cross compile for arm

Posted on 2010-09-11
26
1,721 Views
Last Modified: 2013-11-13
Hi,
I have cross-compiled libgphoto2 and gphoto2 to run on an arm processor. When I run:
$ strace gphoto2 -about
I get the following with a segmentation fault. Can anyone see a solution to this?
Thanks
open("/mnt/flash/lib/libgphoto2/2.4.10.1", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3

fstat64(3, {st_mode=S_IFDIR|0750, st_size=2048, ...}) = 0

fcntl64(3, F_GETFD)                     = 0x1 (flags FD_CLOEXEC)

getdents(3, /* 4 entries */, 4096)      = 72

getdents(3, /* 0 entries */, 4096)      = 0

close(3)                                = 0

access("/lib/dlopen.a", R_OK)           = 0

gettimeofday({1284090621, 931380}, NULL) = 0

open("/mnt/flash/lib/libgphoto2/2.4.10.1/ptp2.la", O_RDONLY) = 3

fstat64(3, {st_mode=S_IFREG|0640, st_size=901, ...}) = 0

mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40020000

read(3, "# ptp2.la - a libtool library fi"..., 4096) = 901

read(3, "", 4096)                       = 0

close(3)                                = 0

munmap(0x40020000, 4096)                = 0

--- SIGSEGV (Segmentation fault) @ 0 (0) ---

+++ killed by SIGSEGV +++

Segmentation fault

Open in new window

0
Comment
Question by:FarcoTech
  • 10
  • 8
  • 8
26 Comments
 
LVL 34

Expert Comment

by:Duncan Roe
ID: 33655303
The segfault is not necessarily related to the preceding munmap or in fact to any system call. gdb would be a better tool than strace here - compile everything -g at least and -g3 -ggdb for best results. Then gdb gphoto2 -about will pinpoint the problem.
It is possible that compiling -g will make the problem go away - up to you what to do if that happens.
Also, reducing optimization level can sometimes get rid of problems like this - makes gdb easier to follow also.
0
 

Author Comment

by:FarcoTech
ID: 33655589
Thanks Duncan,
The gphoto2 is being executed on the embedded platform with arm processor. Currently I do not have gdb for the board and source codes are also on the host not the board. Life is a lot easier on a desktop environment! A few years ago I had done remote debuging using gdbserver on the board and gdb on the desktop with source but this is going to take a while to setup and I do not have the time to do it.

Any other suggestion?
Thanks
0
 
LVL 34

Expert Comment

by:Duncan Roe
ID: 33656171
Turn off all optimizing in the build and see if that fixes it. If not, turn on -g and see if that fixes it (it did fix the last release of fvwm95, which I am still using).
How do you get software onto the embedded platform? I'm just wondering if there is any way to get a command prompt on the board. Even without the sources, gdb would give you the source file name and line number.
0
 

Author Comment

by:FarcoTech
ID: 33656518
Embedded system runs linux and I ftp code into it and can telnet to it to get a command shell.
0
 
LVL 34

Expert Comment

by:Duncan Roe
ID: 33656629
Build gdb for the board then telnet in and gdb gphoto2 -about. Much simpler than using gdbserver - and you could set up nfs to make the sources visible if you like.
0
 
LVL 12

Expert Comment

by:HappyCactus
ID: 33691995
Do you have simply copied your binary into the target?
If so, you should use a complete installation instead.
to do so, to an installation into a "fake" target directory, than targz the tree and un-targz-it into the target.

make DESTDIR="/tmp/target-gphoto" install
cd /tmp/target-gphoto
tar zcvf gphoto.tgz ./
scp gphoto.tgz root@192.168.1.1:/tmp/

and into the target:

cd /
tar zxvf /tmp/gphoto.tgz
ldconfig

Which kind of build environment are you using?
The best way to install a program like gphoto is to build it from the build environment. If you do not want to reflash the firmware, you can do a nfs boot and work onto that nfs directory...

Hope that helps.
0
 
LVL 34

Expert Comment

by:Duncan Roe
ID: 33697027
I meant gdb gphoto2; run -about
0
 

Author Comment

by:FarcoTech
ID: 33707292
Sorry I have not been able to follow up this earlier(so many things are going on at the moment). Regarding building and installation in principal I have done what you have suggested (I have used ./configure --prefix=/tmp/target) and then ftped contents of the /tmp/target to the target board using a script.

One thing that could be helpful in figuring out the problem is that the strace output shows:
access("/lib/dlopen.a", R_OK)           = 0

the file /lib/dlopen.a did not exist in the target and I had to find in in my build PC and manually ftp it to the target (of cource ensuring that it is built for the target and not the PC). But it may not be an issue since it appears it has done what it was supposed to do based on the output of the strace??

The other clue is the following lines in the strace output:
munmap(0x40021000, 4096)                = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

The SIGSEGV is error when "Attempted write into a region mapped as read-only." Problem is that the output does not give a clue of what function or process is attempting to write into the read-only region. I am not sure if gdb can give any clue since all function calls are given by strace anyway.

Can you suggest/guess what could be causing the SIGSEV?


0
 
LVL 12

Expert Comment

by:HappyCactus
ID: 33707315
First, using --prefix in configure change the compilation and installation path from /usr to /tmp. This means that your program not only will be installed in /tmp/bin and libraries in /tmp/lib, but also all internal path will be /tmp. This is wrong, because this implies that you will install your program in /tmp in the target. But maybe you are copying your binary in /usr/bin or /usr/local/bin. This can make some problem (some program search his plugins or dynamic libraries into $(prefix)/share).
The correct procedure is to compile with --prefix=/destination_target and install by only change the DESTDIR variable with make install. This only copy the installation branch into DESTDIR.
Second. If dlopen does not exist, this means that you haven't installed it into the target device. This can be due to a wrong cross-compilation installation, or maybe not all necessary libraries are installed into the target.
0
 
LVL 34

Assisted Solution

by:Duncan Roe
Duncan Roe earned 250 total points
ID: 33707495
gdb will almost certainly be better. Especially if you can compile libgphoto2 and gphoto2 with -g, when gdb will pinpoint the failing line number (even if it can't access source). You may have found a real (lib)gphoto2 bug which is benign on the x86 platform - maybe code tries to access memory that  is no longer shared and somehow gets away with it on x86 for instance
0
 

Author Comment

by:FarcoTech
ID: 33707617
I understand the issue that you have mentioned about the use of --prefix and and have made sure that all needed shared libraries by the program are found and loaded and shown by the output of strace. So I do not think there is any issue with the path to libraries in this instance.

Regarding dlopen, I have manually copied the dlopen.a into the target, since I could not find it on the target. I thought it would be part of libtool but obviously not (I built and ftped across libtool library and binaries but that did not include dlopen). I am not sure what installation of of dlopen involves other than copying the dlopen.a that I have done? Are there other components/libraries that need to be installed with dlopen other than the libtool which I have done?
0
 
LVL 12

Expert Comment

by:HappyCactus
ID: 33707922
gphoto2 seems to be well supported in the ARM platform, so I would exclude the "arm bug".
Strange errors and malfunction in the embedded world usually means bad behaving cross-compiler, bad installations and so on. But you never know, I would check if there are some unofficial patch set for gphoto2 for arm - from a quick check with google, I doesn't seems.
So take a cross compilation environment like openembedded or buildroot and check if there is some gphoto2 patches inside, or start from that version.
But I would check your installation, maybe you are mixing host and target libraries.
Second, it seems to me strange that it access dlopen.a file - it's a static library.
What kind of cross-compilation enviroment are you using?
Are the other target program working correctly?
 
0
 
LVL 34

Expert Comment

by:Duncan Roe
ID: 33709654
The dlopen function is part of glibc. It's an entry point of /lib/libdl.so.2. I had never heard of dlopen.a before and certainly don't have one in /lib (there is one in the build directory of graphviz-2.26.3 now I have looked).
What is the effect of temporarily removing or renaming /lib/dlopen.a from your x86 system?
/mnt/flash/lib/libgphoto2/2.4.10.1/ptp2.la is an ld script. Please post them (i.e. from both systems)
Also notice that /lib/dlopen.a is not opened before the segfault, so its contents are irrelevant.
By the way, SIGSEGV is not necessarily "Attempted write into a region mapped as read-only." - it can also be any attempt to access a page of memory which is not mapped.
0
How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

 
LVL 12

Expert Comment

by:HappyCactus
ID: 33710670
That's way I supposed a bad installation of gphoto or a broken toolchain.
In my experience, a strange crash of an application in a cross compiled environment 65% of the time is caused by a bad cross compiler (strange binutils + gcc + headers + glibc versions, kernel version and kernel header version incompatibility, strange options in glibc compilation, bad installation of the toolchain...), 25% a bad compilation or installation of the application, 5% a bug in software that only triggers with specific toolchain or kernel options and 5% a bug in software.
And this kind of problem seems related with the first or second case, in my opinion.
So I would start from a cross compiler environment that includes scripts for gphoto2 (like buildroot or openembedded), and if it does not work without modification, investigate with gdb or strace...

0
 

Author Comment

by:FarcoTech
ID: 33713030
Unfortunately openEmbeded build environment does not work for me so I am not able to use "bitbake gphoto2" at the moment. Following is the contents of libgphoto.bb bitbake recipe for openEmbedded:

#################################
DESCRIPTION = "libgphoto2 allows you to access digital cameras"

SECTION = "libs"
LICENSE = "GPL"
DEPENDS = "libtool jpeg virtual/libusb0 libexif"

PR = "r0"

SRC_URI = "${SOURCEFORGE_MIRROR}/gphoto/libgphoto2-${PV}.tar.bz2"

inherit autotools pkgconfig lib_package

OE_LT_RPATH_ALLOW=":${libdir}:"
OE_LT_RPATH_ALLOW[export]="1"

EXTRA_OECONF = " --with-drivers=all"

PACKAGES =+ "libgphotoport libgphoto2-camlibs"
FILES_libgphoto2-camlibs = "${libdir}/libgphoto2*/*/*.so*"
RDEPENDS_${PN} = "libgphoto2-camlibs"

FILES_libgphotoport = "${libdir}/libgphoto2_port.so.*"

FILES_${PN} += "${libdir}/udev/*"
FILES_${PN}-dbg += "${libdir}/*/*/.debug"

SRC_URI[md5sum] = "a60154772635b693ff08b4f34dea7f61"
SRC_URI[sha256sum] = "0dc26b7a8568dee7634bebbaf9f7d3e3ab9460424e6297a595e41c4fddbbdb79"
##################################################

I am using gcc-arm-linux toolchain version 4.3.2 to build. I have used it for other programs such as strace and openssl and it works fine.

As you have suggested it is most likely to do with some mixup in cross compilation or incorrect library etc, I wish I knew what!

I am attaching the build script that I have made up to build gphoto2 and all required libraries. I have also copied /mnt/flash/lib/libgphoto2/2.4.10.1/ptp2.la script below:
##################################################
# ptp2.la - a libtool library file
# Generated by ltmain.sh - GNU libtool 1.5.26 (1.1220.2.492 2008/01/30 06:40:56)
#
# Please DO NOT delete this file!
# It is necessary for linking the library.

# The name that we can dlopen(3).
dlname='ptp2.so'

# Names of this library.
library_names='ptp2.so ptp2.so ptp2.so'

# The name of the static archive.
old_library=''

# Libraries that this one depends upon.
dependency_libs=' -L/mnt/flash/lib /mnt/flash/lib/libgphoto2.la /mnt/flash/lib/libgphoto2_port.la -lpthread /mnt/flash/lib/libltdl.la -ldl -lm'

# Version information for ptp2.
current=0
age=0
revision=0

# Is this an already installed library?
installed=yes

# Should we warn about portability when linking against -modules?
shouldnotlink=yes

# Files to dlopen/dlpreopen
dlopen=''
dlpreopen=''

# Directory that this library needs to be installed in:
libdir='/mnt/flash/lib/libgphoto2/2.4.10.1'
###########################################################

I have checked and ensured all the dependency_libs above are present in the target. I am still puzzled why a static library dlopen.a is being accessed?? (that's probably a hint of what the underlaying problem is)

Please let me know if you spot an obvious/potential error in any of the above. I will try the gdb suggestion as soon as I can get some time.
Thanks


gphotoBuild.sh
0
 
LVL 12

Expert Comment

by:HappyCactus
ID: 33714037
You should NOT copy the LD scripts, since they requires developer tools that aren't usually installed in the target environment.
The first thing I would check is to only build the command lines tools. Now you are configuring the software by letting the script to guess the dependencies, this could potentially expose to misconfiguration, since the script is usually not able to understand what are the host libraries (x86 target) and what to target libraries (arm). So maybe you are compiling the software with some mixed platform configuration. So, first disable all the software you are not required.
I also remove any configuration option you do not strictly need, I would start with only one tool (if it is possible) and check if it works. Use --without-xxx and --disable-xxx configure option to remove all the libraries. see if it works.
After that you can start configuring only what you requires, and check if it works.
0
 

Author Comment

by:FarcoTech
ID: 33714319
I am not quite sure what you mean to "only build command line tools" since gphoto is indeed a command line tool. Also everything that I have included in the build script (gphotoBuild.sh attachment in previous post) is really needed and is a minimal build for a working gphoto.

Also I am not quite sure what you mean by "configuring the software by letting the script to guess the dependencies". If you are referring to the gphotoVBuild.sh script, all the libraries are needed for the libgphoto2 which is needed by gphoto2. I may have misunderstood what you mean though!
0
 
LVL 12

Expert Comment

by:HappyCactus
ID: 33714341
I meant to say that when you run the configure script, it analyze the current building environment to understand what libraries are available and configure the output tools and the configuration options. You can force these options with the --enable/disable-xxx and --with/without-xxx configuration options.
Sometime the configure script misunderstand the options available: for example when it found an header file in the host include dir instead of in the target include directory. This way a target/host mix library linking is highly probable.
What I say is: do not let the configure script guess what libraries are available, disable it with the --without and --disable flags.
I do not mean to say that this is the problem - maybe your script is ok - but in my experience sometime this problem happens.
0
 

Author Comment

by:FarcoTech
ID: 33733572
I got source for gdb and compiled for arm and ran on target for gphoto2 and following is the trace I got after the  SIGSEGV segmentation fault. Looks like libltdl is involved and the problem is in the libgphoto2. You may recall that I had problem in the first place with compiling libgphoto2 for arm and that had something to do with libltdl, but that was sorted!? Anyway I will keep looking to see what I can sort out but in the meantime please let me know if you have a suggestion to solve this problem. Thanks

(gdb) backtrace
#0  0x0007878c in ?? ()
#1  0x4015383c in tryall_dlopen (phandle=0xbea42e7c,
    filename=0x794a8 "dlopen.a", padvise=0x0, vtable=0x0) at libltdl/ltdl.c:430
#2  0x40155e34 in try_dlopen (phandle=0xbea42ed0,
    filename=0x4015a718 "dlopen.a", ext=0x794be ".a", advise=0x0)
    at libltdl/ltdl.c:1430
#3  0x40156774 in lt_dlopenadvise (filename=0x4015a718 "dlopen.a", advise=0x0)
    at libltdl/ltdl.c:1607
#4  0x401565e8 in lt_dlopen (filename=0x4015a718 "dlopen.a")
    at libltdl/ltdl.c:1563
#5  0x4015232c in lt_dlpreload_open (originator=0x4015a1f0 "libltdl",
    func=0x40152ff8 <loader_init_callback>) at libltdl/loaders/preopen.c:353
#6  0x401532cc in lt_dlinit () at libltdl/ltdl.c:237
#7  0x40058b04 in gp_abilities_list_load_dir (list=0x79478,
    dir=0x4009a708 "/mnt/flash/lib/libgphoto2/2.4.10.1", context=0x78108)
    at gphoto2-abilities-list.c:192
#8  0x40059310 in gp_abilities_list_load (list=0x79478, context=0x78108)
    at gphoto2-abilities-list.c:320
#9  0x00014ac0 in gp_params_abilities_list (p=0x75568) at gp-params.c:311
#10 0x0001b424 in main (argc=2, argv=0xbea4de34, envp=0xbea4de40)
    at main.c:2038
0
 
LVL 34

Expert Comment

by:Duncan Roe
ID: 33734308
What is the output from file /lib/dlopen.a ? I would expect  current ar archive
Assuming that's what you see, it is a mistake to try to open it with dlopen() which opens shared ELF objects as you yourself mentioned earlier.
Did you try temporarily removing it on the x86 system?
I wonder if something went wrong at the configure stage of building libgphoto2, such that it believes it needs this file as a dynamic library. I think that's the error you need to find.
Now you  have gdb (well done for that), you could make some nfs mounts so it can see the source (use gdb's dir command to tell it where to look). Then by breakpointing and stepping, you might find out where it reads the name dlopen.a - or that might be heavy going.
Something else to try - remove /lib/dlopen.a on the build system (assuming that doesn't annoy libgphoto2, but it shouldn't). Do a fresh untar of libgphoto2 source, configure for arm and make. My thinking here is that the presence of /lib/dlopen.a may have confused configure. If you keep a record of the build, you can grep it for /lib/dlopen.a, or maybe even compare logs from configuring when it was present and when it was not.

(./configure configure args for arm && make) 2>&1 | tee hee will log everything to hee
0
 
LVL 12

Assisted Solution

by:HappyCactus
HappyCactus earned 250 total points
ID: 33734447
Looking at the gphoto2 archive it seems that some old version of gphoto2 haves a similar bug[1].
2.4.10 is the up-to-date version of gphoto, but if it's a bug, it is possible that it's a new bug or that it's has been already solved in the latest development branch.
My suggestion is to try an older version, and then try the latest development version.
Some bug reports[2] says that also libtld can make similar bugs happens, so check carefully your tld (libtool) cross-compilation. Perform a libtool stress test to see if it's all working correctly.[3]

[1] https://bugs.launchpad.net/ubuntu/+source/libgphoto2/+bug/352271
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=539147
[3] http://www.gnu.org/software/libtool/manual/html_node/Libtool-test-suite.html#Libtool-test-suite

0
 

Author Comment

by:FarcoTech
ID: 33739165
Thanks guys. Good suggestions. I will work through them and let you know.
0
 
LVL 34

Expert Comment

by:Duncan Roe
ID: 33739221
I thought after I last posted - remove /lib/dlopen.and then rebuild libtool before trying to rebuild gphoto2 (for arm in both cases)
0
 

Author Comment

by:FarcoTech
ID: 33743832
file dlopen.a indeed outputs  current ar archive. Removing dlopen.a and rebuilding libtool and gphoto2 made no difference (building libtool recreates dlopen.a)

I have attached the log of configure and make for libgphoto2 and I noticed there are a few warnings in it like:
*** Warning: Linking the shared library libgphoto2.la against the
*** static library /mnt/flash/lib/libexif.a is not portable!

I also tried some older version of libgphoto2 and gphoto2 (2.4.0 and 2.4.6 and 2.4.7) and that did not make any difference either. Following is output from gdb run (note /mnt/flash/lib/libgphoto2/2.4.7)

Program received signal SIGSEGV, Segmentation fault.
0x00076580 in ?? ()
(gdb) bt
#0  0x00076580 in ?? ()
#1  0x4015283c in tryall_dlopen (phandle=0xbe941e7c,
    filename=0x770b8 "dlopen.a", padvise=0x0, vtable=0x0) at libltdl/ltdl.c:430
#2  0x40154e34 in try_dlopen (phandle=0xbe941ed0,
    filename=0x40159718 "dlopen.a", ext=0x770ce ".a", advise=0x0)
    at libltdl/ltdl.c:1430
#3  0x40155774 in lt_dlopenadvise (filename=0x40159718 "dlopen.a", advise=0x0)
    at libltdl/ltdl.c:1607
#4  0x401555e8 in lt_dlopen (filename=0x40159718 "dlopen.a")
    at libltdl/ltdl.c:1563
#5  0x4015132c in lt_dlpreload_open (originator=0x401591f0 "libltdl",
    func=0x40151ff8 <loader_init_callback>) at libltdl/loaders/preopen.c:353
#6  0x401522cc in lt_dlinit () at libltdl/ltdl.c:237
#7  0x40077a7c in gp_abilities_list_load_dir (list=0x77088,
    dir=0x400b8e78 "/mnt/flash/lib/libgphoto2/2.4.7", context=0x76108)
    at gphoto2-abilities-list.c:192
#8  0x40078288 in gp_abilities_list_load (list=0x77088, context=0x76108)
    at gphoto2-abilities-list.c:320
#9  0x000144ac in gp_params_abilities_list (p=0x73d30) at gp-params.c:311
#10 0x0001a690 in main (argc=2, argv=0xbe94ce14, envp=0xbe94ce20) at main.c:1875
(gdb)

Back to the board again ....

libphoto2-Build.log
0
 
LVL 12

Expert Comment

by:HappyCactus
ID: 33744049
I see:


checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking ltdl.h usability... yes
checking ltdl.h presence... no
configure: WARNING: ltdl.h: accepted by the compiler, rejected by the preprocessor!
configure: WARNING: ltdl.h: proceeding with the compiler's result
checking for ltdl.h... yes
checking for lt_dlinit in -lltdl... yes
checking that we can compile and link with libltdl... yes



Check that warning: Maybe you have some problem with tld.
Try the test suite as I suggested here in comment #33734447

I also see:

checking libexif/exif-data.h usability... yes
checking libexif/exif-data.h presence... no
configure: WARNING: libexif/exif-data.h: accepted by the compiler, rejected by the preprocessor!
configure: WARNING: libexif/exif-data.h: proceeding with the compiler's result
checking for libexif/exif-data.h... yes
checking libexif library flags... "/mnt/flash/lib/libexif.a"
checking libexif cpp flags... "/mnt/flash/include"

You could try to build libexif with only shared library (--enable-shared and --disable-static).

But again, check if tld is working correctly.

0
 

Accepted Solution

by:
FarcoTech earned 0 total points
ID: 33868696
I have spent some time to get the OpenEmbedded work on my system. I am glad to report that finally I have a working OpenEmbedded that can use to build kernel, filesystem and other packages such as gphoto. As the result I now have a working gphoto2 running on my arm platform. Obviously there has been some problem in my previous build environment which led to the gphoto issue, but I could not find it.

All your suggestions have been helpful though, Thanks
0

Featured Post

Free Trending Threat Insights Every Day

Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

Join & Write a Comment

Displaying an arrayList in a listView using the default adapter is rarely the best solution. To get full control of your display data, and to be able to refresh it after editing, requires the use of a custom adapter.
Entering a date in Microsoft Access can be tricky. A typo can cause month and day to be shuffled, entering the day only causes an error, as does entering, say, day 31 in June. This article shows how an inputmask supported by code can help the user a…
An introduction to basic programming syntax in Java by creating a simple program. Viewers can follow the tutorial as they create their first class in Java. Definitions and explanations about each element are given to help prepare viewers for future …
Video by: Grant
The goal of this video is to provide viewers with basic examples to understand and use while-loops in the C programming language.

757 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

23 Experts available now in Live!

Get 1:1 Help Now