Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Dave Yeo

Pages: [1] 2 3 ... 223
This is what I remember. I thought it would be a good choice cause it worked with Mozilla. But now it seems it's not. Beside the topic of this thread - which compiler/linker combination allows debugging with idebug?

Basically LDFLAGS=-g -Zomf. All the OS/2 linkers should work, the usual is wl.exe as we have the source. We stopped using ilink for Mozilla as it couldn't handle the code size, IIRC the limit was 32 MB

Now I think I've to try again gcc for compiling and linking.

Should be fine. Linking against libcx will give exceptq support, LDFLAGS+=-lcx, -Zmap for map files.

Thanks for explanation. Have to test.

Usually I use makefiles and gcc -c (compile only) and link with whatever I choose in the makefile. Something like -

Code: [Select]
cc = gcc
link = wlink
$(cc) $(objs) ....
$(link) .....

Interesting, guess you'd use the OW crt files then, creating an OW binary. As Lars mentioned, did you use -Zomf as a CFLAG? Or .obj as a suffix and GCC was smart enough to create an OMF object file. Also be hard to do things like the equivalent of -Zhigh-mem. I guess for a simple C program it would work. Perhaps part of the reason for your short exceptq report.
It'll fall down with CPLUS source where you use g++ instead of gcc (same rules for linking). When I moved to GCC 9.2.0 for building Mozilla, it was trying to call a response file from another response file, which doesn't work. Went through similar back around FF4 when the linker cmd line grew to over 64KB (32KB?) and piping the cmd line failed. Then we ended up linking directly with wl.exe, it was hard. This time I linked directly with emxomfld, 873 object files (most consisting of 15 source files) plus libraries created a long cmd line (900 odd words) and was tricky to get working. Here's the sh script I ended up with, renamed to .txt to post. Note the needed libraries.

Hardware / Re: Hardware Compatibility Wishlist for 2022
« on: January 24, 2022, 07:07:09 am »
For some systems, yes. It varies but some systems have holes (used by the hardware I believe) in the memory address map creating the problem that Andreas has, only a couple of GB's accessible in the lower 4GB's of address space.

OK, as you know, #1 only works with OW tools.
I think perhaps your understanding of how GCC works is incomplete. GCC itself will call the linker.
Code: [Select]
gcc -g test.c -o test.exe will compile test to an aout object file and link with ld.exe, it won't produce a debuggable binary (it did way back)
Code: [Select]
gcc -g -Zomf test.c test.exeWill convert the aout object file to omf and link with emxomfld.exe, which depending on environment settings will massage the command line for a native linker,
Code: [Select]
Environment variables:
    The type of linker we're using. Values: WLINK, VAC365, VAC308, LINK386.
        WLINK    wlink.exe from Open Watcom v1.5 or later.
        VAC365   ilink.exe from IBM C and C++ Compilers for OS/2 v3.6 or later.
        VAC308   ilink.exe from Visual Age for C++ v3.08.
        LINK386  link386 form OS/2 install or DDK.
    Name of the linker to use and optionally extra parameters. Spaces in the
    linker name or path is not supported. Quotes are not supported either.
The default values for these two variables are VAC365 and ilink.exe.
There's also environment variables for rc, run emxomfld without arguments to see all options.
So while it is possible to link directly with wlink, it is tricky and really you should use GCC to link.
Both of these work, (going from memory)
Code: [Select]
gcc -g test.c -o test.o
gcc -g -Zomf test.o -o test.exe
Code: [Select]
gcc -g -Zomf test.c -o test.o
gcc -g -Zomf test.o -o test.exe

With CFLAGS=-Zomf, things can get more complex, static libs use emxomfar instead of ar, ranlib will fail on a omf static lib, do SET AR=emxomfar, SET RANLIB=ECHO for that scenario.
Usually omf libs end in .lib and aout ones in .a

Sorry, I was thinking GCC, for OW, I think you'd want something like this,
Code: [Select]
wlink NAME main SYSTEM os2v2 OPTION symfile=PCM9362_ANETCOM.dbg OPTION MAP=main.watmap debug all lib pmprintf.lib file { main.obj }
Hmm, testing it doesn't seem to work here. Anyways see the SYMFILE option in the OW Linker Guide

Hi Andy, sorry, I didn't realize that you were compiling with OW when I posted.
DBG vs XQS: DBG has more info to find where the error occurred. XQS are small and give enough info much of the time. I feel that it is best to add the XQS files to your package and have the DBG files available if needed. I don't know how well exceptq handles the OpenWatcom debug format.
You should be able to add the symfile directive to your wlink options

