I have been able to install and start a program with CMake (with HDF5) but once I access the "about" drop-down link for said program it crashes with the following error:
python: symbol lookup error: /nobackup/<user id>/program-devel/dist_linux/bin_linux/libprogramDLL.so: undefined symbol: h5lib_MP_h5get_libversion_f_
I believe it is an issue with linking static libraries but I am, unfortunately, quite new to CMake and unable to isolate the root problem. I know that this "symbol" is tied somehow to a libhdf5_fortran.a and this is listed in my Cache with:
$ grep -rnw '/nobackup/<user id>/program-devel/build' -e "libhdf5_fortran"
/nobackup/<user id>/program-devel/build/CMakeCache.txt:234:ToolkitLib_LIB_DEPENDS:STATIC=general;SomeLib;general;libz.a;general;libhdf5.a;general;libhdf5_fortran.a;
I’m not sure if this might be where the problem is or not but this is from the ToolKit file - CMakeLists.txt.
if (${USE_HDF5})
#link_directories (${HDF5_DIRECTORY}/lib)
if (WIN32)
target_link_libraries(ToolkitLib libszip libzlib libhdf5 libhdf5_f90cstub libhdf5_fortran)
else ()
# doesn't seem to work on Linux for some reason....
#target_link_libraries(ToolkitLib libsz libz libhdf5 libhdf5_fortran)
# ... try this ... seems to be getting the shared libs...not the static ones...
# set(HDF5_LINK_FLAGS "-L${HDF5_DIRECTORY}/lib -lz -lhdf5_fortran -lhdf5")
# SET(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} ${HDF5_LINK_FLAGS}")
# SET(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} ${HDF5_LINK_FLAGS}")
# ... doesn't work either ...
target_link_libraries(ToolkitLib libz.a libhdf5.a libhdf5_fortran.a)
endif()
endif()
The last 4 "target_link_library" elements are in directories I've added to my LD_LIBRARY_PATH (although, I've heard this isn't the preferred approach). There is also a final output line when I issue gmake install that might be relevant:
-- Set runtime path of "/nobackup/<user id>/program-devel/dist_linux/bin_linux/libProgramDLL.so" to "$ORIGIN/"
It seems I fixed my problem by adding a --with-pic on the hdf5 installation bash scripts. I also had to remove a -standard-semantics from the CMAKE_Fortran_FLAGS in the src directory. Those two things along with the help you provided fixed my problem. Thanks a lot Pierre de Buyl!
Related
I have a library that interfaces against ImageMagick 6. During compilation I get the below compilation warnings (promoted to errors by me).
I am aware that explicitly defining these values during compilation using -DMAGICKCORE_QUANTUM_DEPTH=16 -DMAGICKCORE_HDRI_ENABLE=0 will solve the issue (on my specific installation), however, as I am writing my CMake configuration files to be as portable as I can make them, this feels way to brittle and I really hope there is a better way.
Which brings me back to my question: Is there a way to determine MAGICKCORE_HDRI_ENABLE and MAGICKCORE_QUANTUM_DEPTH using cmake, bash or similar for the specific version of the library I am linking against?
/usr/include/ImageMagick-6/magick/magick-config.h:29:3: error: #warning "you should set MAGICKCORE_QUANTUM_DEPTH to sensible default set it to configure time default" [-Werror=cpp]
# warning "you should set MAGICKCORE_QUANTUM_DEPTH to sensible default set it to configure time default"
^
/usr/include/ImageMagick-6/magick/magick-config.h:30:3: error: #warning "this is an obsolete behavior please fix your makefile" [-Werror=cpp]
# warning "this is an obsolete behavior please fix your makefile"
^
/usr/include/ImageMagick-6/magick/magick-config.h:52:3: error: #warning "you should set MAGICKCORE_HDRI_ENABLE to sensible default set it to configure time default" [-Werror=cpp]
# warning "you should set MAGICKCORE_HDRI_ENABLE to sensible default set it to configure time default"
^
/usr/include/ImageMagick-6/magick/magick-config.h:53:3: error: #warning "this is an obsolete behavior please fix yours makefile" [-Werror=cpp]
# warning "this is an obsolete behavior please fix yours makefile"
^
cc1plus: all warnings being treated as errors
While writing the question I came across an answer to this. I'll summarize it here as the other questions regarding this angle it slightly differently.
Imagemagick ships with an utility called Magick++-config on my installation (Ubuntu 16.04) I found this utility under /usr/lib/x86_64-linux-gnu/ImageMagick-6.8.9/bin-Q16/Magick++-config. Below is the cmake code snipped I ended up using to extract the relevant build options.
find_package(ImageMagick 6.7 COMPONENTS Magick++ MagickCore)
if(ImageMagick_FOUND)
# Find Imagemagick Library directory
get_filename_component(MAGICK_LIB_DIR ${ImageMagick_MagickCore_LIBRARY} DIRECTORY)
# Find where Magick++-config lives
file(GLOB_RECURSE MAGICK_CONFIG FOLLOW_SYMLINKS ${MAGICK_LIB_DIR}/Magick++-config)
# Ask about CXX and lib flags/locations
set(MAGICK_CONFIG ${MAGICK_CONFIG} CACHE string "Path to Magick++-config utility")
execute_process(COMMAND "${MAGICK_CONFIG}" "--cxxflags" OUTPUT_VARIABLE MAGICK_CXX_FLAGS)
execute_process(COMMAND "${MAGICK_CONFIG}" "--libs" OUTPUT_VARIABLE MAGICK_LD_FLAGS)
# Add these to cache
set(MAGICK_CXX_FLAGS "${MAGICK_CXX_FLAGS}" CACHE string "ImageMagick configuration specific compilation flags." )
set(MAGICK_LD_FLAGS "${MAGICK_LD_FLAGS}" CACHE string "ImageMagick configuration specific linking flags.")
# Split into list:
string(REGEX MATCHALL "([^\ ]+)" MAGICK_CXX_FLAGS "${MAGICK_CXX_FLAGS}")
string(REGEX MATCHALL "([^\ ]+)" MAGICK_LD_FLAGS "${MAGICK_LD_FLAGS}")
# Remove trailing whitespace (CMAKE warns about this)
string(STRIP "${MAGICK_CXX_FLAGS}" MAGICK_CXX_FLAGS)
string(STRIP "${MAGICK_LD_FLAGS}" MAGICK_LD_FLAGS)
target_compile_options(<project> ${MAGICK_CXX_FLAGS})
target_link_libraries(<project> ${MAGICK_LD_FLAGS})
endif(ImageMagick_FOUND)
Source
I'm doing my first steps with Qt and QtWebEngine on an embedded board (i.MX6), using Yocto. Using provided example recipes, like the quicknanobrowser, works nicely on the target. So I can't confirm this answer which claims that WebEngine is not available on embedded platforms.
Now I want to write my own QML application and deploy it on the board. With the recipe meta-toolchain-qt5 I created an SDK and installed it. In QtCreator I set all paths to the SDK installation and tried to build it, but got this error:
Project ERROR: Unknown module(s) in QT: webengine
11:13:13: The process "/opt/poky/1.8/sysroots/x86_64-pokysdk-linux/usr/bin/qt5/qmake" exited with code 3.
It turned out that WebEngine was not included in the SDK. Thanks to this answer, I fixed that by putting the following to my own packagegroup-qt5-toolchain-target.bbappend file:
RDEPENDS_${PN} += " \
qtwebengine \
qtwebengine-qmlplugins \
qtquickcontrols-qmlplugins \
qtwebengine-examples \
"
Then reinstalled the SDK. Now it seems that all WebEngine files are available in the SDK installation (the zsh glob pattern below matches all directories in any subdirectory of /opt/poky/1.8/, which contain "webengine", case-insensitively):
% ls -1 -d (#i)/opt/poky/1.8/**/*webengine*(/)
/opt/poky/1.8/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/include/qt5/QtWebEngine/
/opt/poky/1.8/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/include/qt5/QtWebEngine/5.4.3/QtWebEngine/
/opt/poky/1.8/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/include/qt5/QtWebEngineWidgets/
/opt/poky/1.8/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/include/qt5/QtWebEngineWidgets/5.4.3/QtWebEngineWidgets/
/opt/poky/1.8/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/lib/qt5/qml/QtWebEngine/
/opt/poky/1.8/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/share/qt5/examples/webengine/
/opt/poky/1.8/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/share/qt5/examples/webenginewidgets/
/opt/poky/1.8/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/share/qt5/translations/qtwebengine_locales/
Still, I get the same Unknown module error. This is independent of QtCreator, and can also be shown by directly calling qmake:
% source /opt/poky/1.8/environment-setup-cortexa9hf-vfp-neon-poky-linux-gnueabi
% /opt/poky/1.8/sysroots/x86_64-pokysdk-linux/usr/bin/qt5/qmake /home/me/test/test.pro -r -spec linux-oe-g++ CONFIG+=debug CONFIG+=declarative_debug CONFIG+=qml_debug
Project ERROR: Unknown module(s) in QT: webengine
The project itself should be fine, because it compiles and runs without problems on the Desktop installation.
Any ideas? Are there maybe still some files missing in the SDK? Where does qmake search for the modules? How can I tell qmake where to find the WebEngine installation?
In /opt/poky/1.8/environment-setup-cortexa9hf-vfp-neon-poky-linux-gnueabi
add sh /opt/poky/1.8/sysroots/x86_64-pokysdk-linux/environment-setup.d/qt5.sh
This will set up the Qt5 environment.
I recently had it pointed out to me that I might have OpenNI installed correctly but PCL is unable to access it. I've been trying to use various packages with the Kinect and when cmake compiling I always encounter the same error:
-- checking for module 'openni-dev'
-- package 'openni-dev' not found
-- Could NOT find openni (missing: OPENNI_INCLUDE_DIRS)
** WARNING ** io features related to openni will be disabled
I used printenv and received this output:
printenv
SSH_AGENT_PID=2570
GPG_AGENT_INFO=/tmp/keyring-xXJFL7/gpg:0:1
TERM=xterm
SHELL=/bin/bash
ROS_ROOT=/opt/ros/hydro/share/ros
XDG_SESSION_COOKIE=aa6e36316433d5c21f6f3b1500000008-1400098211.848077-377195861
ROS_PACKAGE_PATH=/opt/ros/hydro/share
ROS_MASTER_URI=http://localhost:11311
WINDOWID=56623110
GNOME_KEYRING_CONTROL=/tmp/keyring-xXJFL7
USER=robot2
LD_LIBRARY_PATH=/opt/ros/hydro/lib
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lz=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.axa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36:
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
CPATH=/opt/ros/hydro/include
SSH_AUTH_SOCK=/tmp/keyring-xXJFL7/ssh
SESSION_MANAGER=local/robot2-Precision-T7600:#/tmp/.ICE-unix/2535,unix/robot2-Precision-T7600:/tmp/.ICE-unix/2535
DEFAULTS_PATH=/usr/share/gconf/ubuntu.default.path
XDG_CONFIG_DIRS=/etc/xdg/xdg-ubuntu:/etc/xdg
PATH=/opt/ros/hydro/bin:/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
DESKTOP_SESSION=ubuntu
PWD=/home/robot2
GNOME_KEYRING_PID=2524
LANG=en_US.UTF-8
MANDATORY_PATH=/usr/share/gconf/ubuntu.mandatory.path
UBUNTU_MENUPROXY=libappmenu.so
COMPIZ_CONFIG_PROFILE=ubuntu
GDMSESSION=ubuntu
SHLVL=1
HOME=/home/robot2
ROS_DISTRO=hydro
GNOME_DESKTOP_SESSION_ID=this-is-deprecated
PYTHONPATH=/opt/ros/hydro/lib/python2.7/dist-packages
LOGNAME=robot2
XDG_DATA_DIRS=/usr/share/ubuntu:/usr/share/gnome:/usr/local/share/:/usr/share/
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-DdLQNdIXso,guid=2440d412c31af4bd219f648600000030
PKG_CONFIG_PATH=/opt/ros/hydro/lib/pkgconfig
LESSOPEN=| /usr/bin/lesspipe %s
CMAKE_PREFIX_PATH=/opt/ros/hydro
DISPLAY=:0.0
XDG_CURRENT_DESKTOP=Unity
LESSCLOSE=/usr/bin/lesspipe %s %s
ROS_ETC_DIR=/opt/ros/hydro/etc/ros
COLORTERM=gnome-terminal
XAUTHORITY=/home/robot2/.Xauthority
_=/usr/bin/printenv
Does anyone have any ideas? Is this potentially a path issue?
It seems you have installed OpenNI into some non-standard ocation, that's why CMake can't locate it. Help it by setting CMAKE_PREFIX_PATH to the dir where OpenNI's include/ is located.
Ubuntu 12.04
CMake 2.8.9
Postgresql 9.2.2
I'm trying to get the FindPostgreSQL module to find /usr/include/postgresql/libpq-fe.h.
Here's what I have in my CMakeLists.txt:
find_package(PostgreSQL REQUIRED)
This is the error I get:
CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:97 (MESSAGE):
Could NOT find PostgreSQL (missing: PostgreSQL_TYPE_INCLUDE_DIR) (found
version "9.2.2")
Call Stack (most recent call first):
/usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:288 (_FPHSA_FAILURE_MESSAGE)
/usr/share/cmake-2.8/Modules/FindPostgreSQL.cmake:155 (find_package_handle_standard_args)
CMakeLists.txt:7 (find_package)
I added the following lines before calling find_package but it didn't seem to have any effect.
set(PostgreSQL_ADDITIONAL_VERSIONS "9.2.2")
set(PostgreSQL_ADDITIONAL_SEARCH_PATHS ${PostgreSQL_ADDITIONAL_SEARCH_PATHS} "/usr/include/postgresql")
I also tried googling for PostgreSQL_TYPE_INCLUDE_DIR but didn't find anything. What else can I try?
Make sure you've installed both libpq-dev\ and postgresql-server-dev-all (or specific version e.g. postgresql-server-dev-9.4)
$ dpkg --get-selections | grep -e "libpq-dev\|postgresql-server-dev"
in case you're missing some package
apt-get install libpq-dev postgresql-server-dev-all
should fix it.
After a bit more debugging I figured out that it's getting stuck trying to find pg_type.h
This file is located in /usr/include/postgresql/catalog/pg_types.h but the module is expecting to find it in /usr/include/postgresql/server/catalog/pg_types.h
find_path(PostgreSQL_TYPE_INCLUDE_DIR
NAMES catalog/pg_type.h
PATHS
# Look in other places.
${PostgreSQL_ROOT_DIRECTORIES}
PATH_SUFFIXES
pgsql/server
postgresql/server
include/server
# Help the user find it if we cannot.
DOC "The ${PostgreSQL_INCLUDE_DIR_MESSAGE}"
)
It works if I add postgresql to the PATH_SUFFIXES
find_path(PostgreSQL_TYPE_INCLUDE_DIR
NAMES catalog/pg_type.h
PATHS
# Look in other places.
${PostgreSQL_ROOT_DIRECTORIES}
PATH_SUFFIXES
postgresql
pgsql/server
postgresql/server
include/server
# Help the user find it if we cannot.
DOC "The ${PostgreSQL_INCLUDE_DIR_MESSAGE}"
)
On Ubuntu you can also work around that issue by calling cmake with having PostgreSQL_TYPE_INCLUDE_DIR defined like this:
cmake -DPostgreSQL_TYPE_INCLUDE_DIR=/usr/include/postgresql/
See the bug report [1] for this issue and a potential fix [2]. Álso see the discussion about the reasoning behind the move on the debian mailinglist at [3].
On Ubuntu/Debian, starting with PostgreSQL 9.3 the header file pg_type.h
is moved to a separate package (from libpq-dev to postgresql-server-dev)
and consequently the file pg_type.h is moved to a new location
[1] https://gitlab.kitware.com/cmake/cmake/issues/17223
[2] https://gitlab.kitware.com/cmake/cmake/commit/d4fd30d8d8f5b9c4b5a110b4676cad2a19d7c314
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=314427
From Linux Mint 17.3 ("Rosa") with PostgreSQL 9.3, I had to adjust ilia choly's solution (interestingly, the suggested postgres entry in the list was already present in the file, but wasn't enough to fix things).
I had to edit /usr/share/cmake-2.8/Modules/FindPostgreSQL.cmake around line 114 and add postgresql/9.3 so that the find_path call looks like
find_path(PostgreSQL_TYPE_INCLUDE_DIR
NAMES catalog/pg_type.h
PATHS
# Look in other places.
${PostgreSQL_ROOT_DIRECTORIES}
PATH_SUFFIXES
postgresql/9.3
postgresql
pgsql/server
postgresql/server
include/server
# Help the user find it if we cannot.
DOC "The ${PostgreSQL_INCLUDE_DIR_MESSAGE}"
)
I'm creating a library libgdata that has some tests and non-installed programs. I am running into the problem that once I've installed the library once, the programs seem to be linking to the installed version and not the local version in ../src/libgdata.la any longer.
What could cause this? Am I doing something horribly wrong?
Here is what my test/Makefile.am looks like:
INCLUDES = -I$(top_srcdir)/src/ -I$(top_srcdir)/test/
# libapiutil contains all of our dependencies!
AM_CXXFLAGS = $(APIUTIL_CFLAGS)
AM_LDFLAGS = $(APIUTIL_LIBS)
LDADD = $(top_builddir)/src/libgdata.la
noinst_PROGRAMS = gdatacalendar gdatayoutube
gdatacalendar_SOURCES = gdatacalendar.cc
gdatayoutube_SOURCES = gdatayoutube.cc
TESTS = check_bare
check_PROGRAMS = $(TESTS)
check_bare_SOURCES = check_bare.cc
(libapiutil is another library that has some helper stuff for dealing with libcurl and libxml++)
So, for instance, if I run the tests without having installed anything, everything works fine. I can make changes locally and they are picked up by these programs right away.
If I install the package, these programs will compile (it seems like it does actually look locally for the headers), but once I run the program it complains about missing symbols.
As far as I can tell, it is linking against the newly built library (../src/libgdata.la) based on the make output, so I'm not sure why this would be happening. If i remove the installed files, the local changes to src/* are picked up just fine.
I've included the make output for gdatacalendar below.
g++ -DHAVE_CONFIG_H -I. -I.. -I../src/ -I../test/ -I/home/altern8/workspaces/4355/dev-install/include -I/usr/include/libxml++-2.6 -I/usr/lib/libxml++-2.6/include -I/usr/include/libxml2 -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g -O2 -MT gdatacalendar.o -MD -MP -MF .deps/gdatacalendar.Tpo -c -o gdatacalendar.o gdatacalendar.cc
mv -f .deps/gdatacalendar.Tpo .deps/gdatacalendar.Po
/bin/bash ../libtool --tag=CXX --mode=link g++ -I/home/altern8/workspaces/4355/dev-install/include -I/usr/include/libxml++-2.6 -I/usr/lib/libxml++-2.6/include -I/usr/include/libxml2 -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g -O2 -L/home/altern8/workspaces/4355/dev-install/lib -lapiutil -lcurl -lgssapi_krb5 -lxml++-2.6 -lxml2 -lglibmm-2.4 -lgobject-2.0 -lsigc-2.0 -lglib-2.0 -o gdatacalendar gdatacalendar.o ../src/libgdata.la
mkdir .libs
g++ -I/home/altern8/workspaces/4355/dev-install/include -I/usr/include/libxml++-2.6 -I/usr/lib/libxml++-2.6/include -I/usr/include/libxml2 -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g -O2 -o .libs/gdatacalendar gdatacalendar.o -L/home/altern8/workspaces/4355/dev-install/lib /home/altern8/workspaces/4355/dev-install/lib/libapiutil.so /usr/lib/libcurl.so -lgssapi_krb5 /usr/lib/libxml++-2.6.so /usr/lib/libxml2.so /usr/lib/libglibmm-2.4.so /usr/lib/libgobject-2.0.so /usr/lib/libsigc-2.0.so /usr/lib/libglib-2.0.so ../src/.libs/libgdata.so -Wl,--rpath -Wl,/home/altern8/workspaces/4355/dev-install/lib
creating gdatacalendar
Help. :)
UPDATE
I get the following messages when I try to run the calendar program when I've added the addCommonRequestHeader() method to the Service class after I had installed the library without the addCommonRequestHeader() method.
/home/altern8/workspaces/4355/libgdata/test/.libs/lt-gdatacalendar:
symbol lookup error:
/home/altern8/workspaces/4355/libgdata/test/.libs/lt-gdatacalendar:
undefined symbol:
_ZN55gdata7service7Service22addCommonRequestHeaderERKSsS4_
Eugene's suggestion to try setting the $LD_LIBRARY_PATH variable did not help.
UPDATE 2
I did two tests. First, I did this after blowing away my dev-install directory (--prefix) and in that case, it creates test/.libs/lt-gdatacalendar. Once I have installed the library, though, it creates test/.libs/gdatacalendar instead. The output of ldd is the same for both with one exception:
# before install
# ldd test/.libs/lt-gdatacalendar
libgdata.so.0 => /home/altern8/workspaces/4355/libgdata/src/.libs/libgdata.so.0 (0xb7c32000)
# after install
# ldd test/.libs/gdatacalendar
libgdata.so.0 => /home/altern8/workspaces/4355/dev-install/lib/libgdata.so.0 (0xb7c87000)
What would cause this to create lt-gdatacalendar in one case but gdatacalendar in another?
The output of ldd on libgdata is:
altern8#goldfrapp:~/workspaces/4355/libgdata$ ldd /home/altern8/workspaces/4355/libgdata/src/.libs/libgdata.so.0
linux-gate.so.1 => (0xb7f7c000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7f3b000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7dec000)
/lib/ld-linux.so.2 (0xb7f7d000)
I think I've sorted this out.
The problem should be that libtool sees the "-L" flag in the command line before it sees the "../src/libgdata.so" part. In this case, it executes the linker with "-Wl,-rpath,..." for that "-L" path. If that path contains "libgdata.so", then it will always be used, which is the case here.
In my case, I've rearranged "prog_LDADD" to like like this:
"prog_LDADD = $(top_builddir)/src/my_lib.so $(DEPENDENCY_LIBS)"
In your case, try to delete AM_LDFLAGS and write:
LDADD = $(top_builddir)/src/libgdata.la $(APIUTIL_LIBS)
Not sure how to do that in autoconf, but final command might need to have -L../src, so linker can find newly built library first.
Try manually running last command with that addition and see if that helps.
EDIT: Ok, I guess misread it, thought it wasn't linking, but you are saying it links but doesn't run?
If that is the case, run ldd on your binary and see which .so it picks up -- most likely installed (and outdated) ones.
In this case, either install updated libs before running, or export LD_LIBRARY_PATH env variable before running.
export LD_LIBRARY_PATH="/path to freshly built libs"
I know that for dependencies to work correctly, you need to refer to libgdata.la with a relative path in LDADD; it's possible that affects the situation you're describing as well.
I'm not sure why, though. The behavior you're describing does seem a bit odd; and perhaps worth reporting to the libtool developers.
Without -no-install libtool creates script wrappers and puts the executables into the .libs/ subdir (linked with the installed libraries). Calling the wrapper makes your executable load/link with your local (not installed) library - so everything works fine, e.g. make check does not test the installed but your freshly baken library.
In some cases (e.g. when debugging or valgrinding), you do not want to have those wrappers, but real executables directly linked with your local library. For this you use AM_LDFLAGS = -no-install (or just set it for single targets).
More details here