From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Thu, 18 Sep 2003 14:11:41 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 197 ************************************************** Wednesday 17 September 2003 Number 197 ************************************************** Subjects for today 1 Re: [Ux2bs] Innotek LIBC : Adrian Gschwend" 2 Re: [Ux2bs] Innotek LIBC : Adrian Gschwend" 3 Re: Re: [Ux2bs] Innotek LIBC : Stefan Neis 4 Re: Re: [Ux2bs] Innotek LIBC : Stefan Neis 5 Re: Re: [Ux2bs] Innotek LIBC : Stefan Neis 6 Re: Re: [Ux2bs] Innotek LIBC : Dave and Natalie" 7 Re: gdk-pixbuf (was Re: Mailman tweaking) : Alex Newman" 8 Re: Re: [Ux2bs] Innotek LIBC : Steve Wendt" **= Email 1 ==========================** Date: Thu, 18 Sep 2003 14:54:04 +0200 (CDT) From: "Adrian Gschwend" Subject: Re: [Ux2bs] Innotek LIBC Again a forward, I took away the header and killed some Fwd's in the subject to make it more readable :) cu Adrian ==================BEGIN FORWARDED MESSAGE================== [headers killed] > > > Adrian Gschwend schrieb: > > >> Just to keep their expectations realistic. There is _currently_ >> fork() implementation, > > > I guess from context, there's a "no" missing? Ah, sorry. fork() isn't implemented, it's just a stub which complains and returns -1. (The reason is simple, EM code is GPL thus not suitable in a library.) >> neither does select() work on files - file handles and socket >> handles are not _yet_ shared. > > So that limits the range of programs which will work with that new > libc pretty much for the moment (forget about e.g. rsync and XFree, > in fact, probably forget about everything using sockets for now :-( > ). Sockets handles and filehandles are surely something which must be change. Only it requires a design dicussion, an implementation effort and it's a bit risky (in respect to mozilla). BTW. There is quite a number of apps which doesn't use sockets or require them to be filehandles. For instance, I've successfully build doxygen 1.3 (or what ever the CVS contained) a few months using our LIBC. >> Patches are highly appreciated!!! > > > Hm, there's currently a lack of time on my part... :-( wxWindows with > its two releases (2.4.2 stable and 2.5.1 snapshot) that are expected > soon is taking up pretty much of my limited spare time ... Sure, I'm interested in wxWindows, so please continue on that :) Is there anyone trying the new GCC with wxWindows btw. I see some activity with gcc on the mailing, but I didn't catch which one you guys are trying with. If anyone likes to try with the new one I'll do my best to help. >> PPS. Use -Zomf if you like to debug your app. There will be a Beta3 >> or GA by the end of the month which will have 99% working HLL debug >> features. Meaning you can use icsdebug, idebug or idbug (i.e. IBM >> VisualAge and later debuggers) to debug you C and C++ applications. >> > Any chance of making (pm)gdb work with the new compiler version? I > don't care at all about all those other debuggers that I don't have > and probably can't even get/use easily. We're not investing time updating the gdb port. I'm not sure why it's broken, it may be related to emxbind changes and/or changes in stabs output. It's not impossible that IBM might give you a debugger and a linker, we'll see what the mozilla guys can do. (Do I have to repeate that anyone wishing for gdb support are free to propose patches... ;) ) Kind Regards, knut PS. Where are those guys which were so keen on turning EMX upside down, fixing it up, and make the world a better place a few months back? PPS. Someone is working on 64bit I/O. PPPS. There is 'live' GCC and LIBC support on #gccos2 and #netlabs on dropnet (whenever zap or bird is around) :-) ===================END FORWARDED MESSAGE=================== -- Adrian Gschwend at netlabs.org ktk [a t] netlabs.org ------- Free Software for OS/2 and eCS http://www.netlabs.org _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 2 ==========================** Date: Thu, 18 Sep 2003 14:54:04 +0200 (CDT) From: "Adrian Gschwend" Subject: Re: [Ux2bs] Innotek LIBC Again a forward, I took away the header and killed some Fwd's in the subject to make it more readable :) cu Adrian ==================BEGIN FORWARDED MESSAGE================== [headers killed] > > > Adrian Gschwend schrieb: > > >> Just to keep their expectations realistic. There is _currently_ >> fork() implementation, > > > I guess from context, there's a "no" missing? Ah, sorry. fork() isn't implemented, it's just a stub which complains and returns -1. (The reason is simple, EM code is GPL thus not suitable in a library.) >> neither does select() work on files - file handles and socket >> handles are not _yet_ shared. > > So that limits the range of programs which will work with that new > libc pretty much for the moment (forget about e.g. rsync and XFree, > in fact, probably forget about everything using sockets for now :-( > ). Sockets handles and filehandles are surely something which must be change. Only it requires a design dicussion, an implementation effort and it's a bit risky (in respect to mozilla). BTW. There is quite a number of apps which doesn't use sockets or require them to be filehandles. For instance, I've successfully build doxygen 1.3 (or what ever the CVS contained) a few months using our LIBC. >> Patches are highly appreciated!!! > > > Hm, there's currently a lack of time on my part... :-( wxWindows with > its two releases (2.4.2 stable and 2.5.1 snapshot) that are expected > soon is taking up pretty much of my limited spare time ... Sure, I'm interested in wxWindows, so please continue on that :) Is there anyone trying the new GCC with wxWindows btw. I see some activity with gcc on the mailing, but I didn't catch which one you guys are trying with. If anyone likes to try with the new one I'll do my best to help. >> PPS. Use -Zomf if you like to debug your app. There will be a Beta3 >> or GA by the end of the month which will have 99% working HLL debug >> features. Meaning you can use icsdebug, idebug or idbug (i.e. IBM >> VisualAge and later debuggers) to debug you C and C++ applications. >> > Any chance of making (pm)gdb work with the new compiler version? I > don't care at all about all those other debuggers that I don't have > and probably can't even get/use easily. We're not investing time updating the gdb port. I'm not sure why it's broken, it may be related to emxbind changes and/or changes in stabs output. It's not impossible that IBM might give you a debugger and a linker, we'll see what the mozilla guys can do. (Do I have to repeate that anyone wishing for gdb support are free to propose patches... ;) ) Kind Regards, knut PS. Where are those guys which were so keen on turning EMX upside down, fixing it up, and make the world a better place a few months back? PPS. Someone is working on 64bit I/O. PPPS. There is 'live' GCC and LIBC support on #gccos2 and #netlabs on dropnet (whenever zap or bird is around) :-) ===================END FORWARDED MESSAGE=================== -- Adrian Gschwend at netlabs.org ktk [a t] netlabs.org ------- Free Software for OS/2 and eCS http://www.netlabs.org **= Email 3 ==========================** Date: Thu, 18 Sep 2003 16:15:02 +0200 (CEST) From: Stefan Neis Subject: Re: Re: [Ux2bs] Innotek LIBC On Thu, 18 Sep 2003, Adrian Gschwend wrote: > BTW. There is quite a number of apps which doesn't use sockets or > require them to be filehandles. I suppose I have to use closesocket instead of close to close the socket handles? That's basically the only thing I'm currently worrying about... > (wxWindows and compilers) So far it should be working with gcc-2.8.1 (stock EMX) and 3.2.1 (and possibly some intermediate functions). I'll try to have a look at how Innotek's version handles things ASAP (i.e. one of the next weekends). One thing which is not exactly helpful is the constant renaming of libstdc++: For the sake of EMX' old version (no "c++/g++"), I set CXX to gcc in configure script and then manually have to link in the right library out of stdcpp.a, stdcxx.a, stdc++.a. Question for configure experts: Any idea how to have make configure fall back to "gcc" for a C++ compiler if it can't find any of its standard c++ compilers (c++, g++, CC, aCC, etc.)? > We're not investing time updating the gdb port. I'm not sure why it's > broken, The problem that I know is about changed name mangling in C++ which means that gdb only knows about unreadable function names and also can't match the readable function names to internal representation if you try to set a breakpoint or something similar. > it may be related to emxbind changes and/or changes in stabs > output. Sounds like there might be even more problems... > It's not impossible that IBM might give you a debugger and a > linker, we'll see what the mozilla guys can do. Sounds interesting on the one hand side, OTOH I'm not really keen to use different debuggers on different platforms... ;-) > (Do I have to repeate that anyone wishing for gdb support are free to > propose patches... ;) ) Admitted, that was the remark that I deserved. ;-) > PS. Where are those guys which were so keen on turning EMX upside down, > > fixing it up, and make the world a better place a few months back? I guess they found a different hobby for the moment. I'll try to come back to it later and I suppose others will as well when they have some "idle time" to spend... > PPS. Someone is working on 64bit I/O. Great! Regards, Stefan **= Email 4 ==========================** Date: Thu, 18 Sep 2003 16:15:02 +0200 (CEST) From: Stefan Neis Subject: Re: Re: [Ux2bs] Innotek LIBC On Thu, 18 Sep 2003, Adrian Gschwend wrote: > BTW. There is quite a number of apps which doesn't use sockets or > require them to be filehandles. I suppose I have to use closesocket instead of close to close the socket handles? That's basically the only thing I'm currently worrying about... > (wxWindows and compilers) So far it should be working with gcc-2.8.1 (stock EMX) and 3.2.1 (and possibly some intermediate functions). I'll try to have a look at how Innotek's version handles things ASAP (i.e. one of the next weekends). One thing which is not exactly helpful is the constant renaming of libstdc++: For the sake of EMX' old version (no "c++/g++"), I set CXX to gcc in configure script and then manually have to link in the right library out of stdcpp.a, stdcxx.a, stdc++.a. Question for configure experts: Any idea how to have make configure fall back to "gcc" for a C++ compiler if it can't find any of its standard c++ compilers (c++, g++, CC, aCC, etc.)? > We're not investing time updating the gdb port. I'm not sure why it's > broken, The problem that I know is about changed name mangling in C++ which means that gdb only knows about unreadable function names and also can't match the readable function names to internal representation if you try to set a breakpoint or something similar. > it may be related to emxbind changes and/or changes in stabs > output. Sounds like there might be even more problems... > It's not impossible that IBM might give you a debugger and a > linker, we'll see what the mozilla guys can do. Sounds interesting on the one hand side, OTOH I'm not really keen to use different debuggers on different platforms... ;-) > (Do I have to repeate that anyone wishing for gdb support are free to > propose patches... ;) ) Admitted, that was the remark that I deserved. ;-) > PS. Where are those guys which were so keen on turning EMX upside down, > > fixing it up, and make the world a better place a few months back? I guess they found a different hobby for the moment. I'll try to come back to it later and I suppose others will as well when they have some "idle time" to spend... > PPS. Someone is working on 64bit I/O. Great! Regards, Stefan _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 5 ==========================** Date: Thu, 18 Sep 2003 16:15:02 +0200 (CEST) From: Stefan Neis Subject: Re: Re: [Ux2bs] Innotek LIBC On Thu, 18 Sep 2003, Adrian Gschwend wrote: > BTW. There is quite a number of apps which doesn't use sockets or > require them to be filehandles. I suppose I have to use closesocket instead of close to close the socket handles? That's basically the only thing I'm currently worrying about... > (wxWindows and compilers) So far it should be working with gcc-2.8.1 (stock EMX) and 3.2.1 (and possibly some intermediate functions). I'll try to have a look at how Innotek's version handles things ASAP (i.e. one of the next weekends). One thing which is not exactly helpful is the constant renaming of libstdc++: For the sake of EMX' old version (no "c++/g++"), I set CXX to gcc in configure script and then manually have to link in the right library out of stdcpp.a, stdcxx.a, stdc++.a. Question for configure experts: Any idea how to have make configure fall back to "gcc" for a C++ compiler if it can't find any of its standard c++ compilers (c++, g++, CC, aCC, etc.)? > We're not investing time updating the gdb port. I'm not sure why it's > broken, The problem that I know is about changed name mangling in C++ which means that gdb only knows about unreadable function names and also can't match the readable function names to internal representation if you try to set a breakpoint or something similar. > it may be related to emxbind changes and/or changes in stabs > output. Sounds like there might be even more problems... > It's not impossible that IBM might give you a debugger and a > linker, we'll see what the mozilla guys can do. Sounds interesting on the one hand side, OTOH I'm not really keen to use different debuggers on different platforms... ;-) > (Do I have to repeate that anyone wishing for gdb support are free to > propose patches... ;) ) Admitted, that was the remark that I deserved. ;-) > PS. Where are those guys which were so keen on turning EMX upside down, > > fixing it up, and make the world a better place a few months back? I guess they found a different hobby for the moment. I'll try to come back to it later and I suppose others will as well when they have some "idle time" to spend... > PPS. Someone is working on 64bit I/O. Great! Regards, Stefan **= Email 6 ==========================** Date: Thu, 18 Sep 2003 18:58:33 -0800 From: "Dave and Natalie" Subject: Re: Re: [Ux2bs] Innotek LIBC On Fri, 19 Sep 2003 11:32:54 +1000, Alexander Newman wrote: >> > (The reason is simple, EM code is GPL thus not suitable in a >> library.) >> >> Ehm, what? Sorry, am I the only one who doesn't understand this >> statement? > >I don't either, not that means much ;). Did he leave something out, e.g., 'in an >*Innotek* library? > I think that he means the part of EMX that was written by EM. Some of EMX is GPL and some is BSD licesned. >Given that (most of?) the gcc suite is under GPL, on the face of it this >statment is weird. Unless Innotek are going to reverse engineer the entire >suite, which would seem a little bit like reinventing the wheel (and a total >waste of time). Straange. IRRC GCC is GPL, libc is LGPL. Dave **= Email 7 ==========================** Date: Thu, 18 Sep 2003 19:20:34 +1000 (EST) From: "Alex Newman" Subject: Re: gdk-pixbuf (was Re: Mailman tweaking) On Sun, 14 Sep 2003 23:48:30 -0800, Dave and Natalie wrote: > On Sun, 14 Sep 2003 12:39:42 +1000 (EST), Alex Newman wrote: > > >> Dave > >> ps will look at v 0.22.0 > > > > Well I built v 0.22.0 by running sh configure --prefix=/XFree86, make > Only problem was in building pixbuf-demo.exe. For some reason make > wasn't linking in the graphic libs so I just hacked the makefile. (had > the same problem with 0.11.0). pixbuf-demo runs fine so it seems to > work. Nice demo. > > >I've just tried configure on 0.17.0, without using automake, etc. > >Configure runs fine with CFlAGS/LDFLAGS to build executables (and > >--host=i386-pc-os2-emx), but not with LDFLAGS to build libs. Running > >make on the working configure compiles the object files, but chokes on > >the link step (because it thinks it's building an exec, when it should > >be building a lib?). configure chokes if I leave off --host=, for > >either set of LDFLAGS. > > > I use > CFLAGS='-D__EMX__ -DOS2 -Zmtd -D__ST_MT_ERRNO__ -Zexe -O2 > -fomit-frame-pointer -Dstrncasecmp=strnicmp -Dstrcasecmp=stricmp' That might be it: omit-frame-pointer. The build chokes on (at least) one frame offset when building timescale.exe. I managed to fool my system into building the os2-diffed autoconf/make tools (libtool still eludes me) today, so I may have another crack at gdk-pixbuf, assuming that auto* are sane. Alex. **= Email 8 ==========================** Date: Thu, 18 Sep 2003 21:20:40 -0700 (PDT) From: "Steve Wendt" Subject: Re: Re: [Ux2bs] Innotek LIBC On Fri, 19 Sep 2003 11:32:54 +1000, Alexander Newman wrote: >Given that (most of?) the gcc suite is under GPL, on the face of it this >statment is weird. Unless Innotek are going to reverse engineer the entire libc has to be distributed with applications, e.g. Mozilla, while gcc does not. It's easier to make the IBM lawyers happy when you give them a BSD-licensed library to distribute than a GPL-licensed one. ----------- "Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws." - Plato (427-347 B.C.)