search

TheIceyWolf / shellinabox

Automatically exported from code.google.com/p/shellinabox
Other
0 stars 0 forks source link

Build after svn update seems to fail #20

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?

Check out an old version, build, then update and attempt to rebuild.

1. svn co -r 136 http://shellinabox.googlecode.com/svn/trunk/
shellinabox-from-svn
2. cd shellinabox-from-svn/
3. ./configure
4. make # (works)
5. svn update
6. ./configure # (optional)
7. make

Transcript attached, but the critical bit is pasted below too:

make[1]: Entering directory `/home/tony/shellinabox-from-svn'
/bin/sh ./libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I.    -g
-std=gnu99 -Wall -Os -MT hashmap.lo -MD -MP -MF .deps/hashmap.Tpo -c -o
hashmap.lo `test -f 'libhttp/hashmap.c' || echo './'`libhttp/hashmap.c
./libtool: line 467: CDPATH: command not found
./libtool: line 1145: func_opt_split: command not found
libtool: Version mismatch error.  This is libtool 2.2.6 Debian-2.2.6a-4,
but the
libtool: definition of this LT_INIT comes from an older release.
libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6
Debian-2.2.6a-4
libtool: and run autoconf again.
make[1]: *** [hashmap.lo] Error 63
make[1]: Leaving directory `/home/tony/shellinabox-from-svn'
make: *** [all] Error 2

What is the expected output? What do you see instead?

A successful build

What version of the product are you using? On what operating system?

Debian Lenny, amd64, virtualised under OpenVZ

Please provide any additional information below.

Original issue reported on code.google.com by gnute...@gmail.com on 8 Jul 2009 at 11:13

Attachments:

GoogleCodeExporter commented 8 years ago 
Can you check whether 'svn st' shows any files as having conflicts? That would
certainly explain this behavior.

Most likely, you will need to either delete the conflicting files from your 
system
and then get them again from SVN. Or, alternatively, you could do what the error
message tells you. Delete 'aclocal.m4' and run 'libtoolize' and 'autoreconf'.

I have just submitted a change to SVN that might fix this issue in the future. 
But I
am not 100% sure it will.

Things are optimized for users who either download the tar balls, or who do a 
fresh
checkout from SVN, and who do not want to know about the details of using 
autotools.
This would be the majority of my users.

Unfortunately, this puts those users at a small disadvantage, who like you want 
to
track development with 'svn update'. You might have to actually learn about how 
to
use autotools (or use the exact same version that I use).

I am trying to strike a reasonable compromise here, but it is hard to 
accommodate
these too very different use cases. Let me know, if the new change in SVN makes
things better going forward.

Alternatively, I could check in a script that you could run instead of running 
'svn
update'. Maybe, that's a reasonable approach?

Original comment by zod...@gmail.com on 8 Jul 2009 at 5:39

GoogleCodeExporter commented 8 years ago 
I now added an "update" script. Try running that instead of running "svn 
update".

Original comment by zod...@gmail.com on 8 Jul 2009 at 8:34