From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Tue, 21 Jan 2003 04:48:48 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 20 ************************************************** Monday 20 January 2003 Number 20 ************************************************** Subjects for today 1 Re: glibc completion : Thomas Hoffmann 2 Re: glibc completion : Andreas Buening 3 Re: Standard variables : Andreas Buening 4 Re: Autoconf & Make 3.76.1 : Andreas Buening 5 Re: Testing for LINK386 on path : Csaba" 6 Re: Building OpenSSL : Nicholas Sheppard 7 Re: Open Group's commands and utils : Dave Saville" 8 Re: Standard variables : Dave Saville" 9 Re: Open Group's commands and utils : John Poltorak 10 Re: Building OpenSSL : John Poltorak 11 Re: BYACC : Thomas E. Dickey" 12 Re: BYACC : John Poltorak 13 Re: glibc completion : Maynard" 14 Re: Building OpenSSL : John Poltorak 15 Re: glibc completion : John Poltorak 16 Re: Building OpenSSL : Hannes Hromadka 17 Re: glibc completion : Sebastian Wittmeier (ShadoW)" 18 Re: Building OpenSSL : Brian Havard" 19 Re: Autoconf & Make 3.76.1 : John Poltorak 20 Re: Building OpenSSL : Brian Havard" 21 Gnu Compiler Suite for OS/2 bugtracker : Adrian Gschwend" **= Email 1 ==========================** Date: Tue, 21 Jan 2003 00:28:55 +0100 From: Thomas Hoffmann Subject: Re: glibc completion Only two remarks: I do use (a fixed) libcExt from Posix/2 for more than 3 years now and this way I got rid of lots of extra libs to include and src code hacking with #ifdef __EMX__. It certainly has its rough edges, but is a usable solution to build on. (Possibly not suggested for everybody: I brutally copied the posix/2 headers over the emx headers (this mixture resides in /usr/include, btw: no /emx anymore) and set LIBS=-lcExt before starting configure runs: with gcc 3.0.3 this works in most of the cases). And then I think there is a lesson to learn from the fate of Posix/2, especially in comparison with EMX: put a new system/library to work, keep it as simple as possible, accompany it with readable (user) documentation. At last it does not matter if this thing is named libcext or libunixos2, but libcext provides simply more additional functionality at the moment. Thomas. Stefan Neis wrote: > On Mon, 20 Jan 2003, Andreas Buening wrote: > > >>Then I know that the glibc function foo() >>is missing. > > > But that makes it sound like it's a glibc-specific extension of libc, > which implies that something is really wrong as almost all packages > I know should build with any libc used on Unix, not just with glibc. > So, if it's a general libc function, then it is in fact missing, > if it's an extension to libc provided (only) by glibc, then something > is conigured wrongly, that's why I insist on that seemingly silly > difference... > > >>This leads to the conclusions: >>- We need an improved libc NOW. >>- We need a consistent set of header files. > > > And my answer to both is: Posix/2 is there, so what's the problem > (aside from debugging & fixing)? Just install it on your system, > modify C_INCLUDE_PATH, CPLUS_INCLUDE_PATH, LIBRARY_PATH and you're > done. Of course, one could melt all those functions into emx.dll/ > emxc?.dll, but why not debug them first? > > Ah, OK, reading further, I get it, you're annoyed by the extra -lcExt > which I just forgot about ... > > >>3. We keep EMX untouched but we add all new functionality to an >> additional library called Posix/2. >> Advantages: We have a huge bunch of already implemented >> additional functions. No updates of the EMX dlls anymore. Never. >> Disadvantages: We can't start from a working libc > > > Actually, it's based on EMX dll's which work reasonably well ... > > >> but I don't >> know whether the bugs in Posix/2 are really serious. >> Need for an extra compiler flag "-lext". >> We have a completely new set of header files, i.e. all EMX >> headers have to be replaced. Question: Does Posix/2 support >> all documented EMX functions, i.e. is it possible to compile >> all kinds of EMX programs with Posix/2? > > > Actually, we are linking against _both_ cExt.a (first) _and_ EMX > standard libraries (afterwards, catching anything not touched by > cExt or where cExt.a really is just a wrapper), so there shouldn't > be any problem with any existing program. The first that can happen > is that we end up with a mix of incompatible function (one from BSD, > one from EMX or even from the native OS/2 level) which cause strange > runtime errors (we had/fixed that kind of problem with e.g. sockets, > Thomas seems to have one or two occurences of a similar problem, > unfortunately, II had no time to look into it, so far). > > >>important points. So the question What do we want? Personally, >>I'd vote for 1 or 2 but that's not the point. > > > If somebody has time/knowledge to do this, that would be my prefered > way as well, but it's like to take quite some time, so in the meantime, > I'll happily stay with what already exists (Posix/2). > > Regards, > Stefan > > > **= Email 2 ==========================** Date: Tue, 21 Jan 2003 00:38:50 +0100 From: Andreas Buening Subject: Re: glibc completion Stefan Neis wrote: > > On Mon, 20 Jan 2003, Andreas Buening wrote: > > > Then I know that the glibc function foo() > > is missing. > > But that makes it sound like it's a glibc-specific extension of libc, > which implies that something is really wrong as almost all packages > I know should build with any libc used on Unix, not just with glibc. > So, if it's a general libc function, then it is in fact missing, > if it's an extension to libc provided (only) by glibc, then something > is conigured wrongly, that's why I insist on that seemingly silly > difference... In principle you're right. I just wanted to say that "a glibc function is missing" is 95% equivalent to "a libc function is missing". Most people don't (and needn't) know the difference between several libc implementations. > > This leads to the conclusions: > > - We need an improved libc NOW. > > - We need a consistent set of header files. > > And my answer to both is: Posix/2 is there, so what's the problem > (aside from debugging & fixing)? Just install it on your system, > modify C_INCLUDE_PATH, CPLUS_INCLUDE_PATH, LIBRARY_PATH and you're > done. Because you then have two different sets of header files which might lead to incompatibilities as Holger said. John reported a problem with perl 5.8. I don't know what's the reason. But I'm quite sure that just putting another include directory in front of your PATH can't be the solution. > Of course, one could melt all those functions into emx.dll/ > emxc?.dll, but why not debug them first? I haven't suggested to add these functions uncritically to EMX. > Ah, OK, reading further, I get it, you're annoyed by the extra -lcExt > which I just forgot about ... That's just one minor detail. [snip] > > important points. So the question What do we want? Personally, > > I'd vote for 1 or 2 but that's not the point. > > If somebody has time/knowledge to do this, that would be my prefered > way as well, but it's like to take quite some time, so in the meantime, > I'll happily stay with what already exists (Posix/2). There is no reason why you shouldn't use existing libraries like Posix/2 to compile some stuff. The point is that we want to have and need a standardized build system where it's not necessary to fiddle around with several compiler versions/libraries/headers that have to installed in a specific order or whose files have to appear in a specific order in different *PATH env. vars. Time and knowledge is a problem. Writing a libc is more than a full time job. Therefore I agree that we need a maintainer of "our" new libc (whether it's enhanced EMX, libunixos2 or Posix/2) who knows how the build system of the libc itself works. I don't want to reinvent the wheel. The maintainer's job shouldn't be to implement new functions. That's too much work. That's the job of people who need those functions. Just to write an implementation of foo() or to collect it from elsewhere (maybe from Posix/2) and to submit it to the libc maintainer who adds an entry to the Makefile and/or the header file. That's the way it works in the GNU world. However, I got four on topic replies on my posting with four different opinions. The good news is: We agree that we don't agree. ;-) Bye, Andreas -- One OS to rule them all, One OS to find them, One OS to bring them all and in the darkness bind them In the Land of Mordor where the Shadows lie. **= Email 3 ==========================** Date: Tue, 21 Jan 2003 00:39:15 +0100 From: Andreas Buening Subject: Re: Standard variables Dave Saville wrote: > > On Mon, 20 Jan 2003 12:09:02 +0000, John Poltorak wrote: > > > > >Is there anything which defines which environment variables should/must be > >present on a Unix system? > > I could be wrong but I don't think so - at least I never ran across > anything in five years of Solaris systems admin. I think it depends > on how the system was setup, what the default shell is and what gets > sourced at login/shell start. Note that these are two different > events. There are default startup scripts for all the usual shells, > buried somewhere under /etc. Thats most likely the nearest you will > get - and they likely differ between flavours of *nix - or even > versions of the same *nix. > > If you start a bourne shell progamatically about the only one around > is $HOME - I assume so that one can start sourcing things. At least Posix 1 seems to define the following variables: HOME, LANG, LC_{ALL|COLLATE|...}, LOGNAME, PATH, TERM, TZ but I don't know whether this info is still up to date. Bye, Andreas -- One OS to rule them all, One OS to find them, One OS to bring them all and in the darkness bind them In the Land of Mordor where the Shadows lie. **= Email 4 ==========================** Date: Tue, 21 Jan 2003 00:39:32 +0100 From: Andreas Buening Subject: Re: Autoconf & Make 3.76.1 John Poltorak wrote: > > On Mon, Jan 20, 2003 at 01:16:09AM +0100, Andreas Buening wrote: > > John Poltorak wrote: > > > > > > I realise the README for Autoconf says that Make v3.79.1+ is required to > > > build Autoconf, but I'm trying to understand why... > > > > Maybe because older versions don't work? > > Yes, but I would like to know what the problem is. An older version of > Make has no problem building Perl 5.8.0, and the same version can be used > to build Autoconf 2.50. I would not expect Autoconf to be particularly > demanding of Make's capabilities... You've never seen an automake generated Makefile? ;-) Really, autoconf/automake is about the worst thing that can happen to your make. [snip] Bye, Andreas -- One OS to rule them all, One OS to find them, One OS to bring them all and in the darkness bind them In the Land of Mordor where the Shadows lie. **= Email 5 ==========================** Date: Tue, 21 Jan 2003 01:17:22 -0000 From: "Csaba" Subject: Re: Testing for LINK386 on path On 17 Jan 2003, at 15:33, Stefan Neis wrote: > On Fri, 17 Jan 2003, John Poltorak wrote: > > > How do I know if I want to build OMF based stuff or a.out? > > Well, if you're using -Zomf, you're building OMF based stuff. > _The_ argument in favour of OMF is that it usually results in > smaller executables, that AFAIK, that's it. > Plus, you could use IPMD, ICSDEBUG, IDEBUG, or even (gasp) sd386 to debug it. If it's a PM app you'll be much happier (except EMX's o.out->omf converter tended to lose most of debug info )-: -- Ceci n'est pas un .signature **= Email 6 ==========================** Date: Tue, 21 Jan 2003 07:39:38 +1100 (EST) From: Nicholas Sheppard Subject: Re: Building OpenSSL On Mon, 20 Jan 2003, John Poltorak wrote: > Looking at OpenSSL web site there seems to be a lot of versions to choose > from, and maybe the patch only works on a specific release. The patch is for 0.9.6g I believe. I did get it built at one stage but I can't remember how I did it; I don't remember having to do anything strange. However: > Which release should I download? 0.9.7 compiled out of the box for me, except that I had to make one tiny change to one of the source files; I don't remember exactly what it was but it was an obvious fix for a C programmer. I also found that if I tried to run emxomf on the static crypto.a, I got a "symbol multiply defined: !" error. So I use the DLL version if I'm using -Zomf. Nicholas S. **= Email 7 ==========================** Date: Tue, 21 Jan 2003 08:45:29 +0000 (GMT) From: "Dave Saville" Subject: Re: Open Group's commands and utils xargs = FIND ?? There is a perfectly good xargs as part of xfree - and it does not need X to work fine. -- Regards Dave Saville **= Email 8 ==========================** Date: Tue, 21 Jan 2003 08:47:23 +0000 (GMT) From: "Dave Saville" Subject: Re: Standard variables On Tue, 21 Jan 2003 00:39:15 +0100, Andreas Buening wrote: >Dave Saville wrote: >> >> On Mon, 20 Jan 2003 12:09:02 +0000, John Poltorak wrote: >> >> > >> >Is there anything which defines which environment variables should/must be >> >present on a Unix system? >> >> I could be wrong but I don't think so - at least I never ran across >> anything in five years of Solaris systems admin. I think it depends >> on how the system was setup, what the default shell is and what gets >> sourced at login/shell start. Note that these are two different >> events. There are default startup scripts for all the usual shells, >> buried somewhere under /etc. Thats most likely the nearest you will >> get - and they likely differ between flavours of *nix - or even >> versions of the same *nix. >> >> If you start a bourne shell progamatically about the only one around >> is $HOME - I assume so that one can start sourcing things. > >At least Posix 1 seems to define the following variables: >HOME, LANG, LC_{ALL|COLLATE|...}, LOGNAME, PATH, TERM, TZ >but I don't know whether this info is still up to date. Yes, looking at the supplied default startup scripts they all assume that TERM is defined so I think that list makes sense - apart possibly from TZ. -- Regards Dave Saville **= Email 9 ==========================** Date: Tue, 21 Jan 2003 09:02:20 +0000 From: John Poltorak Subject: Re: Open Group's commands and utils On Tue, Jan 21, 2003 at 08:45:29AM +0000, Dave Saville wrote: > xargs = FIND ?? > > There is a perfectly good xargs as part of xfree - and it does not > need X to work fine. xargs is included with GNU FIND. > -- > Regards > > Dave Saville > -- John **= Email 10 ==========================** Date: Tue, 21 Jan 2003 09:25:13 +0000 From: John Poltorak Subject: Re: Building OpenSSL On Tue, Jan 21, 2003 at 08:03:48PM +1000, Brian Havard wrote: > On Mon, 20 Jan 2003 20:18:29 +0000, John Poltorak wrote: > > >Has anyone tried building OpenSSL according to the instructions here:- > > > >http://silk.apana.org.au/apache/building-openssl.html > > > >I tried but couldn't get the patch applied... > > > >Looking at OpenSSL web site there seems to be a lot of versions to choose > >from, and maybe the patch only works on a specific release. > > > >Which release should I download? > > You don't mention what version you were trying it on but yeah, that patch > is against an early 0.9.6 release. You can try the recent 0.9.7 release > which builds out of the box (see the INSTALL.OS2). Yes, I've tried that now and it does build without any problems, which is great. The thing I need to decide on is what to do with the output files... Should the headers from outinc be copied to /usr/include? Are they used by any other apps? I'm not at all familiar with OpenSSL and have no idea what the executables do but they all appear to be test programs apart from openssl.exe. Where would they normally be installed? Am I better off creatings DLLs ? Presumably they would be shared with other apps... but I'm not sure which. Incidentally, I saw a posting on USENET from IlyaZ in c.o.o.programmer.porting in which he said they shouldn't be called ssl.dll and crypto.dll because such names would be prone to a name clash. Is that likely? > -- > ______________________________________________________________________________ > | Brian Havard | "He is not the messiah! | > | brianh at kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian | > ------------------------------------------------------------------------------ > -- John **= Email 11 ==========================** Date: Tue, 21 Jan 2003 12:26:29 -0500 (EST) From: "Thomas E. Dickey" Subject: Re: BYACC On Tue, 21 Jan 2003, John Poltorak wrote: > On Sat, Jan 18, 2003 at 07:18:53AM -0500, Thomas Dickey wrote: > > On Sat, Jan 18, 2003 at 08:47:07AM +0000, John Poltorak wrote: > > > > If I can't use the Makefile to install it, I propose to copy yacc.exe to > > > /usr/bin and yacc.1 to /usr/share/man/man1. Does this sound correct? > > > > yes. > > How do I set up the environment to specify BYACC in preference to BISON? usually by setting the $YACC environment variable to the given program name. > > Looking at the Makefile, I see references to LINT and CTAGS. Is it better > to have these programs available before building BYACC? no - they are just nice-to-have. -- T.E.Dickey http://invisible-island.net ftp://invisible-island.net **= Email 12 ==========================** Date: Tue, 21 Jan 2003 14:05:12 +0000 From: John Poltorak Subject: Re: BYACC On Sat, Jan 18, 2003 at 07:18:53AM -0500, Thomas Dickey wrote: > On Sat, Jan 18, 2003 at 08:47:07AM +0000, John Poltorak wrote: > > If I can't use the Makefile to install it, I propose to copy yacc.exe to > > /usr/bin and yacc.1 to /usr/share/man/man1. Does this sound correct? > > yes. How do I set up the environment to specify BYACC in preference to BISON? Looking at the Makefile, I see references to LINT and CTAGS. Is it better to have these programs available before building BYACC? > -- > Thomas E. Dickey > http://invisible-island.net > ftp://invisible-island.net -- John **= Email 13 ==========================** Date: Tue, 21 Jan 2003 15:19:24 -0600 (CST) From: "Maynard" Subject: Re: glibc completion On Tue, 21 Jan 2003 17:23:48 +0000, John Poltorak wrote: >Unfortunately, Stefan is probably one of the few people who may be able to >get this working, but because one of the quirks of building Perl mean it >won't build on a system which has C: inacessible from OS/2, just as Stefan >has, then he is unable to give it a try. maybe he could set it up as a local network share ?? -- Maynard **= Email 14 ==========================** Date: Tue, 21 Jan 2003 17:12:04 +0000 From: John Poltorak Subject: Re: Building OpenSSL On Tue, Jan 21, 2003 at 05:28:56PM +0100, Hannes Hromadka wrote: > Hello from Vienna: > > I'm new to this list, and a little bit short in time for now. > > On Tue, Jan 21, 2003 at 09:25:13AM +0000, John Poltorak wrote: > > > > is against an early 0.9.6 release. You can try the recent 0.9.7 release > > > which builds out of the box (see the INSTALL.OS2). > > > > Should the headers from outinc be copied to /usr/include? Are they used by > > any other apps? > > the whole openssl directory with the header files should go into a > direcotry in the INCLUDE path. On my system this is E:\emx\include. So i > have all openssl include files in E:\emx\include\openssl. When programs search the INCLUDE path for headers, they don't actually recurse subdirectories, AFAIK, so how would they find the headers in include\openssl? Do you need something like an include\openssl.h which provides the actual location of the openssl headers, justas you have with termcap.h? > > I'm not at all familiar with OpenSSL and have no idea what the executables > > do but they all appear to be test programs apart from openssl.exe. > > Mostly test files but make test does not work on my machine. Is this to be expected? > > Incidentally, I saw a posting on USENET from IlyaZ in > > c.o.o.programmer.porting in which he said they shouldn't be called ssl.dll > > and crypto.dll because such names would be prone to a name clash. Is that > > likely? > > I have seen this post. The question is: Are there any other libraries > with the same name which could cause problems ? IMV if the makefile creates files with these names then that is the name the porter intended them to have. I don't know of any other files with these names. > I need openssl to compile/link and run SLRN with SSL support. After > installing the DLLd version of openssl as writen above I could > build SLRN without problems. Yesterday I tested SLRN against the secure > webserver from netscape. And it works. Do you have instructions for building SLRN? I would like to see if I can incorporate it into my build framework. A have a little project for putting together a standard Unix-like distribution for OS/2. If that is something you are interested in you might like to join the UnixOS/2 Build System mailing list. For details see:- http://powerusersbbs.net/mailman/listinfo/ux2bs > > Ciao, Hannes > > -- > Johannes Hromadka | Email Office: HromadkaJ at gmx.at > | Home : Johannes.Hromadka at gmx.net > Vienna/Austria/Europe | OECC: http://www.oecc.org/ > PGP Public Key Fingerprint: > DAE6 4ABA 973C 59A7 2710 F3E5 E03A 8513 0487 412C > > >>> Rust never sleeps (borrowed from Neil YOUNG) <<< -- John **= Email 15 ==========================** Date: Tue, 21 Jan 2003 17:23:48 +0000 From: John Poltorak Subject: Re: glibc completion On Tue, Jan 21, 2003 at 12:38:50AM +0100, Andreas Buening wrote: > Stefan Neis wrote: > > > This leads to the conclusions: > > > - We need an improved libc NOW. > > > - We need a consistent set of header files. > > > > And my answer to both is: Posix/2 is there, so what's the problem > > (aside from debugging & fixing)? Just install it on your system, > > modify C_INCLUDE_PATH, CPLUS_INCLUDE_PATH, LIBRARY_PATH and you're > > done. > > Because you then have two different sets of header files which > might lead to incompatibilities as Holger said. John reported > a problem with perl 5.8. I don't know what's the reason. > But I'm quite sure that just putting another include directory > in front of your PATH can't be the solution. Unfortunately, Stefan is probably one of the few people who may be able to get this working, but because one of the quirks of building Perl mean it won't build on a system which has C: inacessible from OS/2, just as Stefan has, then he is unable to give it a try. I think it is a little too early to judge whether it is feasible to use an additional set of headers and libs in a build environment. However being able to build Perl with this arrangement would be a big step to showing that it is worth pursuing. > However, I got four on topic replies on my posting with four > different opinions. The good news is: We agree that we don't > agree. ;-) Well at least we agree that _something_ is required. I'd like to give Posix/2 a a good try. It has had extensive development and testing by a number of people over a year or two, and we have nothing to lose by trying it. > Bye, > Andreas > > -- > One OS to rule them all, One OS to find them, > One OS to bring them all and in the darkness bind them > In the Land of Mordor where the Shadows lie. -- John **= Email 16 ==========================** Date: Tue, 21 Jan 2003 17:28:56 +0100 From: Hannes Hromadka Subject: Re: Building OpenSSL Hello from Vienna: I'm new to this list, and a little bit short in time for now. On Tue, Jan 21, 2003 at 09:25:13AM +0000, John Poltorak wrote: > > is against an early 0.9.6 release. You can try the recent 0.9.7 release > > which builds out of the box (see the INSTALL.OS2). > > Should the headers from outinc be copied to /usr/include? Are they used by > any other apps? the whole openssl directory with the header files should go into a direcotry in the INCLUDE path. On my system this is E:\emx\include. So i have all openssl include files in E:\emx\include\openssl. > I'm not at all familiar with OpenSSL and have no idea what the executables > do but they all appear to be test programs apart from openssl.exe. Mostly test files but make test does not work on my machine. > Where would they normally be installed? > > Am I better off creatings DLLs ? Presumably they would be shared with > other apps... but I'm not sure which. I copied SSL.a, crypto.a and the corresponding .lib files into E:\emx\lib and the two DLL files into E:\EMX\DLL > Incidentally, I saw a posting on USENET from IlyaZ in > c.o.o.programmer.porting in which he said they shouldn't be called ssl.dll > and crypto.dll because such names would be prone to a name clash. Is that > likely? I have seen this post. The question is: Are there any other libraries with the same name which could cause problems ? I need openssl to compile/link and run SLRN with SSL support. After installing the DLLd version of openssl as writen above I could build SLRN without problems. Yesterday I tested SLRN against the secure webserver from netscape. And it works. Ciao, Hannes -- Johannes Hromadka | Email Office: HromadkaJ at gmx.at | Home : Johannes.Hromadka at gmx.net Vienna/Austria/Europe | OECC: http://www.oecc.org/ PGP Public Key Fingerprint: DAE6 4ABA 973C 59A7 2710 F3E5 E03A 8513 0487 412C >>> Rust never sleeps (borrowed from Neil YOUNG) <<< **= Email 17 ==========================** Date: Tue, 21 Jan 2003 18:57:51 +0100 (CET) From: "Sebastian Wittmeier (ShadoW)" Subject: Re: glibc completion Hi John, hi Stefan, On Tue, 21 Jan 2003 17:23:48 +0000, John Poltorak wrote: >Unfortunately, Stefan is probably one of the few people who may be able to >get this working, but because one of the quirks of building Perl mean it >won't build on a system which has C: inacessible from OS/2, just as Stefan >has, then he is unable to give it a try. Then change that bug to depend on another drive letter (which Stefan has). That should be no reason that Stefan can't participate in basing the build system on Posix/2. Sebastian **= Email 18 ==========================** Date: Tue, 21 Jan 2003 20:03:48 +1000 (EST) From: "Brian Havard" Subject: Re: Building OpenSSL On Mon, 20 Jan 2003 20:18:29 +0000, John Poltorak wrote: >Has anyone tried building OpenSSL according to the instructions here:- > >http://silk.apana.org.au/apache/building-openssl.html > >I tried but couldn't get the patch applied... > >Looking at OpenSSL web site there seems to be a lot of versions to choose >from, and maybe the patch only works on a specific release. > >Which release should I download? You don't mention what version you were trying it on but yeah, that patch is against an early 0.9.6 release. You can try the recent 0.9.7 release which builds out of the box (see the INSTALL.OS2). -- ______________________________________________________________________________ | Brian Havard | "He is not the messiah! | | brianh at kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian | ------------------------------------------------------------------------------ **= Email 19 ==========================** Date: Tue, 21 Jan 2003 20:41:57 +0000 From: John Poltorak Subject: Re: Autoconf & Make 3.76.1 On Tue, Jan 21, 2003 at 12:39:32AM +0100, Andreas Buening wrote: > John Poltorak wrote: > > > > On Mon, Jan 20, 2003 at 01:16:09AM +0100, Andreas Buening wrote: > > > John Poltorak wrote: > > > > > > > > I realise the README for Autoconf says that Make v3.79.1+ is required to > > > > build Autoconf, but I'm trying to understand why... > > > > > > Maybe because older versions don't work? > > > > Yes, but I would like to know what the problem is. An older version of > > Make has no problem building Perl 5.8.0, and the same version can be used > > to build Autoconf 2.50. I would not expect Autoconf to be particularly > > demanding of Make's capabilities... > > You've never seen an automake generated Makefile? ;-) > Really, autoconf/automake is about the worst thing that can > happen to your make. OK, I'll take your word for it. My main problem is how can I build Make 3.79.1 if I do not already have Make 3.79.1, as I can't install the latest Autoconf to build it with unless I already have this version of Make. > Bye, > Andreas > > -- > One OS to rule them all, One OS to find them, > One OS to bring them all and in the darkness bind them > In the Land of Mordor where the Shadows lie. -- John **= Email 20 ==========================** Date: Tue, 21 Jan 2003 22:23:10 +1000 (EST) From: "Brian Havard" Subject: Re: Building OpenSSL On Tue, 21 Jan 2003 09:25:13 +0000, John Poltorak wrote: >On Tue, Jan 21, 2003 at 08:03:48PM +1000, Brian Havard wrote: >> On Mon, 20 Jan 2003 20:18:29 +0000, John Poltorak wrote: >> >> >Has anyone tried building OpenSSL according to the instructions here:- >> > >> >http://silk.apana.org.au/apache/building-openssl.html >> > >> >I tried but couldn't get the patch applied... >> > >> >Looking at OpenSSL web site there seems to be a lot of versions to choose >> >from, and maybe the patch only works on a specific release. >> > >> >Which release should I download? >> >> You don't mention what version you were trying it on but yeah, that patch >> is against an early 0.9.6 release. You can try the recent 0.9.7 release >> which builds out of the box (see the INSTALL.OS2). > >Yes, I've tried that now and it does build without any problems, which is >great. > >The thing I need to decide on is what to do with the output files... > >Should the headers from outinc be copied to /usr/include? Are they used by >any other apps? > >I'm not at all familiar with OpenSSL and have no idea what the executables >do but they all appear to be test programs apart from openssl.exe. OpenSSL is primarily a library for other applications & openssl.exe is a basic front end. When building another application that uses OpenSSL the header files & libraries need to be available to it so yes, they will normally be installed in /usr/include/ & /usr/lib/ >Where would they normally be installed? > >Am I better off creatings DLLs ? Presumably they would be shared with >other apps... but I'm not sure which. Well, anything that anyone builds using the import libraries.... >Incidentally, I saw a posting on USENET from IlyaZ in >c.o.o.programmer.porting in which he said they shouldn't be called ssl.dll >and crypto.dll because such names would be prone to a name clash. Is that >likely? Well, I guess that's possible but I don't know what else you'd call them. The normal unix build creates libssl.so & libcrypto.so. -- ______________________________________________________________________________ | Brian Havard | "He is not the messiah! | | brianh at kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian | ------------------------------------------------------------------------------ **= Email 21 ==========================** Date: Tue, 21 Jan 2003 22:58:25 +0100 (CET) From: "Adrian Gschwend" Subject: Gnu Compiler Suite for OS/2 bugtracker Hi all, GCC gets more and more important on OS/2, mainly because it's the only up to date compiler available. Because of this Odin and other projects start to use it so it's about time for a coordinated effort for the port. Andy and Stauff are working on GCC 3.2.1 for OS/2 and for support we now have a bugtracking system at netlabg.org: http://xtracker.netlabs.org/index.php?project=15&gmtofs=-60 You are welcome to keep an eye on this xtracker and add own bugs if you run into a real OS/2 problem. Overview page: http://xtracker.netlabs.org/ Note that several projects are just visible if you are a registerd user. cu Adrian -- Adrian Gschwend at netlabs.org ktk [a t] netlabs.org ------- Free Software for OS/2 and eCS http://www.netlabs.org