- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev] configure problems

by Jorge Arellano Cid

Jan, > Hi, > > this is what I get with the current CVS (viz later). > > I know that I don't have libpng, libjpeg etc installed > (by mistake, I was compiling on machine without them), > but I mean the 'usability ... yes ; presence ... no' problem. > Is this an autoconf bug, or is configure.in written badly ? Our configure.in tests libpng and libjpeg, and it SHOULD abort if those aren't present, _but_ as dillo doesn't have support for running without images in a clean way --it will in the near future (not in 0.7.0 though)--, so we left configure.in as it is now. Ah, the libjpeg test is done badly too... We need an autconf/automake savvy person since a long time! :) Cheers Jorge.- PS: The other errors are not our fault.

Feb. 5, 2003

configure problems

by Jan Stary

Hi, this is what I get with the current CVS (viz later). I know that I don't have libpng, libjpeg etc installed (by mistake, I was compiling on machine without them), but I mean the 'usability ... yes ; presence ... no' problem. Is this an autoconf bug, or is configure.in written badly ? The system is: Debian unstable kernel 2.4.19 (self compiled) autoconf 2.57 automake 1.6.3 gcc/cpp 3.2.2 The results follow. Jan cvs co dillo && cd dillo ./autogen.sh ./configure --prefix=$HOME checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for gcc... gcc checking for C compiler default output... 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 gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking for gcc option to accept ANSI C... none needed checking for ranlib... ranlib checking for gtk-config... /usr/bin/gtk-config checking for GTK - version >= 1.2.0... yes checking for jpeg_destroy_decompress in -ljpeg... no configure: WARNING: *** JPEG support will not be included *** checking for pthread_create in -lpthread... yes checking for zlibVersion in -lz... no checking for png_check_sig in -lpng... no checking for ANSI C header files... no checking fcntl.h usability... yes checking fcntl.h presence... no configure: WARNING: fcntl.h: accepted by the compiler, rejected by the preprocessor! configure: WARNING: fcntl.h: proceeding with the preprocessor's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to bug-autoconf(a)gnu.org. ## configure: WARNING: ## ------------------------------------ ## checking for fcntl.h... no checking unistd.h usability... yes checking unistd.h presence... no configure: WARNING: unistd.h: accepted by the compiler, rejected by the preprocessor! configure: WARNING: unistd.h: proceeding with the preprocessor's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to bug-autoconf(a)gnu.org. ## configure: WARNING: ## ------------------------------------ ## checking for unistd.h... no checking sys/uio.h usability... yes checking sys/uio.h presence... no configure: WARNING: sys/uio.h: accepted by the compiler, rejected by the preprocessor! configure: WARNING: sys/uio.h: proceeding with the preprocessor's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to bug-autoconf(a)gnu.org. ## configure: WARNING: ## ------------------------------------ ## checking for sys/uio.h... no checking for socket... yes configure: creating ./config.status config.status: creating Makefile config.status: creating doc/Makefile config.status: creating src/Makefile config.status: creating src/IO/Makefile config.status: creating config.h config.status: executing depfiles commands

Feb. 5, 2003

Re: [Dillo-dev] autoconf/automake stuff in CVS

by Nicola Girardi

> > This list seems OK to me. Thanks Jorge. > > Are you savvy on autoconf/automake stuff? Not really. :-) I only know which files need to be around and which ones don't, and the list seemed OK. I wrote because I was among the ones who asked you to remove those files and I'm happy that you did.

Feb. 4, 2003

Re: [Dillo-dev] autoconf/automake stuff in CVS

by Jorge Arellano Cid

On Tue, 4 Feb 2003, Patrick Shanahan wrote: > > > Built ok on SuSE 8.1, i586(686), but lost bookmarks access. Did I miss > > > this being mentioned earlier? > > > > What do you mean by "lost bookmarks access"? > > There are no longer any bookmarks from the drop-down menu. There is a > bookmarks.html file in ~/.dillo but dillo is unable to access it. Also > saving a bookmark does not work ??? Go to the [CVS] link and RTFM. Jorge.-

Feb. 4, 2003

