From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Tue, 26 Feb 2002 04:16:34 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 147 ************************************************** Monday 25 February 2002 Number 147 ************************************************** Subjects for today 1 sendmail 8-12-0 : Stepan Kazakov 2 Re: Building \emx\lib : James Cannon 3 Re: Gnat 3.14p OS/2 binaries available : DWParsons at t-online.de (Dave Parsons) 4 Re: Building \emx\lib : Holger Veit 5 Re: Using configure scripts : John Poltorak 6 Re: gcc 3.0.3. _optlink questions for Andy : Holger Veit 7 Re: Iconv is fully available now btw : Andrew Zabolotny" 8 Re: gcc 3.0.3. _optlink questions for Andy : Andrew Zabolotny" 9 Re: GCC 3.0.2 problems : Andrew Zabolotny" 10 Re: cat.exe fails for long command lines whe called from unix-like shell : lamikr 11 cc1plus in gcc 3.0.3 ? : John Poltorak 12 Re: cc1plus in gcc 3.0.3 ? : John Poltorak 13 Re: Building \emx\lib : John Poltorak 14 Re: cc1plus in gcc 3.0.3 ? : John Poltorak 15 Re: cc1plus in gcc 3.0.3 ? : MS" 16 Re: cc1plus in gcc 3.0.3 ? : MS" 17 Re: Building \emx\lib : Henry Sobotka 18 Re: cat.exe fails for long command lines whe called from unix-like shell : Gerhard Arnecke" 19 Re: Building \emx\lib : csaba.raduly at sophos.com 20 Re: gcc 3.0.3. _optlink questions for Andy : Henry Sobotka 21 Re: GCC 3 name unmangling possible? : John Poltorak 22 GCC 3 name unmangling possible? : MS" 23 Re: Building \emx\lib : Holger Veit 24 Re: GCC 3 name unmangling possible? : Holger Veit **= Email 1 ==========================** Date: Tue, 26 Feb 2002 01:59:53 -0500 From: Stepan Kazakov Subject: sendmail 8-12-0 sendmail 8-12-0 at hobbes.nmsu.edu/pub/incoming/ with openssl / smtp auth.. -- madded. [Red Hot Chili Hackers] **= Email 2 ==========================** Date: Tue, 26 Feb 2002 08:08:42 -0800 (PST) From: James Cannon Subject: Re: Building \emx\lib Can NASM be used instead of MASM? NASM can build 32-bit OS/2 .OBJs which cna be compiled. --- John Poltorak wrote: > On Tue, Feb 26, 2002 at 09:05:17AM +0100, Holger > Veit wrote: > > > > > > > > There's a directory, \emx\src\lib, which > seems to contain all the > > > > required source along with Makefiles, but > there is no option to make all, > > > > so I don't really know where to start. > > > > > > > > Any hints would be appreciated. > > > > > > emx\doc\build.doc > > > > > > in case anyone wants to know. > > > > > > Do I really need MASM to build emx\lib? > > > > Yes. > > > Assuming, I can get MASM included on the PATH in > DMAKE.INI, can I expect > to build all the libs using? :- > > make mkdir > make all-os2-bsd > > from emx\src\lib > > It isn't all that clear (at least to me...) whether > 'all-os2-bsd' includes > c-st, c_alias, c_dllnrt, libgcc etc > > > > Holger > > > > -- > > Please update your tables to my new e-mail > address: > > holger.veit$ais.fhg.de (replace the '$' with ' at ' > -- spam-protection) > > > > > -- > John > > ===== Sincerely, James Cannon Using OS/2 Warp in the beautiful Wine Country of Northen California! __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com **= Email 3 ==========================** Date: Tue, 26 Feb 2002 08:25:24 +0100 (CET) From: DWParsons at t-online.de (Dave Parsons) Subject: Re: Gnat 3.14p OS/2 binaries available On Mon, 25 Feb 2002 23:28:56 -0500, Vincent Marciante wrote: > > Hi Dave, > > First of all, thanks for making this available! Your welcome > Two questions: > > 1) There is no gdb.exe included - what one should be used? > The one from 3.12p? No, it is in a different source archive. I understand that there is now a visual debugger for Gnat, but I haven't looked at it yet. I didn't try to do any debugging with 3.14p, but when I built 3.13p I used an eariler gdb (GDB 4.16.gnat.3.12w-20) and that worked ok. I think it should work, just try it. From the gdb.diff file that did come with Gnat, it would seem that GDB is now at 4.17. > 2) I always get mixed up with "/" vs "\" in the environmental > variables, then I just got to thinking that maybe I have been > running from the wrong type of shell all these years - should > gnatmake be run from an OS/2 command line (cmd.exe) or from > a unix type shell like bash? OS/2 command line ie cmd.exe -- Dave **= Email 4 ==========================** Date: Tue, 26 Feb 2002 09:05:17 +0100 From: Holger Veit Subject: Re: Building \emx\lib On Mon, Feb 25, 2002 at 09:30:34PM +0000, John Poltorak wrote: > On Mon, Feb 25, 2002 at 02:37:26PM +0000, John Poltorak wrote: > > > > > > Does anyone have any tips on building \emx\lib from \emx\src? > > > > > > There's a directory, \emx\src\lib, which seems to contain all the > > required source along with Makefiles, but there is no option to make all, > > so I don't really know where to start. > > > > Any hints would be appreciated. > > emx\doc\build.doc > > in case anyone wants to know. > > Do I really need MASM to build emx\lib? Yes. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 5 ==========================** Date: Tue, 26 Feb 2002 09:55:20 +0000 From: John Poltorak Subject: Re: Using configure scripts On Wed, Feb 20, 2002 at 10:36:48PM +0100, bart-news at netage.nl wrote: > > > Hi, > > I'm new to this list so it might be an old subject. > I'm currently porting gphoto2 to OS/2 with success. I never got the configure > and automake stuff running so Simply created my own build environment. > > what do you recomend ?? use my own build environment for OS/2 or use the > configure.in files etc. > and how do I make it work ?? whats neede what is a good start ?? My personal view is that Open Source apps should build the same way on OS/2 as they do any Unix platform, with the possible addition of running autoconf before configure. It can be difficult getting the correct build environment set up and the situation is changing with the development of the next version of autoconf which seems to aim to be more friendly to DOS-like filesystems, but in the meantime you may be able to make use of the OS/2 port of Autoconf v2.50 along with Automake which you can find here:- ftp://unixos2.com/pub/unixos2/unixos2-current/unixos2/d1/autoconf.zip ftp://unixos2.com/pub/unixos2/unixos2-current/unixos2/d1/automake.zip > Thx in advance > > FYI I do have write access to gphoto2 CVS > > With Regards > Bart van Leeuwen > > -- John **= Email 6 ==========================** Date: Tue, 26 Feb 2002 11:28:00 +0100 From: Holger Veit Subject: Re: gcc 3.0.3. _optlink questions for Andy On Tue, Feb 26, 2002 at 12:55:33PM +0300, Andrew Zabolotny wrote: > On Sat, 23 Feb 2002 16:56:56 -0500, Henry Sobotka wrote: > >How feasible would it be to add a -moptlink flag to make that calling > >convention the default? > Um... that's interesting question. I don't think it makes sense since all the > EMX runtime libraries are not _Optlink, and how the compiler will determine > that the extern declaration is a libc function or not? I think VAC++ headers > take care about the "default optlink" flag and declare all C library functions > as _cdecl; emx headers don't. Thus, it is a problem not just with the > compiler, but with EMX headers. Once the Optlink mechanism in the compiler is bullet proof and compatible with VACPP, there is no reason why we coouldn't modify the headers to explicitly declare APIENTRY (a.k.a. _System) for each publicly exported function. This implies that gcc will understand the _System keyword as well (does it?), but this shouldn't be too complicated. > >I noticed that _optlink only kicks in with optimization. Without -O or > >higher, args are moved from the registers to the stack instead of used > >in situ. Is this a bug or just an unfortunate necessity due to gcc > >internals and implementation details or...? > ? Do you mean a _optlink function called from non-optimized code will get its > arguments on the stack? Or you mean a non-optimized _optlink function receives > its arguments in the registers but instantly puts them somewhere on the stack > and then takes them from there? In the later case it is not a problem at all, > because I've heard the old IBM C compiler does the same even with "optimized" > code :-) The compiler does not track register usage when optimizer is turned > off (in particular, it cannot guarantee that the register parameters won't be > overwriten by a intermediate operation), thus it puts them into local memory > in the prologue of the function, and then uses them as normal memory operands. Even VAC++ does this once in a while. While we are there with changing the code generated by the compiler, would it be possible to adjust another deficiency of gcc, namely the assumption that DS=ES=SS? This would enable gcc for development of the 32 bit part of drivers. Or is there already an implicit guarantee? From kernel/driver development, it is known that you have to convert a stack-based address to a DS-based address by adding an offset found in a kernel-exported variable named _TKSSBase if you want to submit it to a pointer argument of another procedure. This is required as well for drivers written in VAC++. It is difficult for me to think about a situation where gcc really accesses stack addresses through DS or ES, but if the x86 instructions permit such access, this should be modified. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 7 ==========================** Date: Tue, 26 Feb 2002 12:27:52 +0300 From: "Andrew Zabolotny" Subject: Re: Iconv is fully available now btw On Mon, 4 Feb 2002 11:17:04 +0100, Holger Veit wrote: >> The only problem is that I don't know whenever there is a reason to make >> separate such a small package (it will be about 10K in zip :) >If it is essential for quite a number of applications (and I guess it is >for several internationalized GNU apps), then it should be added to the >minimal runtime system - to avoid such typical problems as "I have installed >GIMP, and it says LIBINTL missing". The latter is IMHO an indicator of >too much salami-tactics when building packages. I fully agree with you, but the problem is that there is just only one "standard runtime system" for now - it is emxrt.zip. I know there is John Poltorak's effort in creating something similar - as soon as I'll have something to add to his runtime package, I will contact him. Greetings, _\ndy **= Email 8 ==========================** Date: Tue, 26 Feb 2002 12:55:33 +0300 From: "Andrew Zabolotny" Subject: Re: gcc 3.0.3. _optlink questions for Andy On Sat, 23 Feb 2002 16:56:56 -0500, Henry Sobotka wrote: >Simple tests indicate that gcc's _optlink is compatible with VAC++'s >_Optlink both ways: I was able to create an _optlink DLL with gcc and >use it with an icc-built program, as well as run a gcc-built program >with a VAC++ version of glib.dll. That's nice to hear because I have not tested it at all - I don't have VAC++. >Is there any particular reason for the case difference between _optlink >and _Optlink? My dumbness :-) In the 3.0.3 release I will rename it into _Optlink. >How feasible would it be to add a -moptlink flag to make that calling >convention the default? Um... that's interesting question. I don't think it makes sense since all the EMX runtime libraries are not _Optlink, and how the compiler will determine that the extern declaration is a libc function or not? I think VAC++ headers take care about the "default optlink" flag and declare all C library functions as _cdecl; emx headers don't. Thus, it is a problem not just with the compiler, but with EMX headers. >I noticed that _optlink only kicks in with optimization. Without -O or >higher, args are moved from the registers to the stack instead of used >in situ. Is this a bug or just an unfortunate necessity due to gcc >internals and implementation details or...? ? Do you mean a _optlink function called from non-optimized code will get its arguments on the stack? Or you mean a non-optimized _optlink function receives its arguments in the registers but instantly puts them somewhere on the stack and then takes them from there? In the later case it is not a problem at all, because I've heard the old IBM C compiler does the same even with "optimized" code :-) The compiler does not track register usage when optimizer is turned off (in particular, it cannot guarantee that the register parameters won't be overwriten by a intermediate operation), thus it puts them into local memory in the prologue of the function, and then uses them as normal memory operands. Greetings, _\ndy **= Email 9 ==========================** Date: Tue, 26 Feb 2002 12:58:26 +0300 From: "Andrew Zabolotny" Subject: Re: GCC 3.0.2 problems On Sun, 10 Feb 2002 21:56:21 +0100 (MEZ), MS wrote: >I have narrowed down the problem with building STLport on OS/2. STLport is >including which in turn includes some other headers. I always get >the errors: You should install ctype.h from the latest emx fix (0.9d if I'm not mistaken). Previous headers declare isspace & Co as "#define"s, and STL #undef's all these macros (for unknown to me reasons). The latest ctype.h declares isspace & Co as inline functions for C++, thus #undef doesn't change it. Greetings, _\ndy **= Email 10 ==========================** Date: Tue, 26 Feb 2002 13:47:48 +0100 From: lamikr Subject: Re: cat.exe fails for long command lines whe called from unix-like shell 32 bit CMD has solved this problem in some way. I know this because with it I can launch Java-applications with very long classpaths as an argument. I just wish that IBM could fix this part of 16 bit code from OS/2... Mika Holger Veit wrote: > On Wed, Feb 13, 2002 at 08:08:39AM -0600, Jerrold Heyman wrote: > > On 13 February 2002 at 11:53, Holger Veit wrote: > > >On Wed, Feb 13, 2002 at 11:16:10AM +0100, Stefan Neis wrote: > > >> On Tue, Feb 12, 2002 at 11:37:45PM +0100, Thomas Hoffmann wrote: > > >>> > > >>> # cat ../../../../../../../tmp/ctt/1234567890/1234567890/*.Rd >nul > > >>> cat: No such file or directory > [...] > > > It is an OS/2 limitation: DosExecPgm uses a combined 16 bit segment for > > > both the environment strings as well as the argument vector. The sum > > > mustn't exceed 64K. This is one reason why I don't like adding bazillions > > > of environment variables to CONFIG.SYS (%UNIXROOT% must be enough), they > > > reduce the available space for arguments. ...Thinking about this a bit > > > more, it should be possible to inject the environment vector in a different > > > way - you could call DosExecPgm with a NULL for the env argument, so not to > > > inherit ENV from the parent - this is OTOH no problem, because I tap the > > > DosExecPgm API anyway, so I can feed the program anything I like it to see... > > > Hmmm, so this should work. But the limit for the argv vector =64K remains > > > for now. > > > > > > Holger > > > > This problem doesn't just exist on OS/2. I support the Cygnus tools on NT > > (along with EMX on OS/2) for internal development, and have run across the > > same problem concerning large path names. After debugging for a while, > > we came to the conclusion that it was an NT filesystem/pathname length > > issue. > > > > In our case it was the cp command that was failing - even though if I did > > the equivalent command within a DOS prompt, it worked just fine... > > filesystem/pathname length is a different issue than the problem > above. It is clear that > ../../../../../../../tmp/ctt/1234567890/1234567890/*.Rd > is a pathological name which *might* result in a fully decoded name > longer than 260 chars depending on what it resolved to (and symbolic > links might add more to the whole confusion. It is not a file system > issue as well, because the filesystem won't see the argv vector; it is > passed one decoded filename after the other, and should allow access to > any number of files by a process unless the maximum number of open files > per process is exhausted (DosQuery/SetMaxFH). > > The culprit is the wildcard expansion of the shell which constructs an > extremely lengthy argv vector. Doing _wildargs() expansion in the > program itself, as suggested for DOS/OS2 apps, will in contrast > work here, but is of course not Unix compatible. Unix typically > does not have a 16 bit limit on argv and envp. That issue (restrictions > on DosExecPgm) is hard to fix completely, because the code behind that, > in DOSCALL1.DLL and OS2KRNL is extremely scattered with 16 bit calls > which don't like segments > 64K. > > Holger > > -- > Please update your tables to my new e-mail address: > holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 11 ==========================** Date: Tue, 26 Feb 2002 14:12:19 +0000 From: John Poltorak Subject: cc1plus in gcc 3.0.3 ? Should there be a cc1plus.exe in gcc v3.0.3 or should the one from v2.8.1 be used instead? -- John **= Email 12 ==========================** Date: Tue, 26 Feb 2002 14:38:18 +0000 From: John Poltorak Subject: Re: cc1plus in gcc 3.0.3 ? On Tue, Feb 26, 2002 at 03:30:13PM +0100, MS wrote: > On Tue, 26 Feb 2002 14:12:19 +0000, John Poltorak wrote: > > > > >Should there be a cc1plus.exe in gcc v3.0.3 or should the one from v2.8.1 > >be used instead? > > Look into \emx\lib\gcc-lib\i386-pc-os2_emx\3.0.2 ... I don't see a cc1plus.exe there.... > Regards, > > > Martin Schafföner > > -- John **= Email 13 ==========================** Date: Tue, 26 Feb 2002 14:48:07 +0000 From: John Poltorak Subject: Re: Building \emx\lib On Tue, Feb 26, 2002 at 09:05:17AM +0100, Holger Veit wrote: > > > > > > There's a directory, \emx\src\lib, which seems to contain all the > > > required source along with Makefiles, but there is no option to make all, > > > so I don't really know where to start. > > > > > > Any hints would be appreciated. > > > > emx\doc\build.doc > > > > in case anyone wants to know. > > > > Do I really need MASM to build emx\lib? > > Yes. Assuming, I can get MASM included on the PATH in DMAKE.INI, can I expect to build all the libs using? :- make mkdir make all-os2-bsd from emx\src\lib It isn't all that clear (at least to me...) whether 'all-os2-bsd' includes c-st, c_alias, c_dllnrt, libgcc etc > Holger > > -- > Please update your tables to my new e-mail address: > holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) > -- John **= Email 14 ==========================** Date: Tue, 26 Feb 2002 15:04:07 +0000 From: John Poltorak Subject: Re: cc1plus in gcc 3.0.3 ? On Tue, Feb 26, 2002 at 03:50:27PM +0100, MS wrote: > On Tue, 26 Feb 2002 14:38:18 +0000, John Poltorak wrote: > > >> Look into \emx\lib\gcc-lib\i386-pc-os2_emx\3.0.2 ... > > > >I don't see a cc1plus.exe there.... > > Have you unpacked gcc-os2-3.0.2-beta-gpp.zip into the right place and tested g++, e.g. g++ -v ? oops.... Thanks, for pointing that out. > Martin Schafföner > > -- John **= Email 15 ==========================** Date: Tue, 26 Feb 2002 15:30:13 +0100 (MEZ) From: "MS" Subject: Re: cc1plus in gcc 3.0.3 ? On Tue, 26 Feb 2002 14:12:19 +0000, John Poltorak wrote: > >Should there be a cc1plus.exe in gcc v3.0.3 or should the one from v2.8.1 >be used instead? Look into \emx\lib\gcc-lib\i386-pc-os2_emx\3.0.2 ... Regards, Martin Schafföner **= Email 16 ==========================** Date: Tue, 26 Feb 2002 15:50:27 +0100 (MEZ) From: "MS" Subject: Re: cc1plus in gcc 3.0.3 ? On Tue, 26 Feb 2002 14:38:18 +0000, John Poltorak wrote: >> Look into \emx\lib\gcc-lib\i386-pc-os2_emx\3.0.2 ... > >I don't see a cc1plus.exe there.... Have you unpacked gcc-os2-3.0.2-beta-gpp.zip into the right place and tested g++, e.g. g++ -v ? Martin Schafföner **= Email 17 ==========================** Date: Tue, 26 Feb 2002 16:29:26 -0500 From: Henry Sobotka Subject: Re: Building \emx\lib csaba.raduly at sophos.com wrote: > > Most GCC assembly stuff is likely to be for GAS (AT&T syntax). FWIW, gcc 3.x can apparently handle Intel syntax (-mintel?). Haven't played with it yet. h~ **= Email 18 ==========================** Date: Tue, 26 Feb 2002 17:05:28 +0100 (MEZ) From: "Gerhard Arnecke" Subject: Re: cat.exe fails for long command lines whe called from unix-like shell Conc. CMD.EXE: There are new versions of CMD.EXE, f. i. here: 20.02.02 18.36 100620 0 cmd.exe 20.02.02 18.36 12980 0 cmd.sym with a special kernel for special functions. And now a little questions nearby for experts: What happens for this command type cmd* > cmd.txt GA **= Email 19 ==========================** Date: Tue, 26 Feb 2002 17:39:52 +0000 From: csaba.raduly at sophos.com Subject: Re: Building \emx\lib On 26/02/2002 16:08:42 James Cannon wrote: >Can NASM be used instead of MASM? NASM can build >32-bit OS/2 .OBJs which can be compiled. > I think the point of MASM here is to build 16-bit EMX-specific sources. Most GCC assembly stuff is likely to be for GAS (AT&T syntax). -- Csaba Ráduly, Software Engineer Sophos Anti-Virus email: csaba.raduly at sophos.com http://www.sophos.com US Support: +1 888 SOPHOS 9 UK Support: +44 1235 559933 **= Email 20 ==========================** Date: Tue, 26 Feb 2002 18:52:53 -0500 From: Henry Sobotka Subject: Re: gcc 3.0.3. _optlink questions for Andy Andrew Zabolotny wrote: > > In the 3.0.3 release I will rename it into _Optlink. Yay! Though that means EMX's will need tweaking. > ? Do you mean a _optlink function called from non-optimized code will get its > arguments on the stack? Or you mean a non-optimized _optlink function receives > its arguments in the registers but instantly puts them somewhere on the stack > and then takes them from there? In the code I was looking at, both caller and optlinked callee were unoptimized. Since _Optlink is a calling convention and not an optimization in the strict sense of what happens to code compiled with -O or higher, I expected to see the caller load the registers before issuing the call even in unoptimized code. In that context, optimization of _Optlink itself might involve things like bending the rules (e.g. pushing args on the stack before the call if they're only used late in the callee and the initial instructions in the latter push them from the registers to the stack to process local variables); skipping the steps of saving/restoring the caller's %ebx, %esi and %edi if unused; or even (in an ideal compiler) rearranging the args if necessary, e.g. putting a "conforming" arg 4 in %edx instead of arg 2 because it's used right at the outset and arg 2 only later in the function, or even reshuffling the trio loaded into %eax, %edx and %ecx so that they're in the best place for the ensuing instructions. (Any such convention-breaking optimizations, if ever implemented, would have to be controllable to maintain compatibility with VAC++.) I see no need for the compiler to track registers in unoptimized _Optlink calls. The convention is essentially a contract between caller and callee, so all the compiler has to do is adhere to it in the caller's prolog by putting parameters where the callee expects to find them based on the rules, and generate corresponding code for the callee that can safely assume they're there because _Optlink was specified in the prototype. Also, since loading the registers for the callee is the final stage before the call, the only intervening operations involve registers not used for args (%ebp, %esp, %ebx, %esi and %edi). In other words, the rules of the convention effectively serve as the tracking mechanism by specifically defining where call parameters go. h~ **= Email 21 ==========================** Date: Tue, 26 Feb 2002 19:27:06 +0000 From: John Poltorak Subject: Re: GCC 3 name unmangling possible? On Tue, Feb 26, 2002 at 08:12:14PM +0100, Holger Veit wrote: > On Tue, Feb 26, 2002 at 07:45:20PM +0100, MS wrote: > > Hello, > > > > as the title is suggesting, I am wondering if it is possible to find out the unmangled names of the symbols > > defined in an a.out object file? I know that the ABI has changed with GCC 3, so emxexp only gives the > > mangled names. I would need to know that to compare the results of compiling STLport with gcc 3 and pgcc > > 2.95.3. > > Haven't checked too intensively, but there should be a c++filt.exe from > binutils that demangles names. At least last time I checked original > 2.9.x binutils, there had been one. There is a c++filt.exe in binutils 2.11.2 *and* gcc-gpp 3.0.3... I assume we should use the newer one. > Holger > > -- > Please update your tables to my new e-mail address: > holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) > -- John **= Email 22 ==========================** Date: Tue, 26 Feb 2002 19:45:20 +0100 (MEZ) From: "MS" Subject: GCC 3 name unmangling possible? Hello, as the title is suggesting, I am wondering if it is possible to find out the unmangled names of the symbols defined in an a.out object file? I know that the ABI has changed with GCC 3, so emxexp only gives the mangled names. I would need to know that to compare the results of compiling STLport with gcc 3 and pgcc 2.95.3. Regards, Martin Schafföner **= Email 23 ==========================** Date: Tue, 26 Feb 2002 20:10:10 +0100 From: Holger Veit Subject: Re: Building \emx\lib On Tue, Feb 26, 2002 at 08:08:42AM -0800, James Cannon wrote: > Can NASM be used instead of MASM? NASM can build > 32-bit OS/2 .OBJs which cna be compiled. This is not the point. The point is MASM syntax - precise syntax. I have spent quite some time already to modify assembler code from MASM to ALP (not EMX stuff) - MASMs (different versions, different bugs) have their particular preferences how assembler code ouht to look like. You might try NASM or ALP, but I am sceptic they will pass without severe restructuring of the code. Besides, the assembler code in EMX is mixed 16/32 bit. Holger > > --- John Poltorak wrote: > > On Tue, Feb 26, 2002 at 09:05:17AM +0100, Holger > > Veit wrote: > > > > > > > > > > There's a directory, \emx\src\lib, which > > seems to contain all the > > > > > required source along with Makefiles, but > > there is no option to make all, > > > > > so I don't really know where to start. > > > > > > > > > > Any hints would be appreciated. > > > > > > > > emx\doc\build.doc > > > > > > > > in case anyone wants to know. > > > > > > > > Do I really need MASM to build emx\lib? > > > > > > Yes. > > > > > > Assuming, I can get MASM included on the PATH in > > DMAKE.INI, can I expect > > to build all the libs using? :- > > > > make mkdir > > make all-os2-bsd > > > > from emx\src\lib > > > > It isn't all that clear (at least to me...) whether > > 'all-os2-bsd' includes > > c-st, c_alias, c_dllnrt, libgcc etc > > > > > > > Holger > > > > > > -- > > > Please update your tables to my new e-mail > > address: > > > holger.veit$ais.fhg.de (replace the '$' with ' at ' > > -- spam-protection) > > > > > > > > > -- > > John > > > > > > > ===== > Sincerely, > James Cannon > > Using OS/2 Warp in the beautiful Wine > Country of Northen California! > > __________________________________________________ > Do You Yahoo!? > Yahoo! Sports - Coverage of the 2002 Olympic Games > http://sports.yahoo.com -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 24 ==========================** Date: Tue, 26 Feb 2002 20:12:14 +0100 From: Holger Veit Subject: Re: GCC 3 name unmangling possible? On Tue, Feb 26, 2002 at 07:45:20PM +0100, MS wrote: > Hello, > > as the title is suggesting, I am wondering if it is possible to find out the unmangled names of the symbols > defined in an a.out object file? I know that the ABI has changed with GCC 3, so emxexp only gives the > mangled names. I would need to know that to compare the results of compiling STLport with gcc 3 and pgcc > 2.95.3. Haven't checked too intensively, but there should be a c++filt.exe from binutils that demangles names. At least last time I checked original 2.9.x binutils, there had been one. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection)