Link error on Raspberry Pi sample program

[Anonymous]

I have an evaluation copy of VisualGDB installed with the Raspberry toolchain, and I am trying to work my way through the Raspberry’s example programs as a means of verifying that the Sysprog tools will work the way I expect and so on. This has been working fine, until I got to the example demonstrating fonts (hello_font). This is the procedure I have been following, and below is the error I am stuck on.

I copied from the Raspberry to my PC the directory structure that contains all the sample programs and some other directories containing library and headers that they referred to. I then used VisualDGB to create an empty project in the same directory as the Makefile for a given sample program. VisualGDB creates a directory with the solution name at this point, so that it did not overwrite the original Makefile, which I wanted for reference. I then populated the empty project by adding the original source files to it. I made changes to the flags.mak file to include the correct headers and libraries and so on, including the consideration that I was running from one directory level down from the original when copying the realitve paths. This has worked fine on several of the programs, building an execuable file that I could then copy back to the Raspberry and run, and it worked.

On the font program however, I get an error from the linker – “undefined reference to symbol ‘vcos_log_impl’ ” with instructions to include the correct library – libvcos.so. The thing is, it’s already included, as you can see below (with some difficulty I admit). It’s in the same directory as at least three of the other libraries ( libGLESv2.so, libEGL.so, and libopenmaxil.so ), so I know it is in the search path. This is the output log produced by VisualGDB. I am at a loss as to what to even look at. Any suggestions would be appreciated.

Performing Makefile project actions
VisualGDB: Attempting inline build…
cmd.exe /c “C:Program FilesSysprogsVisualGDBmake.exe” CONFIG=DEBUG

C:/SysGCC/Raspberry/bin/arm-linux-gnueabihf-gcc.exe -ggdb -ffunction-sections -DSTANDALONE -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -DTARGET_POSIX -D_LINUX -fPIC -DPIC -D_REENTRANT -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -U_FORTIFY_SOURCE -Wall -g -DHAVE_LIBOPENMAX=2 -DOMX -DOMX_SKIP64BIT -ftree-vectorize -pipe -DUSE_EXTERNAL_OMX -DHAVE_LIBBCM_HOST -DUSE_EXTERNAL_LIBBCM_HOST -DUSE_VCHIQ_ARM -Wno-psabi -O0 -IC:/RaspberryPi/opt/vc/include -IC:/RaspberryPi/opt/vc/include/interface/vcos/pthreads -IC:/RaspberryPi/opt/vc/include/interface/vmcs_host/linux -I../ -I../../libs/ilclient -I../../libs/vgfont -DDEBUG -c ../main.c -o Debug/main.o -MD -MF Debug/main.dep

C:/SysGCC/Raspberry/bin/arm-linux-gnueabihf-g++.exe -o Debug/Font -Wl,-gc-sections -LC:/RaspberryPi/opt/vc/lib -LC:/RaspberryPi/usr/lib/arm-linux-gnueabihf -L../../libs/ilclient -L../../libs/vgfont -Wl,–start-group Debug/main.o -lGLESv2 -lEGL -lopenmaxil -lbcm_host -lvcos -lvchiq_arm -lpthread -lrt -ldl -lvgfont -lfreetype -lz -Wl,–end-group

c:/sysgcc/raspberry/bin/../lib/gcc/arm-linux-gnueabihf/4.6/../../../../arm-linux-gnueabihf/bin/ld.exe: C:/RaspberryPi/opt/vc/lib/libbcm_host.so: undefined reference to symbol ‘vcos_log_impl’

c:/sysgcc/raspberry/bin/../lib/gcc/arm-linux-gnueabihf/4.6/../../../../arm-linux-gnueabihf/bin/ld.exe: note: ‘vcos_log_impl’ is defined in DSO C:/RaspberryPi/opt/vc/lib/libvcos.so so try adding it to the linker command line

C:/RaspberryPi/opt/vc/lib/libvcos.so: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make: *** [Debug/Font] Error 1

[ket]

Hi,

We have seen some similar issues before, where the linker does not seem to find the library based on the name even if it is on its search path.
As a work-around try specifying the library with its full path and name in the LDFLAGS variable in flags.mak (e.g. LDFLAGS := -Wl,-gc-sections C:/RaspberryPi/opt/vc/lib/libvcos.so).

Btw, the default directory to copy additional libraries and headers to for the cross-toolchain is at C:SysGCCraspberryarm-linux-gnueabihfsysroot. This should not however affect the issue you are having.

Sometimes also issues arise from copying the directories from the Raspberry PI in ways that may break symbolic links. You can open a SSH console to Raspberry PI, from Visual Studio Tools->SSH Host Manager. In our SSH console there is a SCP menu that allows easy downloading of directories in tar files.

[Mustrum]

Hi ket,

Thank you for the reply and the suggestion. Unfortunately, when I tried it, and several variations I could think of, but it still did not result in a successful link. Many of the variations in the order of directory in and library specifications did give the result that a different symbol was identified as being the one not found.

I did solve the problem in the end. I was aware of the possible problems with symbolic links and I had used the method that you suggested for copying files from the Raspberry Pi. But I noticed that some of the time, the error message produced referred to an unfound archive by an explicit full pathname. The reference was to archives that were in directories I had copied, and the PC directory I had copied them to was specified in the search path (specifically the LC:/RaspberryPi/usr/lib/arm-linux-gnueabihf directory), but on the Raspberry Pi, the path started at the root. This would only occur when I had got as far as getting the archive freetype to be included in the link, and I thought perhaps it somehow contained absolute path names for the archives it needed. This seemed to be the case, because when I made copies of those archives starting from the root directory on my PC, the link suddenly worked and produced a working executable file. So the problem seems to have been with the archives of the Raspberry Pi I was trying to link, and nothing to do with the toolchain I had loaded along with my VisualGDB trial, nor with the VisualGDB plugin. I probably would have got there eventually, but your comment about the default location for additional libraries to be placed got me thinking along those lines, so it probably saved me a week of frustration. Thanks.

[Author]

Posts