Date: Tue, 6 Apr 2004 00:04:05 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 338 ************************************************** Monday 05 April 2004 Number 338 ************************************************** Subjects for today 1 Makefile.am for hello.exe : John Poltorak 2 Re: Building DLLs : Knut St. Osmundsen" 3 Re: Building DLLs : Knut St. Osmundsen" 4 Re: Autoconf v2.59 : Knut St. Osmundsen" 5 Re: Makefile.am for hello.exe : Andreas Buening 1 Re: Building DLLs : Andreas Buening 2 Re: Building DLLs : Knut St. Osmundsen" 3 Re: Autoconf v2.59 : Knut St. Osmundsen" 4 Re: Makefile.am for hello.exe : John Poltorak 5 Re: Autoconf v2.59 : John Poltorak 6 Re: Building DLLs : Knut St. Osmundsen" 7 Re: Makefile.am for hello.exe : Andreas Buening 8 Re: Autoconf v2.59 : Andreas Buening 9 Re: Autoconf v2.59 : Knut St. Osmundsen" 10 Re: Autoconf v2.59 : Knut St. Osmundsen" 11 Re: Makefile.am for hello.exe : John Poltorak 6 Re: Autoconf v2.59 : Andreas Buening 12 Re: Autoconf v2.59 : John Poltorak 7 Re: Makefile.am for hello.exe : Andreas Buening 8 Re: Building DLLs : Dave and Natalie" 9 Setting Environment for Make : John Poltorak 10 Building Subversion : Johannes Fahrenkrug 27 Re: Autoconf v2.59 : Andreas Buening **= Email 1 ==========================** Date: Sun, 4 Apr 2004 15:27:19 +0100 From: John Poltorak Subject: Makefile.am for hello.exe I realise that this is oversimplistic but, if for some strange reason I wanted to build a HELLO program which just output 'Hello, world' using the GNU Build System, would Makefile.am simply consist of:- ? bin_PROGRAMS = hello hello_SOURCES = hello.c I'm trying to get to the bottom of how all this works and can't fins a simple enough example, or at least an example which works. If that is OK for Makefile.am, what are the minimal statements I would need for configure.ac? -- John **= Email 2 ==========================** Date: Sun, 04 Apr 2004 17:28:25 +0200 From: "Knut St. Osmundsen" Subject: Re: Building DLLs John Poltorak wrote: > On Fri, Apr 02, 2004 at 04:33:32PM +0200, Knut St. Osmundsen wrote: > >> Dave and Natalie wrote: >> >>> On Thu, 01 Apr 2004 17:20:47 +0200, Knut St. Osmundsen wrote: >>> >>> >>> >>>> There is no flag for building both a.out and omf binaries, that >>>> doesn't make much sense IMHO. >>> >>> >>> Well when building common DLLs such as zlib for distributation it >>> is nice to include both a.out and omf export libs (and static) so >>> anyone using it has a choice >> >> That I strongly agree with. But that just means you have to do two >> emxomf operations: emxomf -o libz_dll.a z.def && emxomf -o >> libz_dll.lib z.def > > > Can't issues like this be dealt with automatically by changes to > libtool? Sure, the libtool v1.5 port I did for InnoTek GCC does that. Kind Regards, knut **= Email 3 ==========================** Date: Sun, 04 Apr 2004 17:43:04 +0200 From: "Knut St. Osmundsen" Subject: Re: Building DLLs Stefan Neis wrote: > On Sat, 3 Apr 2004, Stefan Neis wrote: > > >> emxbind: export multiply defined: append__8wxStringPCc >> >>when in fact I'm trying to export three different symbols, namely: >> "append__8wxStringPCc" >> "append__8wxStringPCcT1" >> "append__8wxStringPCcUl" >> >>If I remove two of those symbols, I get a DLL... >>I should mention that this is with plain EMX (gcc-2.8.1), so updating >>emxbind to e.g. gcc-3.0.3 level might help? > > > Actually, I have similar problems with Innotek's gcc port (god, gcc-3.2.x > really _is_ slow, compared to 2.8.1!). Here, the conflicting symbols seem > to be e.g. > "__ZN14wxBaseArrayInt5clearEv" > "__ZN14wxBaseArrayInt5ClearEv" I can reproduce this. Debugging it now. Kind Regards, knut **= Email 4 ==========================** Date: Sun, 04 Apr 2004 17:49:04 +0200 From: "Knut St. Osmundsen" Subject: Re: Autoconf v2.59 John Poltorak wrote: > On Fri, Apr 02, 2004 at 04:38:29PM +0200, Knut St. Osmundsen wrote: > >> John Poltorak wrote: >> >>> Does anyone know if Autoconf v2.59 works straight out of the box >>> on OS/2? >>> >>> Does Innotek's version have any modifications to the distributed >>> source? >>> >> >> Yes, I did some changes. `cvs diff -r AUTOCONF_2-59` generates a >> 12kb diff file here. > > > > That sounds like quite a lot of changes. > > Do you think any of them should be submitted to the Autoconf > developers for possible inclusions with forthcoming versions of > Autoconf? > Depends if they appreciate driveletter stuff. They surely will not appreciate UNIXROOT and /bin/sh -> sh changes, I'm sure. I considered it more work to cleanup and submitt patches to autoconf than maintaining the a parallel port of it. But if you have time to clean up parts of it and submitt it, please do, but I don't have time/health for that I'm afraid. Kind Regards, knut **= Email 5 ==========================** Date: Sun, 04 Apr 2004 18:23:50 +0200 From: Andreas Buening Subject: Re: Makefile.am for hello.exe John Poltorak wrote: > > I realise that this is oversimplistic but, if for some strange reason I > wanted to build a HELLO program which just output 'Hello, world' using the > GNU Build System, would Makefile.am simply consist of:- ? > > bin_PROGRAMS = hello > hello_SOURCES = hello.c bin_PROGRAMS = hello$(EXEEXT) > I'm trying to get to the bottom of how all this works and can't fins a > simple enough example, or at least an example which works. > > If that is OK for Makefile.am, what are the minimal statements I would > need for configure.ac? This might be the smallest configure.ac for a C program using automake and autoheader (not tested): AC_PREREQ([2.53]) AC_INIT([hello], [1.2.3]) AM_INIT_AUTOMAKE([hello], [1_2_3]) AM_CONFIG_HEADER([config.h]) AC_PROG_CC AC_CONFIG_FILES([Makefile]) AC_OUTPUT Bye, Andreas **= Email 1 ==========================** Date: Sun, 04 Apr 2004 18:23:58 +0200 From: Andreas Buening Subject: Re: Building DLLs Knut St. Osmundsen wrote: > Sure, the libtool v1.5 port I did for InnoTek GCC does that. Could you provide some diffs for that, please? Bye, Andreas **= Email 2 ==========================** Date: Sun, 04 Apr 2004 19:39:21 +0200 From: "Knut St. Osmundsen" Subject: Re: Building DLLs Andreas Buening wrote: > Knut St. Osmundsen wrote: > > >>Sure, the libtool v1.5 port I did for InnoTek GCC does that. > > > Could you provide some diffs for that, please? > I will provide diffs for all the extra stuff when I do the next GCC release, in the mean time you can just diff my changed sources against the libtool v1.5 sources. Kind Regards, knut **= Email 3 ==========================** Date: Sun, 04 Apr 2004 19:50:31 +0200 From: "Knut St. Osmundsen" Subject: Re: Autoconf v2.59 Andreas Buening wrote: > Knut St. Osmundsen wrote: > >> John Poltorak wrote: > > >>> Do you think any of them should be submitted to the Autoconf >>> developers for possible inclusions with forthcoming versions of >>> Autoconf? >>> >> >> Depends if they appreciate driveletter stuff. They surely will not >> appreciate UNIXROOT and /bin/sh -> sh changes, I'm sure. > > > Why do you need this anyway? Usually, you can specify your shell with > $CONFIG_SHELL. I don't recall the details of what I did, perhaps /bin/sh/ -> $CONFIG_SHELL would be the right thing. > However, from the patches John sent yesterday I conclude that you've > included some extra code I've written, some code for UNIXROOT and sh, > and you've played with the testsuite. Is this correct? > Yes, I looked at the 2.57 port and I've played with the testsuite. I don't quite recall how many tests which failed but I don't think it was that many. IIRC the testharness takes for ever to run on OS/2, which isn't very phun when you need to rerun it and stuff. >> I considered it more work to cleanup and submitt patches to >> autoconf than maintaining the a parallel port of it. But if you >> have time to clean up parts of it and submitt it, please do, but I >> don't have time/health for that I'm afraid. > > > Currently, I'm playing around with autoconf 2.59 and would like to > submit some minor changes especially to get the testsuite working. > Have phun :-) Kind Regards, knut **= Email 4 ==========================** Date: Sun, 4 Apr 2004 18:54:10 +0100 From: John Poltorak Subject: Re: Makefile.am for hello.exe On Sun, Apr 04, 2004 at 06:23:50PM +0200, Andreas Buening wrote: > John Poltorak wrote: > > > > I realise that this is oversimplistic but, if for some strange reason I > > wanted to build a HELLO program which just output 'Hello, world' using the > > GNU Build System, would Makefile.am simply consist of:- ? > > > > bin_PROGRAMS = hello > > hello_SOURCES = hello.c > > bin_PROGRAMS = hello$(EXEEXT) Actually this does not appear necessary as Makefile.in created by automake gets the variable $(EXEEXT) added. > > > I'm trying to get to the bottom of how all this works and can't fins a > > simple enough example, or at least an example which works. > > > > If that is OK for Makefile.am, what are the minimal statements I would > > need for configure.ac? > > This might be the smallest configure.ac for a C program using > automake and autoheader (not tested): > > AC_PREREQ([2.53]) > AC_INIT([hello], [1.2.3]) > AM_INIT_AUTOMAKE([hello], [1_2_3]) > AM_CONFIG_HEADER([config.h]) > AC_PROG_CC > AC_CONFIG_FILES([Makefile]) > AC_OUTPUT I've just given it a try with these minimum values. Here is what I get:- configure.ac: no proper invocation of AM_INIT_AUTOMAKE was found. configure.ac: You should verify that configure.ac invokes AM_INIT_AUTOMAKE, configure.ac: that aclocal.m4 is present in the top-level directory, configure.ac: and that aclocal.m4 was recently regenerated (using aclocal). configure.ac: required file `./install-sh' not found configure.ac: required file `./missing' not found Makefile.am: required file `./INSTALL' not found Makefile.am: required file `./NEWS' not found Makefile.am: required file `./README' not found Makefile.am: required file `./AUTHORS' not found Makefile.am: required file `./ChangeLog' not found Makefile.am: required file `./COPYING' not found Makefile.am: required file `./depcomp' not found /usr/local/share/automake-1.8/am/depend2.am: am__fastdepCC does not appear in AM_CONDITIONAL /usr/local/share/automake-1.8/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL Using:- autoconf (GNU Autoconf) 2.58 configure.ac:3: error: possibly undefined macro: AM_INIT_AUTOMAKE If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:4: error: possibly undefined macro: AM_CONFIG_HEADER ../configure configure: loading site script c:/ux2bs/lib/config.site configure: creating cache /dev/null ../configure[1253]: syntax error: `hello,' unexpected This is as a result of running:- automake (1.8.3) autoconf (2.58) configure I can't understand why the first error occurs at all. Does it indicate a syntax error? I realise the format of the values for some of the macros changes, but they look correct for the versions of the programs I am using. Is there an obvious error here? I suspect I should run aclocal and autoheader in addition to the above... > Bye, > Andreas -- John **= Email 5 ==========================** Date: Sun, 4 Apr 2004 19:06:23 +0100 From: John Poltorak Subject: Re: Autoconf v2.59 On Sun, Apr 04, 2004 at 06:24:16PM +0200, Andreas Buening wrote: > Currently, I'm playing around with autoconf 2.59 and would like > to submit some minor changes especially to get the testsuite > working. It would be nice to be able to have a single source that works straight out of the box for everyone, so having OS/2 enhancements rolled into the original distributed source would mean that any new releases woud automatically include those changes and we wouldn't need an OS/2 maintainer. Having said that, I understand that Knud has his primary goal of getting gcc working properly and I wouldn't want to hold him up with that. > Bye, > Andreas -- John **= Email 6 ==========================** Date: Sun, 04 Apr 2004 20:10:31 +0200 From: "Knut St. Osmundsen" Subject: Re: Building DLLs Knut St. Osmundsen wrote: > Stefan Neis wrote: > >> On Sat, 3 Apr 2004, Stefan Neis wrote: >> >> >>> emxbind: export multiply defined: append__8wxStringPCc >>> >>> when in fact I'm trying to export three different symbols, namely: >>> "append__8wxStringPCc" >>> "append__8wxStringPCcT1" >>> "append__8wxStringPCcUl" >>> >>> If I remove two of those symbols, I get a DLL... >>> I should mention that this is with plain EMX (gcc-2.8.1), so updating >>> emxbind to e.g. gcc-3.0.3 level might help? >> >> >> >> Actually, I have similar problems with Innotek's gcc port (god, gcc-3.2.x >> really _is_ slow, compared to 2.8.1!). Here, the conflicting symbols seem >> to be e.g. >> "__ZN14wxBaseArrayInt5clearEv" >> "__ZN14wxBaseArrayInt5ClearEv" > > > I can reproduce this. Debugging it now. emxbind did an stricmp() to check for duplicate export names. I've corrected this to be strcmp() instead. This should fix the latter of the above problems. emxbind fix (unofficial): http://download.innotek.de/gccos2/testcase/emxbind-exportproblem.zip Kind Regards, knut **= Email 7 ==========================** Date: Sun, 04 Apr 2004 20:17:55 +0200 From: Andreas Buening Subject: Re: Makefile.am for hello.exe John Poltorak wrote: > I've just given it a try with these minimum values. Here is what I get:- [many warnings and errors] > This is as a result of running:- > > automake (1.8.3) > autoconf (2.58) > configure > > I can't understand why the first error occurs at all. Does it indicate a > syntax error? I realise the format of the values for some of the macros > changes, but they look correct for the versions of the programs I am > using. Is there an obvious error here? I suspect I should run aclocal and > autoheader in addition to the above... You've just requested configure.ac, not the commands you need to get it running. ;-) IIRC this is what you want (not tested): aclocal automake -a -c --foreign autoconf autoheader And, AFAIK autoconf 2.58 has some serious bugs so that it was replaced by 1.59 very soon. Bye, Andreas **= Email 8 ==========================** Date: Sun, 04 Apr 2004 20:18:19 +0200 From: Andreas Buening Subject: Re: Autoconf v2.59 Knut St. Osmundsen wrote: > > Andreas Buening wrote: > > Knut St. Osmundsen wrote: > I don't recall the details of what I did, perhaps /bin/sh/ -> > $CONFIG_SHELL would be the right thing. In theory /bin/sh is never used if CONFIG_SHELL is set. > > However, from the patches John sent yesterday I conclude that you've > > included some extra code I've written, some code for UNIXROOT and sh, > > and you've played with the testsuite. Is this correct? > > > > Yes, I looked at the 2.57 port and I've played with the testsuite. I > don't quite recall how many tests which failed but I don't think it was > that many. IIRC the testharness takes for ever to run on OS/2, which > isn't very phun when you need to rerun it and stuff. Oh, yeah. And I bet your computer is faster than mine. :-((( > >> I considered it more work to cleanup and submitt patches to > >> autoconf than maintaining the a parallel port of it. But if you > >> have time to clean up parts of it and submitt it, please do, but I > >> don't have time/health for that I'm afraid. > > > > > > Currently, I'm playing around with autoconf 2.59 and would like to > > submit some minor changes especially to get the testsuite working. > > Have phun :-) :-( Btw, do you have the permission to submit patches to gnu.org? Bye, Andreas **= Email 9 ==========================** Date: Sun, 04 Apr 2004 21:03:14 +0200 From: "Knut St. Osmundsen" Subject: Re: Autoconf v2.59 John Poltorak wrote: > On Sun, Apr 04, 2004 at 06:24:16PM +0200, Andreas Buening wrote: > > >> Currently, I'm playing around with autoconf 2.59 and would like to >> submit some minor changes especially to get the testsuite working. > > > It would be nice to be able to have a single source that works > straight out of the box for everyone, so having OS/2 enhancements > rolled into the original distributed source would mean that any new > releases woud automatically include those changes and we wouldn't > need an OS/2 maintainer. > > Having said that, I understand that Knut has his primary goal of > getting gcc working properly and I wouldn't want to hold him up with > that. Yep, that would be a very nice thing, only, I'd like to see some more changes than I guess the autoconf developers/maintainers probably would accept. Like the UNIXROOT and no /bin/sh stuff. You just removed that when generating that diff a few mails ago, remember. I need those features. So, when they aren't there I have to maintain a separate line anyway. So, it's gonna hold a bit of my time anyway. But anyway, if some of the changes made it into the autoconf cvs I'd be happy, it's just that I've got no time for that. Kind Regards, knut **= Email 10 ==========================** Date: Sun, 04 Apr 2004 21:05:39 +0200 From: "Knut St. Osmundsen" Subject: Re: Autoconf v2.59 Andreas Buening wrote: > Knut St. Osmundsen wrote: > >> Andreas Buening wrote: >> >>> Knut St. Osmundsen wrote: > > >> I don't recall the details of what I did, perhaps /bin/sh/ -> >> $CONFIG_SHELL would be the right thing. > > > In theory /bin/sh is never used if CONFIG_SHELL is set. Only /bin/sh is hardcoded a few places, so that'll have to be changed then. Question is if CONFIG_SHELL is around at those points, I didn't consider this when I changed it and thus didn't check it out. [snip] > Btw, do you have the permission to submit patches to gnu.org? No. Kind Regards, knut **= Email 11 ==========================** Date: Sun, 4 Apr 2004 20:08:10 +0100 From: John Poltorak Subject: Re: Makefile.am for hello.exe On Sun, Apr 04, 2004 at 08:17:55PM +0200, Andreas Buening wrote: > John Poltorak wrote: > > > I've just given it a try with these minimum values. Here is what I get:- > > [many warnings and errors] > > > This is as a result of running:- > > > > automake (1.8.3) > > autoconf (2.58) > > configure > > > > I can't understand why the first error occurs at all. Does it indicate a > > syntax error? I realise the format of the values for some of the macros > > changes, but they look correct for the versions of the programs I am > > using. Is there an obvious error here? I suspect I should run aclocal and > > autoheader in addition to the above... > > You've just requested configure.ac, not the commands you need > to get it running. ;-) Well I'm still hazy about some of these commands and when they are needed. Didn't realise aclocal was needed. > IIRC this is what you want (not tested): > > aclocal > automake -a -c --foreign > autoconf > autoheader Is that the correct sequence? ie. should I expect to see this msg when running the programs in that order? configure.ac:4: required file `config.h.in' not found > And, AFAIK autoconf 2.58 has some serious bugs so that it was > replaced by 1.59 very soon. Can you suggest which versiions of AC and AM I should use? I'm pleased to report that I can now build hello.exe using the GNU Autotools, so thank you again for the help. Now that I have a better understanding of how they work I need to try and incorporate libtool to see if it's possible to use these tools for building ZLIB... > Bye, > Andreas -- John **= Email 6 ==========================** Date: Sun, 04 Apr 2004 18:24:16 +0200 From: Andreas Buening Subject: Re: Autoconf v2.59 Knut St. Osmundsen wrote: > > John Poltorak wrote: > > Do you think any of them should be submitted to the Autoconf > > developers for possible inclusions with forthcoming versions of > > Autoconf? > > > > Depends if they appreciate driveletter stuff. They surely will not > appreciate UNIXROOT and /bin/sh -> sh changes, I'm sure. Why do you need this anyway? Usually, you can specify your shell with $CONFIG_SHELL. However, from the patches John sent yesterday I conclude that you've included some extra code I've written, some code for UNIXROOT and sh, and you've played with the testsuite. Is this correct? > I considered it more work to cleanup and submitt patches to autoconf > than maintaining the a parallel port of it. But if you have time to > clean up parts of it and submitt it, please do, but I don't have > time/health for that I'm afraid. Currently, I'm playing around with autoconf 2.59 and would like to submit some minor changes especially to get the testsuite working. Bye, Andreas **= Email 12 ==========================** Date: Sun, 4 Apr 2004 20:24:03 +0100 From: John Poltorak Subject: Re: Autoconf v2.59 On Sun, Apr 04, 2004 at 09:03:14PM +0200, Knut St. Osmundsen wrote: > John Poltorak wrote: > > > > Having said that, I understand that Knut has his primary goal of > > getting gcc working properly and I wouldn't want to hold him up with > > that. > > Yep, that would be a very nice thing, only, I'd like to see some more > changes than I guess the autoconf developers/maintainers probably would > accept. Like the UNIXROOT and no /bin/sh stuff. You just removed that > when generating that diff a few mails ago, remember. I need those > features. Well it may be that setting $CONFIG_SHELL might obviate the requirement to to make changes which refer to /bin/sh... and there may be some other means of incorporating UNIXROOT. But I'm sure the maintainers would be reluctant to accept such changes. > So, when they aren't there I have to maintain a separate line > anyway. So, it's gonna hold a bit of my time anyway. Not if v2.60 is fully usable straight out of the box ;-)... > But anyway, if some of the changes made it into the autoconf cvs I'd be > happy, it's just that I've got no time for that. Sure, I understand that. Andreas has been doing a great job getting OS/2 specific enhancements into various GNU apps over the last few years and he may well be able to get Autoconf set up exactly as you need it. > Kind Regards, > knut -- John **= Email 7 ==========================** Date: Sun, 04 Apr 2004 22:11:12 +0200 From: Andreas Buening Subject: Re: Makefile.am for hello.exe John Poltorak wrote: > > On Sun, Apr 04, 2004 at 08:17:55PM +0200, Andreas Buening wrote: > > IIRC this is what you want (not tested): > > > > aclocal > > automake -a -c --foreign > > autoconf > > autoheader > > Is that the correct sequence? ie. should I expect to see this msg when > running the programs in that order? aclocal first, the other ones in any order. > configure.ac:4: required file `config.h.in' not found No idea. > > And, AFAIK autoconf 2.58 has some serious bugs so that it was > > replaced by 1.59 very soon. > > Can you suggest which versiions of AC and AM I should use? Any version (AC 2.53+, AM 1.7+) should do unless the application requires a special version. Bye, Andreas **= Email 8 ==========================** Date: Sun, 04 Apr 2004 12:17:29 -0800 From: "Dave and Natalie" Subject: Re: Building DLLs On Sat, 3 Apr 2004 20:32:44 +0200 (CEST), Stefan Neis wrote: > >If I remove two of those symbols, I get a DLL... >I should mention that this is with plain EMX (gcc-2.8.1), so updating >emxbind to e.g. gcc-3.0.3 level might help? You might want to try updating emxbind, as well as the othe emx*, ld, ldstub.bin. There are sopposed to be quite a few bug fixes in these as well as other improvements. Though some DOS and short file name cod ehas been removed. You could always put them in /emx/bin.new and put that ahead of /emx/bin in your path (perhaps in a script) and try it. IIRC mine are all from GCC 3.2.1. Dave **= Email 9 ==========================** Date: Mon, 5 Apr 2004 00:16:48 +0100 From: John Poltorak Subject: Setting Environment for Make Is there any way to set the environment in which Make executes it's rules from within Make itself? What I would like to do is ensure that Make uses a specific path, libpath and sundry other variables prior to invoking a rule. What is the best way of doing that? Is there any way to run an initialisation script? -- John **= Email 10 ==========================** Date: Mon, 05 Apr 2004 09:37:59 GMT From: Johannes Fahrenkrug Subject: Building Subversion Hi everyone, I was sick last week so I just had to go through a couple of hundred emails this morning... but sadly it seemed as if the discussion about building subversion... umm... died. Is anyone still working on it? Has any progress been made? I'm sure that it must be possible to at least build the client. We have got to get that darn thing to work somehow :) -Johannes. **= Email 27 ==========================** Date: Sun, 04 Apr 2004 22:11:28 +0200 From: Andreas Buening Subject: Re: Autoconf v2.59 Knut St. Osmundsen wrote: > > Andreas Buening wrote: > > In theory /bin/sh is never used if CONFIG_SHELL is set. > > Only /bin/sh is hardcoded a few places, so that'll have to be changed > then. Question is if CONFIG_SHELL is around at those points, I didn't > consider this when I changed it and thus didn't check it out. In the past I used CONFIG_SHELL sometimes when I compiled something on a different drive. I should work in most cases and more important, since this feature is supported by the maintainers, related patches will be accepted. > [snip] > > Btw, do you have the permission to submit patches to gnu.org? > > No. Oh. Does this mean you haven't subscibed yet that paper for the FSF or doesn't Innotek not allow you to do so? Bye, Andreas