Re: 0.2.2.5-alpha doesn't know how to make libtor.a
On Sun, 18 Oct 2009 19:05:28 -0400 Nick Mathewson ni...@freehaven.net
wrote:
On Sun, Oct 18, 2009 at 10:40:44AM -0500, Scott Bennett wrote:
After running './configure CFLAGS=-march=prescott', a 'make' in the
top (tor-0.2.2.5-alpha) directory did the following.
I can't reproduce this; can you say more about your toolchain? What
OS are you getting this on? Whose make are you using, and what
Script started on Mon Oct 19 10:16:24 2009
[hellas] 101 % which make
/usr/bin/make
[hellas] 102 % ls /usr/local/bin/*make
/usr/local/bin/automake@/usr/local/bin/gmake*
/usr/local/bin/ppmmake*
/usr/local/bin/avimake* /usr/local/bin/imake* /usr/local/bin/qmake*
/usr/local/bin/ccmake* /usr/local/bin/kmk_gmake* /usr/local/bin/tmake*
/usr/local/bin/cmake* /usr/local/bin/pbmmake*
[hellas] 103 % ls /usr/local/bin/automake*
/usr/local/bin/automake@ /usr/local/bin/automake-1.8*
/usr/local/bin/automake-1.10*/usr/local/bin/automake-1.9*
/usr/local/bin/automake-1.4* /usr/local/bin/automake-wrapper*
/usr/local/bin/automake-1.6*
[hellas] 104 % ls /usr/local/bin/autoconf*
/usr/local/bin/autoconf@ /usr/local/bin/autoconf-2.62*
/usr/local/bin/autoconf-2.13*/usr/local/bin/autoconf-wrapper*
[hellas] 105 % ls /usr/local/bin/libtool*
/usr/local/bin/libtool* /usr/local/bin/libtoolize*
[hellas] 106 % gmake --version
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
This program built for i386-portbld-freebsd7.2
[hellas] 107 % lsl /usr/local/bin/auto{make,conf}
lrwxr-xr-x 1 root wheel 16 Jun 25 01:59 /usr/local/bin/autoconf@ -
autoconf-wrapper
lrwxr-xr-x 1 root wheel 16 Jun 25 02:00 /usr/local/bin/automake@ -
automake-wrapper
[hellas] 108 % libtool --version
ltmain.sh (GNU libtool) 2.2.6
Written by Gordon Matzigkeit g...@gnu.ai.mit.edu, 1996
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[hellas] 109 % uname -a
FreeBSD hellas 7.2-STABLE FreeBSD 7.2-STABLE #11: Sun Oct 18 09:33:26 CDT 2009
root@:/usr/obj/usr/src/sys/hellas i386
[hellas] 110 % exit
exit
Script done on Mon Oct 19 10:20:25 2009
version? If it isn't gmake, does trying gmake[*] cause the problem to
go away?
I used the FreeBSD 7.2-STABLE make, which was recompiled as part of a
make buildworld, etc. after cvsup-ing to get the latest FreeBSD RELENG_7
updates shortly beforehand. Actually, what prompted the tor-0.2.2.5-alpha
build was the 5000 circuit times bug in 0.2.2.3-alpha, which was hit upon
startup after the make installworld mergemaster reboot sequence that
ends a full update of FreeBSD. So that's what I used to start building tor,
but what was used at the lower levels (e.g., src/{common,or} I don't know.
I assume it was set by the configure script.
Does anything happen if you edit src/or/Makefile.in to replace every
reference to ./libtor.a with one to libtor.a , then run configure
again?
I haven't tried it. I may have a chance to play with it tonight or
tomorrow.
[*] It wasn't our intention to require gmake; but learning that we
broke non-gmake builds would be a good step to diagnosing what's
wrong.
Here are the diffs of src/or/Makefile from 0.2.2.3-alpha to
0.2.2.5-alpha.
18a19
36,37d36
TESTS = test$(EXEEXT)
noinst_PROGRAMS = test$(EXEEXT)
50,53c49,54
am__installdirs = $(DESTDIR)$(bindir)
binPROGRAMS_INSTALL = $(INSTALL_PROGRAM)
PROGRAMS = $(bin_PROGRAMS) $(noinst_PROGRAMS)
am__test_SOURCES_DIST = buffers.c circuitbuild.c circuitlist.c \
---
LIBRARIES = $(noinst_LIBRARIES)
AR = ar
ARFLAGS = cru
libtor_a_AR = $(AR) $(ARFLAGS)
libtor_a_LIBADD =
am__libtor_a_SOURCES_DIST = buffers.c circuitbuild.c circuitlist.c \
60c61
config_codedigest.c test_data.c test.c
---
config_codedigest.c
63c64
am__objects_3 = buffers.$(OBJEXT) circuitbuild.$(OBJEXT) \
---
am_libtor_a_OBJECTS = buffers.$(OBJEXT) circuitbuild.$(OBJEXT) \
76,90c77,81
am_test_OBJECTS = $(am__objects_3) test_data.$(OBJEXT) test.$(OBJEXT)
test_OBJECTS = $(am_test_OBJECTS)
test_DEPENDENCIES = ../common/libor.a ../common/libor-crypto.a \
../common/libor-event.a
test_LINK = $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(test_LDFLAGS) $(LDFLAGS) \
-o $@
am__tor_SOURCES_DIST = buffers.c circuitbuild.c circuitlist.c \
circuituse.c command.c config.c connection.c connection_edge.c \
connection_or.c control.c cpuworker.c directory.c dirserv.c \
dirvote.c dns.c dnsserv.c geoip.c hibernate.c main.c ntmain.c \
networkstatus.c onion.c policies.c reasons.c relay.c \
rendcommon.c rendclient.c rendmid.c rendservice.c rephist.c \
router.c routerlist.c routerparse.c eventdns.c \
config_codedigest.c
Re: any rough stats on bridges ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/19/2009 04:10 PM, John Case wrote: It would be interesting if someone in the know could let us know how many bridges are running ... I'd further be interested in the total number that have been submitted over time, vs. the number that are actually running now ... maybe some rough ideas as to their average bandwidth, etc. My understanding of the protocol leads me to believe that this is benign information. The latest information that I can give you is from June 22: https://www.torproject.org/projects/metrics in particular https://git.torproject.org/checkout/metrics/master/report/bridges/bridges-2009-06-22.pdf Let me know if there's something else you are interested in that could be extracted from the bridge descriptors, and I can include it in the next report. Thanks, - --Karsten -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrctvsACgkQ0M+WPffBEmVsKgCeIBSb9vE93GDAgeTA8s0x3LZn tjgAoKN1qtfYH3Qi8vR+w5HpcXooHgUc =Jzyh -END PGP SIGNATURE- *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: any rough stats on bridges ?
On Mon, 19 Oct 2009, Karsten Loesing wrote: On 10/19/2009 04:10 PM, John Case wrote: It would be interesting if someone in the know could let us know how many bridges are running ... I'd further be interested in the total number that have been submitted over time, vs. the number that are actually running now ... maybe some rough ideas as to their average bandwidth, etc. My understanding of the protocol leads me to believe that this is benign information. The latest information that I can give you is from June 22: https://www.torproject.org/projects/metrics in particular https://git.torproject.org/checkout/metrics/master/report/bridges/bridges-2009-06-22.pdf Let me know if there's something else you are interested in that could be extracted from the bridge descriptors, and I can include it in the next report. Thank you. This was very interesting. I'd like to see some stats, or even some conjecture, as to the longevity of a bridge, and what it means for the bridge to be born, be used, and eventually be blocked. I understand the mechanisms used to slowly feed bridge information to people who request them, but even that slowness can't keep them from eventually being discovered and blocked. I would think there would be some kind of exponential falloff in utility of a bridge as it is extant for longer and longer periods of time. You might be able to analyze this by looking at the relationship between the number of times a bridge IP is given out vs. the bandwidth it generates and then provide some guidelines to bridge operators that would give them an idea as to when to move to a new IP, or when to expect their bridge to have gone stale. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: any rough stats on bridges ?
I'd like to see some stats, or even some conjecture, as to the longevity of a bridge, and what it means for the bridge to be born, be used, and eventually be blocked. I understand the mechanisms used to slowly feed bridge information to people who request them, but even that slowness can't keep them from eventually being discovered and blocked. It seems that a reasonable question might be: for a home user, with a static IP, planning to contribute to Tor, which is most useful: should they just be a bridge; start out as a bridge, and then eventually change to a relay; or immediately sign on as a relay? Given some responses to this, might it make sense to construct a tool to tell people when their bridges should change to relays?
Re: any rough stats on bridges ?
I think that unless you have a good way of telling specific people in the need of a bridge about your bridge without telling the world, that you should not consider being a bridge, -Martin --- On Mon, 10/19/09, Flamsmark flamsm...@gmail.com wrote: From: Flamsmark flamsm...@gmail.com Subject: Re: any rough stats on bridges ? To: or-talk@freehaven.net Date: Monday, October 19, 2009, 4:05 PM I'd like to see some stats, or even some conjecture, as to the longevity of a bridge, and what it means for the bridge to be born, be used, and eventually be blocked. I understand the mechanisms used to slowly feed bridge information to people who request them, but even that slowness can't keep them from eventually being discovered and blocked. It seems that a reasonable question might be: for a home user, with a static IP, planning to contribute to Tor, which is most useful: should they just be a bridge; start out as a bridge, and then eventually change to a relay; or immediately sign on as a relay? Given some responses to this, might it make sense to construct a tool to tell people when their bridges should change to relays? *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: any rough stats on bridges ?
2009/10/19 Martin Fick mogul...@yahoo.com I think that unless you have a good way of telling specific people in the need of a bridge about your bridge without telling the world, that you should not consider being a bridge, Is that a gut feeling, or based on some research? What about the ways that we have of selectively giving bridges to those who need them?
Re: any rough stats on bridges ?
--- On Mon, 10/19/09, Flamsmark flamsm...@gmail.com wrote: I think that unless you have a good way of telling specific people in the need of a bridge about your bridge without telling the world, that you should not consider being a bridge, Is that a gut feeling, or based on some research? What about the ways that we have of selectively giving bridges to those who need them? Neither. If you have a selective way of telling people you deem in the need, than you meet my criteria. It would likely be hard for us all to meet that criteria though, I don't. You may tell me that you can help me, but then I have to trust you, which doesn't really make too much sense. And a general mechanism to do this seems impossible, doesn't it? How can you keep a secret while telling it to the world. Any newcomers to tor who cannot understand the implications of when they should or should not be running a bridge are unlikely to understand the nuances of distributing a secret to those in the need (and by whose criteria are they in need anyway) only. If you have arguments to the contrary, I welcome them and feel that many on this list might benefit from them, because it would be beyond my understanding of the point of bridges, and perhaps other's too? -Martin *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: any rough stats on bridges ?
Neither. If you have a selective way of telling people you deem in the need, than you meet my criteria. It would likely be hard for us all to meet that criteria though, I don't. You may tell me that you can help me, but then I have to trust you, which doesn't really make too much sense. And a general mechanism to do this seems impossible, doesn't it? How can you keep a secret while telling it to the world. Any newcomers to tor who cannot understand the implications of when they should or should not be running a bridge are unlikely to understand the nuances of distributing a secret to those in the need (and by whose criteria are they in need anyway) only. If you have arguments to the contrary, I welcome them and feel that many on this list might benefit from them, because it would be beyond my understanding of the point of bridges, and perhaps other's too? The project currently has a method of distributing bridges to anyone who asks. Individual requesters are given only a select number of addresses. If a 'clueless' user sets their tor as a bridge, their bridge gets added to the (secret) bridge directory, and handed out from time to time.. Please see https://www.torproject.org/bridges for more information.
