Bug#529908: Upstream Fix

2009-11-05 Thread Robert Hogan
Hi there,

After upgrading to Karmic Koala I'm now getting this same error.

However, I can build with --with-external-torsocks.

Short of developing a magic wand to fix whatever it is libtool is doing 
wrong, I don't see a way of fixing this.

One way out of this is to package torsocks separately 
(http://code.google.com/p/torsocks) and I can update tork to rely on its 
presence (rather than including it in the source).

If this is satisfactory I can make the appropriate changes.

Thanks,
Robert

On Sunday 25 October 2009 15:01:38 Patrick Matthäi wrote:
 Andreas Metzler schrieb:
  On 2009-10-19 Robert Hogan rob...@roberthogan.net wrote:
  Is there any way the reporter or an interested packager could check
  the fix for this in upstream CVS:
 
  http://sourceforge.net/mailarchive/message.php?msg_name=E1MLhzT-a
 q...@ddv4jf1.ch3.sourceforge.com
 
  Once validated, I can perform a release - or alternatively the patch
  can be applied to the tork package.
 
  Hello,
 
  I think that generally the fix is correct.
 
  However I do not seem to able to make *any* changes to the build
  system and getting a compileable setup.
 
  Even a simple
  make -f Makefile.cvs ; ./configure ; make
  fails with
 
 Hello,
 
 yes I talked to Robert in private the last days and I have got exactly
 the same error, he is working on it.
 
  if /bin/bash ../../libtool --silent --tag=CC --mode=compile gcc
  -DHAVE_CONFIG_H -I. -I. -I../..   -DQT_THREAD_SUPPORT  -D_REENTRANT 
  -Wall -MT dead_pool.lo -MD -MP -MF .deps/dead_pool.Tpo -c -o
  dead_pool.lo dead_pool.c; \ then mv -f .deps/dead_pool.Tpo
  .deps/dead_pool.Plo; else rm -f .deps/dead_pool.Tpo; exit 1; fi
  /bin/bash ../../libtool --silent --tag=CC --mode=link gcc  -Wall   -o
  libtorksocks.la -rpath /usr/lib/tork -version-info 1:0:0 tsocks.lo
  common.lo parser.lo dead_pool.lo  -ldl gcc: libtorksocks.so.1: No such
  file or directory
  gcc: unrecognized option '-soname'
  make[3]: *** [libtorksocks.la] Error 1
  make[3]: Leaving directory `/tmp/TORK/tork-0.31/src/tsocks'
  make[2]: *** [all-recursive] Error 1
  make[2]: Leaving directory `/tmp/TORK/tork-0.31/src'
  make[1]: *** [all-recursive] Error 1
  make[1]: Leaving directory `/tmp/TORK/tork-0.31'
  make: *** [all] Error 2
 
  I think this is caused by mixing old ltmain.sh in ./admin with new
  libtool.m4 in /usr/share/ or something like that. The aclocal run
  triggered by make -f Makefile.cvs throws loads of errors and warnings:
  SID)ametz...@argenau:/tmp/TORK/tork-0.31$ make -f Makefile.cvs
  This Makefile is only for the CVS repository
  This will be deleted before making the distribution
 
  *** automake (GNU automake) 1.9.6 found.
  *** Creating acinclude.m4
  make[2]: Entering directory `/tmp/TORK/tork-0.31'
  make[2]: Leaving directory `/tmp/TORK/tork-0.31'
  *** Creating list of subdirectories
  make[2]: Entering directory `/tmp/TORK/tork-0.31'
  cd .  make -f admin/Makefile.common subdirs
  make[3]: Entering directory `/tmp/TORK/tork-0.31'
  make[3]: Leaving directory `/tmp/TORK/tork-0.31'
  make[2]: Leaving directory `/tmp/TORK/tork-0.31'
  *** Creating configure.files
  *** Creating configure.in
  make[2]: Entering directory `/tmp/TORK/tork-0.31'
  cd .  make -f admin/Makefile.common configure.in ;
  make[3]: Entering directory `/tmp/TORK/tork-0.31'
  make[3]: Leaving directory `/tmp/TORK/tork-0.31'
  make[2]: Leaving directory `/tmp/TORK/tork-0.31'
  *** Creating aclocal.m4
  configure.in:51: warning: AC_REQUIRE: `AC_PROG_CC' was expanded before
  it was required ../../lib/autoconf/c.m4:433: AC_LANG_COMPILER(C) is
  expanded from... ../../lib/autoconf/lang.m4:315:
  AC_LANG_COMPILER_REQUIRE is expanded from...
  ../../lib/autoconf/general.m4:2593: AC_COMPILE_IFELSE is expanded
  from... ../../lib/autoconf/general.m4:2601: AC_TRY_COMPILE is expanded
  from... acinclude.m4:2978: KDE_CHECK_FOR_BAD_COMPILER is expanded
  from... acinclude.m4:3059: AC_CHECK_COMPILERS is expanded from...
  configure.in:51: the top level
  configure.in:51: warning: AC_REQUIRE: `AC_PROG_CXX' was expanded
  before it was required ../../lib/autoconf/c.m4:671:
  AC_LANG_COMPILER(C++) is expanded from...
  ../../lib/autoconf/general.m4:2665: AC_LINK_IFELSE is expanded from...
  ../../lib/autoconf/general.m4:2674: AC_TRY_LINK is expanded from...
  ../../lib/m4sugar/m4sh.m4:620: AS_IF is expanded from...
  ../../lib/autoconf/general.m4:2018: AC_CACHE_VAL is expanded from...
  acinclude.m4:2903: KDE_CHECK_COMPILER_FLAG is expanded from...
  configure.in:54: warning: AC_REQUIRE: `AC_OBJEXT' was expanded before
  it was required acinclude.m4:6067: AC_LIBTOOL_SETUP is expanded
  from...
  acinclude.m4:6047: _AC_PROG_LIBTOOL is expanded from...
  acinclude.m4:6012: AC_PROG_LIBTOOL is expanded from...
  acinclude.m4:11781: AM_PROG_LIBTOOL is expanded from...
  acinclude.m4:3472: KDE_PROG_LIBTOOL is expanded from...
  configure.in:54: the top level
  configure.in:54: warning: AC_REQUIRE: `AC_EXEEXT' was expanded before
  it was required

Bug#529908: Upstream Fix

2009-10-25 Thread Robert Hogan
On Sunday 25 October 2009 14:18:07 Andreas Metzler wrote:
 I think this is caused by mixing old ltmain.sh in ./admin with new
 libtool.m4 in /usr/share/ or something like that. 

Interesting, I tried libtoolize to no avail  - it just broke the build even 
further.

I checked the admin folder in the kde-common module in the KDE 3.5 SVN repo 
and it as old as mine.

Any ideas on what to do/try out to remedy this? (Other than hand-edit the 
admin folder!)

 The aclocal run
 triggered by make -f Makefile.cvs throws loads of errors and warnings:
 

I think these are a red herring. I get them too and I can still build fine.



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#529908: Upstream Fix

2009-10-19 Thread Robert Hogan
Is there any way the reporter or an interested packager could check the fix 
for this in upstream CVS:

http://sourceforge.net/mailarchive/message.php?msg_name=e1mlhzt-aq...@ddv4jf1.ch3.sourceforge.com

Once validated, I can perform a release - or alternatively the patch can be 
applied to the tork package.



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org