rpath problem?

[Arwin Arni <ar...@collab.net>]

Sometimes while compiling our sources, I get errors like this:

cd subversion/svn && /usr/share/apr-1.0/build/libtool --tag=CC --silent 
--mode=link gcc  -Wno-system-headers -Wold-style-definition 
-Werror=declaration-after-statement -Wpointer-arith -Wwrite-strings 
-Wshadow -ansi -Wall -Wformat=2 -Wunused -Waggregate-return 
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations 
-Wno-multichar -Wredundant-decls -Wnested-externs -Wunreachable-code 
-Winline -Wno-long-long -g -pthread -D_LARGEFILE64_SOURCE -DNE_LFS 
-Werror=implicit-function-declaration  -DSVN_DEBUG -DAP_DEBUG   -rpath 
/home/arwin/Binaries/svn_trunk/lib  -o svn  add-cmd.lo blame-cmd.lo 
cat-cmd.lo changelist-cmd.lo checkout-cmd.lo cleanup-cmd.lo 
commit-cmd.lo conflict-callbacks.lo copy-cmd.lo delete-cmd.lo 
diff-cmd.lo export-cmd.lo help-cmd.lo import-cmd.lo info-cmd.lo 
list-cmd.lo lock-cmd.lo log-cmd.lo main.lo merge-cmd.lo mergeinfo-cmd.lo 
mkdir-cmd.lo move-cmd.lo notify.lo patch-cmd.lo propdel-cmd.lo 
propedit-cmd.lo propget-cmd.lo proplist-cmd.lo props.lo propset-cmd.lo 
relocate-cmd.lo resolve-cmd.lo resolved-cmd.lo revert-cmd.lo 
status-cmd.lo status.lo switch-cmd.lo tree-conflicts.lo unlock-cmd.lo 
update-cmd.lo upgrade-cmd.lo util.lo 
../../subversion/libsvn_client/libsvn_client-1.la 
../../subversion/libsvn_wc/libsvn_wc-1.la 
../../subversion/libsvn_ra/libsvn_ra-1.la 
../../subversion/libsvn_delta/libsvn_delta-1.la 
../../subversion/libsvn_diff/libsvn_diff-1.la 
../../subversion/libsvn_subr/libsvn_subr-1.la -laprutil-1 -lapr-1 
-Wl,-Bsymbolic-functions -lneon
/home/arwin/Binaries/svn_trunk/lib/libsvn_ra_svn-1.so.0: undefined 
reference to `svn_string_from_stringbuf'
collect2: ld returned 1 exit status
make: *** [subversion/svn/svn] Error 1

This goes away when I remove the prefix location. (rm -rf 
/home/arwin/Binaries/svn_trunk).

Why should the make process depend on what exists at the target?

Arwin Arni

Re: rpath problem?

[Stefan Sperling <st...@elego.de>]

On Fri, Jun 03, 2011 at 04:16:48PM +0530, Arwin Arni wrote:
> Sometimes while compiling our sources, I get errors like this:
> 
> cd subversion/svn && /usr/share/apr-1.0/build/libtool --tag=CC
> --silent --mode=link gcc  -Wno-system-headers -Wold-style-definition
> -Werror=declaration-after-statement -Wpointer-arith -Wwrite-strings
> -Wshadow -ansi -Wall -Wformat=2 -Wunused -Waggregate-return
> -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
> -Wno-multichar -Wredundant-decls -Wnested-externs -Wunreachable-code
> -Winline -Wno-long-long -g -pthread -D_LARGEFILE64_SOURCE -DNE_LFS
> -Werror=implicit-function-declaration  -DSVN_DEBUG -DAP_DEBUG
> -rpath /home/arwin/Binaries/svn_trunk/lib  -o svn  add-cmd.lo
> blame-cmd.lo cat-cmd.lo changelist-cmd.lo checkout-cmd.lo
> cleanup-cmd.lo commit-cmd.lo conflict-callbacks.lo copy-cmd.lo
> delete-cmd.lo diff-cmd.lo export-cmd.lo help-cmd.lo import-cmd.lo
> info-cmd.lo list-cmd.lo lock-cmd.lo log-cmd.lo main.lo merge-cmd.lo
> mergeinfo-cmd.lo mkdir-cmd.lo move-cmd.lo notify.lo patch-cmd.lo
> propdel-cmd.lo propedit-cmd.lo propget-cmd.lo proplist-cmd.lo
> props.lo propset-cmd.lo relocate-cmd.lo resolve-cmd.lo
> resolved-cmd.lo revert-cmd.lo status-cmd.lo status.lo switch-cmd.lo
> tree-conflicts.lo unlock-cmd.lo update-cmd.lo upgrade-cmd.lo util.lo
> ../../subversion/libsvn_client/libsvn_client-1.la
> ../../subversion/libsvn_wc/libsvn_wc-1.la
> ../../subversion/libsvn_ra/libsvn_ra-1.la
> ../../subversion/libsvn_delta/libsvn_delta-1.la
> ../../subversion/libsvn_diff/libsvn_diff-1.la
> ../../subversion/libsvn_subr/libsvn_subr-1.la -laprutil-1 -lapr-1
> -Wl,-Bsymbolic-functions -lneon
> /home/arwin/Binaries/svn_trunk/lib/libsvn_ra_svn-1.so.0: undefined
> reference to `svn_string_from_stringbuf'
> collect2: ld returned 1 exit status
> make: *** [subversion/svn/svn] Error 1

Sometimes when files or symbols are renamed or deleted dependencies
recorded by the build system are outdated. In which case you must
run ./gen-make.py or ./configure again before compiling.

> This goes away when I remove the prefix location. (rm -rf
> /home/arwin/Binaries/svn_trunk).
>
> Why should the make process depend on what exists at the target?

I guess that's just a side-effect of the above problem.

Re: rpath problem?

[Philip Martin <ph...@wandisco.com>]

Arwin Arni <ar...@collab.net> writes:

> Why should the make process depend on what exists at the target?

Your distribution may make modifications to libtool to reduce the
inter-library dependencies; such modification can cause problems when
the build produces libraries that link to other libraries in the build.
See for example:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=291641

I routinely use --prefix=/some/non-existant/path during development as
most of my builds don't ever get installed.  I reconfigure/rebuild to
install.

-- 
Philip