On Mon, 2004-01-26 at 12:18, Trevor Smith wrote: > > For example, I'm desperately trying to get *any* gnutella client to run on > this machine so I don't have to boot to Windows for bearshare. Should be > simple, right? I tried mutella but running the 'make' step generates errors > including: > > [...] > g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/local/include -D_REENTRANT > -D_MIT_POSIX_THREADS -fno-exceptions -fno-check-new -g -O0 -c -o gnushare.o > `test -f 'gnushare.cpp' || echo './'`gnushare.cpp > gnushare.cpp: In member function `void MGnuShare::ResetDirectories(long > unsigned int&, u_long*)': > gnushare.cpp:220: error: `assert' undeclared (first use this function) > gnushare.cpp:220: error: (Each undeclared identifier is reported only once > for each function it appears in.) I get the same. You should notify the author. > ... > > But at step 3 I get: > > [trevor@localhost qtella-0.6.4]$ ./configure > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > /home/trevor/qtella-0.6.4/missing: Unknown `--run' option > Try `/home/trevor/qtella-0.6.4/missing --help' for more information > configure: WARNING: `missing' script is too old or missing > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for g++... g++ > checking for C++ compiler default output file name... a.out > checking whether the C++ compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking for style of include used by make... GNU > checking dependency style of g++... gcc3 > checking for gcc... gcc > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking dependency style of gcc... gcc3 > checking for a BSD-compatible install... /usr/bin/install -c > checking for Qt moc... > Qt's moc not found! If you have installed Qt in an > unusual place, please use the "--with-qt-moc=" option You can work through the "configure" script, approx line 3546 onwards, to find why this test is failing on your system. It will most likely be due to your newer Qt - I do not get this error on my FC1 system. Qtella builds and runs fine. > > So obviously "all I need" is not what is claimed. :-( It's sometimes hard for a package maintainer to guarantee their code will build with all future versions of dependencies. > > One caveat: I did upgrade to the new KDE beta release so I have some newer > version of Qt on my system I think. > > 1. Should someone without system-level programming experience on linux ever > attempt to compile software? It is certainly incomprehensible to me and any > error stops me dead in the water. The info generated never enlightens me or > gives me any idea how to "fix" the problem of the moment. In this case, the configure script told you there was a problem with Qt. You have installed an upgraded version of Qt. That is a pretty clear signpost. If you rolled back to the previous version of Qt, it is likely to fix this problem. > > 2. Why can a plain vanilla, out of the box FC1 system never successfully > compile any source I ever download? Is there something else I should install > on my system to be able to compile most software out there? Or do I generally > need to become an expert on each individual package I download and try to > install? I find the "./configure; make; make install" process to be generally reliable, but the reliability depends on the stability of the particular package's dependencies. Often packages that use actively developed UI components will be more difficult to get the dependencies right. > > 3. How many years of computer science classes will I realistically need to > attend before I can understand half of what is going on when I try to compile > any non-trivial linux program? I'd strongly suggest you work through the "./configure; make; make install" process for a simple package. Learn about make targets, work through the configure script to get an idea what it is doing. Another practise that can make diagnosing problems easier is to keep a history of all the changes you make to your system. > > frustrated beyond description at all the days I've wasted without any > results. :-( > Nothing worse than burning a lot of time and having nothing to show for it. Hope these suggestions help. Thanks for the question - I know have a p2p client working that I can play with! Cheers, Ben