Re: [Dillo-dev] autoconf/automake stuff in CVS

by Patrick Shanahan

* Jorge Arellano Cid <jcid(a)softhome.net> [02-04-03 00:49]: > > Patrick, > > > * Jorge Arellano Cid <jcid(a)softhome.net> [02-02-03 17:00]: > > > > > > and wrote a simple autogen.sh script to remake them. > > > > > > Now you'll need autoconf and automake installed. > > > > Built ok on SuSE 8.1, i586(686), but lost bookmarks access. Did I miss > > this being mentioned earlier? > > What do you mean by "lost bookmarks access"? There are no longer any bookmarks from the drop-down menu. There is a bookmarks.html file in ~/.dillo but dillo is unable to access it. Also saving a bookmark does not work ??? I did checkout on the cvs at the new address and the build 02-02-03 @ 11:10pm EST (-5 hrs). -- Patrick Shanahan http://wahoo.no-ip.org Registered Linux User #207535 icq#173753138 @ http://counter.li.org

Feb. 4, 2003

Re: [Dillo-dev] Very close to a new release!

by Jorge Arellano Cid

Micah, > > Note: the new bookmarks server tarball has a short program and > > instructions to test permissions on *BSD machines. Someone please > > give it a try. > > I'm using NetBSD 1.6. First, some GNUisms: Autogen.sh > starts '#!/bin/bash' when /bin/sh works just fine. Convert > in the dpi tarball has the same problem. I'll fix that. > Also, Makefile.am > uses the GNU-specific '--backups=t' option to install. > A '-b' will make both GNU and BSD install make backups > according to their default scheme. If simple backups > are enough (why not?) then that's fine. Otherwise, you > may have to resort to some configure trickery to decide > whether to use '--backups=t' or '-b -B ".%d"' or some such. > Other that that, it works great. Is just a matter of 's/--backups=t/-b/' ? As I'm not an expert on this area, I'd appreciate a patch! > The socket test gives 'Permission denied' like it should. Good! OpenBSD and NetBSD are OK, I only need a FreeBSD test now! > Thanks for all your work! You're welcome Cheers Jorge.-

Feb. 4, 2003

Re: [Dillo-dev] Very close to a new release!

by Jorge Arellano Cid

Andreas, > > The point is: testing it. Sadly I didn't received more than a > > single comment of its working. Now I'm asking again: please > > download the latest CVS, the bookmarks server, intall them, play > > with them, test and report how it works for you. > > With the CVS verion as of > > $ date -u > Mon Feb 3 16:38:33 UTC 2003 > > It works almost out of the box for FreeBSD (the latest stable) > The only thing : autogen.sh should be a /bin/sh script, > not a /bin/bash script to make it portable. > > Same for the small convert script for the bm_dpi. > I'll change those. > > Ah, if someone here has NFS mounted accounts (from another > > machine), I want to know how it works there. As unix domain > > sockets are accessible only to the local machine, and it listens > > on /tmp, it should work, but we need the proof! > > The NFS part works between 2 FreeBSD machines. Thanks for testing. May I bother you with the socket access test? > There is just one problem : dillo waits 128 cycles for > the plugin to get online. > On my machine, this seems to be not long enough. I > set it to 256, and then it says it waits 90-190 cycles to get > online ... weird ... and then it works. > Maybe this hard coded waiting is not such a great idea. Yes. The problem is the time gap between 'exec' and the dpi-program being operative. It should be minimal when the programs is on a local HD, but NFS may take some time. I added the wait cycles for this case, and don't know the "canonical" way to do it. Yes it could be done with a gtk-timeout function or something akin but the wait cycles were the simplest thing to begin with. ;) Cheers Jorge.-

Feb. 4, 2003

Re: [Dillo-dev] Very close to a new release!

by Jorge Arellano Cid

