From: Brian D. <br...@de...> - 2006-11-03 02:22:58
|
Sisyphus wrote: > I often use the Windows Search utility to find and open files that I want to > peruse - so I search F:\libssh2-0.14 for 'libssh2_config.h' and it turns up > a file that *clearly* shows that the iovec structure is defined. Of course > what I didn't realise was that I was looking at win32/libssh2_config.h ... > not include/libssh2_config.h (which is the file I *thought* I was looking > at). > > Until a few days back the Windows search used to display the path to any > files that were found - but for some reason it's now decided to provide only > the file *name* - which means I don't see multiple occurrences of files with > the same name. I think I had better rectify this before I waste more hours > thinking I'm going mad. I find that in the results page of a Explorer file search there are two columns, "Name" which is the base-filename only, and "In Folder" which contains the path where the file was found. This is with the view set to 'Details', which is the only one I ever use. However, for searching source code I much prefer to use standard command line tools. The one I use most often I have compacted into a shell function that I call srcgrep, which looks as follows: allgrep () { find . \( -type d -a \( -name .svn -o -name CVS \) -a -prune \) \ -o \( -type f -a -print0 \) | xargs -0 grep -Pin -U5 "$1" \ | less "+/$1" } This searches all files under the current directory for a RE string given as the first argument. It uses "grep -P" which means PCRE in the grep that I use, which is the RE-flavor I prefer. It also prunes (i.e. skips) CVS and Subversion cruft, which eliminates false positives. And it automatically gives 5 lines of context (-U5), line numbers (-n), and highlighting of hits (though less's "/"-search). I find this to be infinitely more useful than just a standard grep. I also have a variant that searches just source files, which I have named "srcgrep": srcgrep () { perl -e ' my @exts = qw/c cc h hpp s i ii asm java php properties txt 1 am in y/; my @ignoredirs = qw/.svn CVS/; my @args = qw/. ( -type d -a (/; push @args, ("-name", "$_", "-o") foreach @ignoredirs; pop @args if($args[-1] eq "-o"); push @args, qw/) -a -prune ) -o ( -type f -a (/; push @args, ("-iname", "*.$_", "-o") foreach @exts; pop @args if($args[-1] eq "-o"); push @args, qw/) -a -print0 )/; print join("\0", @args); ' | xargs -0 find | xargs -0 grep -Pin -U5 "$1" | less "+/$1" } This uses perl just for ease of maintaining the 'find' expression (i.e. you can just add or remove extensions from the list), but is otherwise the same idea as above. > Once I realised that, it was just a matter of including > win32/libssh2_config.h and taking care of the fact that ENOTCONN is not > defined in the MinGW headers (though it's defined to WSAENOTCONN somewhere > in the MSVC headers). That gets me all the way through to linking w32api has WSAENOTCONN too. > when trying to build libssh2.so ('.so' ... wtf ?) from all of the > successfully compiled object files. Linking in a few additional libraries I > can build a shared libssh2.dll by running: The fact that it tries to create a shared library named .so indicates a deficiency in the configure script. As you can see, it's decided on a case-by-case basis based on host type: case "$host" in *-cygwin) SHLIB_SUFFIX_NAME="dll" SHLIB_LDFLAGS="-shared" CFLAGS="$CFLAGS -DLIBSSH2_WIN32" ;; *darwin*) SHLIB_SUFFIX_NAME="dylib" SHLIB_LDFLAGS="-dynamiclib -flat_namespace" CFLAGS="$CFLAGS -DLIBSSH2_DARWIN" ;; *hpux*) SHLIB_SUFFIX_NAME="sl" SHLIB_LDFLAGS="-b +vnocompatwarnings -L/lib/pa20_64" LDCC="ld" ;; *) SHLIB_SUFFIX_NAME="so" SHLIB_LDFLAGS="-shared" ;; esac ...and the author was aware of Cygwin but not aware of MinGW. This is the kind of reason why I was disappointed that it did not include the actual source files needed to regenerate the configure script, because crap scripts like this really need to be fixed but it's impossible without the configure.ac. OT: It's junk like this that makes me wish people would use tools like automake and libtool more often. If they did that instead of trying to write these files by hand, there would be no mucking about with special casing of host types, or having to manually build static libraries. You could just run "./configure --disable-shared --enable-static" on any host in the known world and it would Just Work. You'd also get a Makefile that supports all the standard features of the GNU coding standards, like DESTDIR, vpath, distcheck, and so on... Instead everybody thinks they know enough to "just do it by hand" but in 99% of cases they don't. But that's a rant that is for another place and time. > but I would prefer a static library. When I replace the > 'libssh2.dll -shared" in the above command with "libssh2.a" I get: > > Rob@DESKTOP /f/libssh2-0.14/src > $ gcc -o libssh2.a channel.o comp.o crypt.o hostkey.o kex.o mac.o misc.o > packet.o publickey.o scp.o session.o sftp.o > serauth.o -L/f/openssl/openssl-0.9.8d/lib -lssl -lcrypto -L/d/MSYS/local/li > b -lz -lws2_32 -lgdi32 That is not how you create a static library. Here you are actually trying to compile a binary .exe (one that is erroniously given a filename ending in .a), and thus the error about missing WinMain(). To create a static archive you do not use gcc or ld, you use ar, because static archives are just that, archives of .o files that have not been linked. Brian |