I see your linking with wl, wl is for GCC, handles dwarf style debug info. Using wc386, you should probably link with wlink. Perhaps this is your problem producing debug info, '-d2 -dDEBUG_BUILD' is what the screensaver uses.
wc386 only produces HLL debugging info and that's currently it. You have to use the OW debugger.
Might of got confused about debugging styles, GCC -Zomf -g produces files that can be debugged in idebug, OW doesn't so your left with its debugger.

Networking / Re: Squid Cache
« on: January 23, 2022, 09:44:19 am »
Hi Harald, basically a Pentium 4 Northwood and as you can see, no SSE3 support. Paul can explain why squid is using SSE3. The trp report is accurate and this build of squid will not run on your processor.
Gotta say that Intel has crappy CPU naming, especially with Xenon's

Hardware / Re: Hardware Compatibility Wishlist for 2022
« on: January 23, 2022, 01:47:04 am »
Somewhat surprising, my T42 with 1GB of ram is quite stable, takes forever to start SeaMonkey but once running, it's fine.
One thing is to set the size of the swap file as fairly large (1GB?) as growing it can cause problems.
The other day I had to reboot as cpp (the preprocessor) was dying trying to allocate 64 KB's of memory, SeaMonkey was still stable.

OK, use something like 'LDFLAGS=-Zlinker option symfile=xxx.dbg' and -g in both CFLAGS (CXXFLAGS) and LDFLAGS to get the dbg file.

Networking / Re: Squid Cache
« on: January 22, 2022, 06:44:09 pm »
Tried my old squid, which is working fine as I'm posting this using it. The log also has :DNS Socket created at, FD 9" but works. Here's the log for comparison, no invalid arguments, the cache was dirty after 4 years :)

Hardware / Re: Hardware Compatibility Wishlist for 2022
« on: January 22, 2022, 06:24:44 pm »
Thanks, OS4User. RAM disk is not an option, when only 1 GB or less is recognized for the system. AMD systems suffer since a longer time from this, with 1.5 - 2 GB. According to Sigurd, newer Intel (i7) systems have that problem, too.

Virtualization seems to be the only option then.

Are there any newer systems that support 3 GB?

Even with only 1.5GB of actual ram recognized by the system, you still should have about 3.5 GB of memory space, it'll just swap and the swap file can go on the ram disk.
At one point I was using a system with 1.5GB's of ram installed, linking xul.dll required VIRTUALADDRESSLIMIT set to 3072 to avoid running out of memory, the swap file would grow to close to 2 GB (occasionally over which killed the system with a swap file full error, there seems to be a 2GB limit), things would be slow but work.
With 1.5 GB of ram under normal usage you should only see light swapping.

Hi, the xqs files should be enough to create a trp report and it looks like you are correctly creating them. And of course wl.exe is a patched version of wlink.exe to handle dwarf debugging code. IIRC, (have to look at the mozilla source), the symfile directive creates the dbg file. You do have to build with -g to get the debug info to begin with.
To double check the debug status, try running the binary under an OS/2 (not Watcom) debugger.
Perhaps simply exceptq's exception handler isn't handling the exception correctly and it is falling through to the default exception handler, which creates the entry in popuplog.

Networking / Re: Squid Cache
« on: January 22, 2022, 05:45:13 pm »
Tried it, seems to just sit there forever trying to load a page. In the log I see,
Code: [Select]
2022/01/22 08:29:29 kid1| ERROR: loading file '/squid/share/errors/templates/ERR_PROTOCOL_UNKNOWN': (2) No such file or directory
2022/01/22 08:29:29 kid1| WARNING: failed to find or read error text file ERR_PROTOCOL_UNKNOWN

Which is missing. Have to try an older browser in case it is SeaMonkey/Firefox (tried both) that is broken.

Edit: seems to be stuck listening at, which won't work, there's other invalid arguments even using  my old working squid.conf (almost the same), attaching log.

Networking / Re: Squid Cache
« on: January 22, 2022, 05:12:14 pm »
Hi Harald, unluckily given Intel's crappy naming, Xeon doesn't say much besides being the high end of whatever Intel was making. Seems "000D7A99 >FISTTP QWORD " is SSE3 and I guess your CPU doesn't support it and is pre-Prescott if I understand it right.
Attached is cpuinfo.exe, that'll list your CPU characteristics if you want to post them.
Paul can comment on whether this was assembly or C code.

Networking / Re: Squid Cache
« on: January 22, 2022, 06:08:11 am »
In theory, on a client, especially one with a bad/slow connection, using the cache speeds things up as many responses come from the cache instead of over the internet. It was why I used squid when I was on dial up. In practice I found less and less benefit as things went to HTTPS as it is hard to cache encrypted content and stopped using it.

Pages: [1] 2 3 ... 223