On Mon, 3 Feb 2003, TheStar wrote: > > > > > Note to all/self: Dillo will *not* work with autoconf-2.13. > > > > > > Please test our latest CVS. It should work with the old autoconf. > > > > Works fine now, thanks. :) I've been using 0.7.0-pre since last night; > > it works beautifully so far. Can't wait for the release! > > > > Same here, although I'd much prefer having the plugins in some generic place > such as /usr/share/dillo so that I don't have to make sure that each user has > the correct plugin, etc... (Can I do that already?) You can place them anywhere in your PATH or in ~/.dillo/ > I'd also _really_ like to have a "open link with..." dialog/menu/etc... ;) Dpi is the gateway to those extensions. > Great job, Once the cut & paste and downloading are finished, it will > be better than the graphical links! Thanks. Cheers Jorge.-

Feb. 4, 2003

Re: [Dillo-dev] Very close to a new release!

by Jorge Arellano Cid

Livio, > Hello there! > > I have tested today's CVS + DPI bookmarks and things seem very well! Good! Did you use `convert` or started from scratch? Or wrote a simple script to import from elsewhere? :) > Jorge Arellano Cid writes: > > [...] > > > With respect to staying alive, I also think it should end after > > closing dillo. Maybe sending a termination request at exit time > > could work fine, but I need some time to think about it... > > One small suggestion is that this termination be dealt with unix > signals. I don't see clearly what are the advantages of using sockets > for DPI's over pipes (expect running the server and the browser > in different machines, but... is that useful?). Sockets are two-way channels and, BTW, unix domain sockets allow access from the local machine only... > Anyway, since we're > using unix domain sockets, I'll assume we are local users only, and > I'll also assume that signals are ok. > > The advantage of using signals for termination (instead of a > "proper" DPI request) is that anyone can "safely" terminate a specific > server. If Dillo crashes, or if it is buggy the server may dangle > alive. But if you (Dillo or a user) kill with -TERM, we can have the > servers set up the termination code inside the -TERM signal handler, > and hence free it's resources correctly (unsaved files, opened ftp > connections, etc.). I understand. BTW, bm_srv12 has a SIGTERM handler (just in case the server is killed or brought down with Ctrl-C). The problem is that dillo should keep track of the process ID of each server (and those can be taken down and re-launched without dillo's intervention). As you see, both schemes have some glitches; if you find an easy way to deliver the signals, I'd be all for it. Cheers Jorge.-

Feb. 4, 2003

Re: [Dillo-dev] Very close to a new release!

by Melvin Hadasht

[Sorry for the incomplete previous message] Hi Melvin, on Mon, 3 Feb 2003 19:38:25 +0100 Melvin Hadasht <melvin.hadasht(a)free.fr> wrote: > > My `info libc` didn't mention an explicit need to do that > > (except for getsockopt and getsockname); BUT the example > > initialized the one for accept!!! According to my "man accept" page, the length "should" be initialised (at least if addr is not NULL) The same source indicates that the addrlen should contain the allocated size of the structure pointed by addr (or more precisely, the sizeof() that structure). In the case of struct sockaddr_un, that size is 110, where 2 bytes are for the sa_family_t and 108 for the char array that holds the name. It seems the length is used to check if the function will not do a buffer overflow when filling it. accept() will then update the addrlen to inform the caller about the real length of the client info. In case of a Unix socket, it seems that it is used (but the string sun_path is of zero length), hence addrlen is returned with the value 2. In our case, as the client address is not used, we could just use NULL for both addr and addrlen. Anyway, in our case, libc info does not say that addrlen need to be initialized if addr is not NULL. > > Well this isn't too surprising as the same source explains two > > equivalent ways to calculate the size of the address, and when > > tested they are different! :) Concerning the SUN_LEN, the formula you used takes into account the trailing NUL byte of the string, which is wrong according to info libc: "You should compute the LENGTH parameter for a socket address in the local namespace as the sum of the size of the `sun_family' component and the string length (_not_ the allocation size!) of the file name string". *But* the man page says the addrlen argument to accept() should contain the "size of the structure pointed to by addr", so in this case, the SUN_LEN is not the candidate, but rather the "sizeof(struct sockaddr_un)". > > Should we report that? You mean reporting that accept() needs addrlen initialized if addr is not NULL? I don't know, as it seems that my system is the only one with that symptom. Farvel (Danish: Farewell) -- Melvin Hadasht

Feb. 3, 2003