You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Gabriela Gibson <ga...@gmail.com> on 2013/01/09 17:31:05 UTC
Diff Project compilation problem
I added a new option to the command structure and the compile error I
get is this:
../../subversion/libsvn_client/.libs/libsvn_client-1.so: undefined
reference to `svn_wc__get_wcroot'
../../subversion/libsvn_client/.libs/libsvn_client-1.so: undefined
reference to `svn_wc_add_from_disk2'
What is going on here? This is totally unexpected! I grepped for the
terms and I cannot even see a connection %-)
I attached a patch of the changes I made and the compile log is at the
bottom of this mail.
I did make clean prior to this, and also make -k, the make here
was just to cut down the spammy list.
thanks for any advice!
-*- mode: compilation; default-directory: "/home/g/trunk/" -*-
Compilation started at Wed Jan 9 15:13:24
make
------ making all in apr
make[1]: Entering directory `/home/g/trunk/apr'
make[2]: Entering directory `/home/g/trunk/apr'
make[2]: Nothing to be done for `local-all'.
make[2]: Leaving directory `/home/g/trunk/apr'
make[1]: Leaving directory `/home/g/trunk/apr'
------ completed all in apr
------ making all in apr-util
make[1]: Entering directory `/home/g/trunk/apr-util'
make[2]: Entering directory `/home/g/trunk/apr-util'
make[2]: Nothing to be done for `local-all'.
make[2]: Leaving directory `/home/g/trunk/apr-util'
make[1]: Leaving directory `/home/g/trunk/apr-util'
------ completed all in apr-util
cd subversion/svnmucc && /bin/bash /home/g/trunk/libtool --tag=CC
--silent --mode=link gcc -g3 -fno-omit-frame-pointer -fno-inline -Wall
-Wmiss\
ing-prototypes -Wstrict-prototypes -Wmissing-declarations -pthread
-DSVN_DEBUG -DAP_DEBUG -rpath /usr/local/lib -o svnmucc svnmucc.lo ../.\
./subversion/libsvn_client/libsvn_client-1.la
../../subversion/libsvn_ra/libsvn_ra-1.la
../../subversion/libsvn_subr/libsvn_subr-1.la ../../subv\
ersion/libsvn_delta/libsvn_delta-1.la -L/home/g/trunk/apr-util
-laprutil-1 -L/home/g/trunk/apr -lapr-1
../../subversion/libsvn_client/.libs/libsvn_client-1.so: undefined
reference to `svn_wc__get_wcroot'
../../subversion/libsvn_client/.libs/libsvn_client-1.so: undefined
reference to `svn_wc_add_from_disk2'
collect2: ld returned 1 exit status
make: *** [subversion/svnmucc/svnmucc] Error 1
Compilation exited abnormally with code 2 at Wed Jan 9 15:13:26
Re: Diff Project compilation problem
Posted by Stefan Sperling <st...@apache.org>.
On Wed, Jan 09, 2013 at 04:31:05PM +0000, Gabriela Gibson wrote:
> I added a new option to the command structure and the compile error
> I get is this:
>
> ../../subversion/libsvn_client/.libs/libsvn_client-1.so: undefined
> reference to `svn_wc__get_wcroot'
> ../../subversion/libsvn_client/.libs/libsvn_client-1.so: undefined
> reference to `svn_wc_add_from_disk2'
>
> What is going on here?
I believe you're running into the problem where you've got some
released version of Subversion installed on your system, and
libtool is wrongly trying to link to the libsvn_wc from that
version, instead of linking to the proepr libsvn_wc which was
compiled in your working copy of Subversion trunk code.
So, this is not a problem with your patch. Rather, it is a problem
with how the build system interacts with existing software on your
system. It's a long-standing and annoying issue with libtool, where
it generates linker flags in the wrong order, causing the linker to
pick up Subversion libraries from the wrong directory.
It can be tricky to resolve such issues. The easiest option might
be to uninstall the other Subversion version, but that's not always
an option.
What operating system are you trying to compile on? Perhaps someone
who is using the same operating system can help you.
Re: Diff Project compilation problem
Posted by Hyrum K Wright <hy...@hyrumwright.org>.
On Wed, Jan 9, 2013 at 11:37 AM, Branko Čibej <br...@wandisco.com> wrote:
> On 09.01.2013 17:31, Gabriela Gibson wrote:
> > I added a new option to the command structure and the compile error I
> > get is this:
> >
> > ../../subversion/libsvn_client/.libs/libsvn_client-1.so: undefined
> > reference to `svn_wc__get_wcroot'
> > ../../subversion/libsvn_client/.libs/libsvn_client-1.so: undefined
> > reference to `svn_wc_add_from_disk2'
> >
> > What is going on here? This is totally unexpected! I grepped for the
> > terms and I cannot even see a connection %-)
> >
> > I attached a patch of the changes I made and the compile log is at the
> > bottom of this mail.
> >
> > I did make clean prior to this, and also make -k, the make here
> > was just to cut down the spammy list.
> >
> > thanks for any advice!
>
> I think you have to run autogen.sh again to rebuild the generated
> makefiles.
Even just ./gen-make.py should suffice.
fwiw, this probably isn't related to your change, just one that you picked
up upon running 'svn update'.
-Hyrum
Re: Diff Project compilation problem
Posted by Branko Čibej <br...@wandisco.com>.
On 09.01.2013 17:31, Gabriela Gibson wrote:
> I added a new option to the command structure and the compile error I
> get is this:
>
> ../../subversion/libsvn_client/.libs/libsvn_client-1.so: undefined
> reference to `svn_wc__get_wcroot'
> ../../subversion/libsvn_client/.libs/libsvn_client-1.so: undefined
> reference to `svn_wc_add_from_disk2'
>
> What is going on here? This is totally unexpected! I grepped for the
> terms and I cannot even see a connection %-)
>
> I attached a patch of the changes I made and the compile log is at the
> bottom of this mail.
>
> I did make clean prior to this, and also make -k, the make here
> was just to cut down the spammy list.
>
> thanks for any advice!
I think you have to run autogen.sh again to rebuild the generated makefiles.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: Diff Project compilation problem
Posted by Gabriela Gibson <ga...@gmail.com>.
On 09/01/13 16:54, Philip Martin wrote:>
> ./configure --prefix=/usr/local/subversionx ...
>
> which solves the linking problem. I never install this build so
> /usr/local/subversionx/lib never exists. When I want to install a build
> of Subversion I reconfigure and rebuild using the correct prefix (and at
> this stage I may need to remove the Subversion libraries in the prefix
> to get it to link).
>
Thanks Philip. this did the trick. And thanks to everyone else too!
Re: [PATCH] Re: Diff Project compilation problem
Posted by Gabriela Gibson <ga...@gmail.com>.
I propose we add the FAQ entry similar to the following:
<p>One typical error message class involve the following pattern:</p>
<pre>
../../subversion/../*.so: undefined reference to `function_not_worked_on'
collect2: ld returned 1 exit status
make: *** [subversion/something/something] Error 1
</pre>
<p>There are a couple of common causes of this kind of problem:</p>
<p>1. You could be linking to your own installed libraries.</p>
<p>Workaround 1: Remove any installed subversion libraries from
subdirectories of your PREFIX directory. A discussion of this sort of
cleanup is available at <link to Karl Fogel's post in the hacking
guide.</p>
<p>Workaround 2: Specify a different prefix. For example:
<br /><code>"./configure --prefix=/dev/null ## Doesn't exist"</code></p>
<p>2. You may have run <code>"svn up"</code> so that your build system
files are now stale:</p>
<p>Rerun <code>"./autogen.sh; make"</code> or
<code>"./autogen.sh; ./config.nice; make"</code>
to run configure with the same arguments as the last invocation
</p>
Potential addition:
If you have altered a build system file,
<a href="link_to_permutation_table">
see here for information</a> how to refresh your build.
(link to build system doc entry that holds the decision matrix that
explains this bit, see below)
---------------------
Daniel Shahaf wrote:
> How does this compare to the HACKING (docs/community-guide/) section
> containing Karl's "voice of experience" email? Should they
> crossreference each other?
Karls' advice would not have helped me in this situation, the
--prefix=/dev/null was the best soln. for my problem. He addresses
build system changes for the most part.
> It would be useful to explain why this happens or what needs to be run
> when. IIRC the permutations are: if Makefile.in changed, re-run
> configure to regenerate Makefile; if configure.ac or build/ac-macros/
> changed, rerun autogen.sh to regenerate configure (then run configure);
> if build.conf or build/gen-make/ changed, run ./gen-make.py (which is
> normally invoked by autogen.sh) to regenerate build-outputs.mk.
I could add the following table:
Changed File Re-run script Output Next action
==============================================================
Makefile.in configure Makefile make
build.conf gen-make.py build-outputs.mk configure
build/gen-make/ " " "
configure.ac autogen.sh configure "
build/ac-macros/ " " "
---------------------------------------------------------------
However, I think something like that belongs in the section about the
build system, and if the above table(or a variant thereof) is liked,
we could put a link in the faq entry that points to it.
========================================================================
Ben Reser wrote:
> been using <tt> for that, but I believe <tt> is going away and I'd bet
> we've been inconsistent about that.
"<tt> is not supported in HTML5. Defines teletype text."
(http://www.w3schools.com/tags/default.asp)
I could attempt to find-replace. There are 2559 instances, including
page translations -- would any commiter like to make that change?
Re: [PATCH] Re: Diff Project compilation problem
Posted by Ben Reser <be...@reser.org>.
On Thu, Jan 10, 2013 at 2:24 PM, Gabriela Gibson
<ga...@gmail.com> wrote:
> I was testing whether the current tarball (subversion-1.7.8.tar.gz) is
> affected by the wrong-lib-linking compilation issue, and I discovered
> that zlib.net no longer offers a direct download of the zlib version
> in the get-deps.sh script, so, get-dept.sh no longer fetches the zlib
> that is needed.
>
> Also, the current version of zlib appears to be at version 1.2.7,
>
> Not sure if this is expected behaviour. I haven't been able to find
> a direct download link for zlib-1.2.5 on the zlib site, but I've found
> a link on a mirror:
>
> http://ftp.heanet.ie/pub/download.sourceforge.net/pub/sourceforge/l/li/libpng/zlib/1.2.5/zlib-1.2.5.tar.gz
Two issues here:
1) ZLIB doesn't have a consistent place for downloading any version.
Which means we need to pay attention to this.
2) Our release procedures doesn't have us testing get-deps.sh and
since we as devs don't use it very often it gets missed.
I've updated the release procedures to include a check for get-deps.sh now.
Re: [PATCH] Re: Diff Project compilation problem
Posted by Ben Reser <be...@reser.org>.
On Thu, Jan 10, 2013 at 3:19 PM, Branko Čibej <br...@wandisco.com> wrote:
> Looks like we'll have to get-deps.sh on the 1.7.x branch for the next
> 1.7 release, then. Care to file an issue about this, tagged with the
> 1.7.9 milestone?
r1352031 nominated for backport in the 1.7.x STATUS.
Re: [PATCH] Re: Diff Project compilation problem
Posted by Branko Čibej <br...@wandisco.com>.
On 10.01.2013 23:24, Gabriela Gibson wrote:
> On 10/01/13 03:55, Daniel Shahaf wrote:
>
>> Is this section applicable to tarball builds (which don't use
>> autogen.sh) too?
>
> I'm worming my way through the list (more to come) but have
> encountered the following issue:
>
> I was testing whether the current tarball (subversion-1.7.8.tar.gz) is
> affected by the wrong-lib-linking compilation issue, and I discovered
> that zlib.net no longer offers a direct download of the zlib version
> in the get-deps.sh script, so, get-dept.sh no longer fetches the zlib
> that is needed.
>
> Also, the current version of zlib appears to be at version 1.2.7,
>
> Not sure if this is expected behaviour. I haven't been able to find
> a direct download link for zlib-1.2.5 on the zlib site, but I've found
> a link on a mirror:
>
> http://ftp.heanet.ie/pub/download.sourceforge.net/pub/sourceforge/l/li/libpng/zlib/1.2.5/zlib-1.2.5.tar.gz
>
Looks like we'll have to get-deps.sh on the 1.7.x branch for the next
1.7 release, then. Care to file an issue about this, tagged with the
1.7.9 milestone?
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: [PATCH] Re: Diff Project compilation problem
Posted by Gabriela Gibson <ga...@gmail.com>.
On 10/01/13 03:55, Daniel Shahaf wrote:
> Is this section applicable to tarball builds (which don't use
> autogen.sh) too?
I'm worming my way through the list (more to come) but have encountered
the following issue:
I was testing whether the current tarball (subversion-1.7.8.tar.gz) is
affected by the wrong-lib-linking compilation issue, and I discovered
that zlib.net no longer offers a direct download of the zlib version
in the get-deps.sh script, so, get-dept.sh no longer fetches the zlib
that is needed.
Also, the current version of zlib appears to be at version 1.2.7,
Not sure if this is expected behaviour. I haven't been able to find
a direct download link for zlib-1.2.5 on the zlib site, but I've found
a link on a mirror:
http://ftp.heanet.ie/pub/download.sourceforge.net/pub/sourceforge/l/li/libpng/zlib/1.2.5/zlib-1.2.5.tar.gz
Re: [PATCH] Re: Diff Project compilation problem
Posted by Daniel Shahaf <da...@elego.de>.
Gabriela Gibson wrote on Thu, Jan 10, 2013 at 00:15:29 +0000:
> I thought that the solutions to this question might be useful to have in
> the faq.html.
> +<p>There are a couple of frequent causes of this kind of problem:</p>
> +
> +<p>1. You could be linking about your own installed libraries.</p>
It would be useful to quote the error message.
Is this section applicable to tarball builds (which don't use
autogen.sh) too?
How does this compare to the HACKING (docs/community-guide/) section
containing Karl's "voice of experience" email? Should they
crossreference each other?
> +<p>Workaround 1: Remove them.</p>
> +<p>Workaround 2: <code>"./configure --prefix=/usr/vladivostock ## Doesn't exist"</code></p>
> +
> +<p>2. You may have run <code>"svn up"</code> so that your build system is now stale:</p>
> +<p>Rerun <code>"./autogen.sh; make"</code> or <code>"./autogen.sh; ./configure; make"</code>.</p>
It would be useful to explain why this happens or what needs to be run
when. IIRC the permutations are: if Makefile.in changed, re-run
configure to regenerate Makefile; if configure.ac or build/ac-macros/
changed, rerun autogen.sh to regenerate configure (then run configure);
if build.conf or build/gen-make/ changed, run ./gen-make.py (which is
normally invoked by autogen.sh) to regenerate build-outputs.mk.
> +</div>
> +
> +
> <div class="h2" id="references">
> <h2>References:
> <a class="sectionlink" href="#references"
Re: [PATCH] Re: Diff Project compilation problem
Posted by Ben Reser <be...@reser.org>.
On Wed, Jan 9, 2013 at 4:15 PM, Gabriela Gibson
<ga...@gmail.com> wrote:
> I thought that the solutions to this question might be useful to have in the
> faq.html.
> +<p>1. You could be linking about your own installed libraries.</p>
Think you mean "You could be linking to your own installed libraries."
I'd probably flush this out a little section out a tad more.
> +<p>Rerun <code>"./autogen.sh; make"</code> or <code>"./autogen.sh; ./configure; make"</code>.</p>
Not sure if <code> is the right tag for command lines, think we've
been using <tt> for that, but I believe <tt> is going away and I'd bet
we've been inconsistent about that.
I'd probably say:
./autogen.sh; ./config.nice; make
config.nice is a script that configure writes after each run so you
can re-run configure with the same arguments, if you want to add
argument just pass it to config.nice.
[PATCH] Re: Diff Project compilation problem
Posted by Gabriela Gibson <ga...@gmail.com>.
I thought that the solutions to this question might be useful to have in
the faq.html.
Re: Diff Project compilation problem
Posted by Philip Martin <ph...@wandisco.com>.
Gabriela Gibson <ga...@gmail.com> writes:
> cd subversion/svnmucc && /bin/bash /home/g/trunk/libtool --tag=CC --silent --mode=link gcc -g3 -fno-omit-frame-pointer -fno-inline -Wall -Wmiss\
> ing-prototypes -Wstrict-prototypes -Wmissing-declarations -pthread -DSVN_DEBUG -DAP_DEBUG -rpath /usr/local/lib -o svnmucc svnmucc.lo ../.\
> ./subversion/libsvn_client/libsvn_client-1.la ../../subversion/libsvn_ra/libsvn_ra-1.la ../../subversion/libsvn_subr/libsvn_subr-1.la ../../subv\
> ersion/libsvn_delta/libsvn_delta-1.la -L/home/g/trunk/apr-util -laprutil-1 -L/home/g/trunk/apr -lapr-1
> ../../subversion/libsvn_client/.libs/libsvn_client-1.so: undefined reference to `svn_wc__get_wcroot'
> ../../subversion/libsvn_client/.libs/libsvn_client-1.so: undefined reference to `svn_wc_add_from_disk2'
> collect2: ld returned 1 exit status
> make: *** [subversion/svnmucc/svnmucc] Error 1
>From the rpath it looks like you are using the default --prefix of
/usr/local so the problem is probably that you have older Subversion
libraries installed in /usr/local/lib and the link is erroneously
picking up those libraries instead of the one in your build. If you
remove the Subversion libraries from /usr/local/lib the link will
probably work.
Having to remove the installed libraries is obviously inconvenient,
particularly as they may well be the libraries that you are using. The
way I work around this problem is that I do all my development using a
prefix that doesn't exist:
./configure --prefix=/usr/local/subversionx ...
which solves the linking problem. I never install this build so
/usr/local/subversionx/lib never exists. When I want to install a build
of Subversion I reconfigure and rebuild using the correct prefix (and at
this stage I may need to remove the Subversion libraries in the prefix
to get it to link).
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download