fixed sorry, typo'ed

Are you building this for ELKS? Or are you just using OpenWatcom to build for DOS? I am pretty familiar with the OWC settings required for ELKS but not familiar with the options in general.

For ELKS, please take a look at the ewcc and ewlink scripts in elks/tools/bin. I have spent a lot of time on them and we use the owcc wrapper for ELKS building rather than calling WCL directly. The general idea was to be able to say ewcc file.c file2.c file3.c, then ewlink file.obj file2.obj file3.obj and have it all work. The many many different options for WCL and OWCC have been consolidate into the the ewcc and ewlink scripts. (Of course, what would be nice would be to write a script 'ewcc' that was a true 'cc-like' wrapper around files and invoked the compiler and linker appropriately for file type but I haven't had time to complete that yet).

When building for ELKS, it is fairly important that you do NOT include any WATCOM/h directory in the include search path. This happens to be where your current compilation is dying. It is picking up <strings.h> from OWC rather than from ELKS libc/include.

Your build script looks quite nice and fairly fancy. I don't have to debug that script or look at the many options for WCL, but will try to help you get the daemon compiled for ELKS.

In summary, it looks like your problem is that the compile is including a WATCOM .h file, which is not supported by ELKS. The mess of OWC .h files is not something I want to get into. Thus, the important WATCOM .h files that we DO work with have been copied to libc/include/watcom/*.h. If/when your program uses a non-approved .h file, we can deal with getting it copied over, but that is not (yet) what is happening here. So remove the -IWATCOM/h from your build and/or look at how it is handled in ewcc.

[EDIT: I just happened to notice that ewcc does not yet have the WATCOM/h removed, so you should have the following instead:]

ELKSLIBCINCLUDE=$TOPDIR/libc/include
ELKSINCLUDE1=$TOPDIR/include
ELKSINCLUDE2=$TOPDIR/elks/include
#WATCINCLUDE=$WATCOM/h <--- comment this line out

source $TOPDIR/libc/watcom.model

CCFLAGS="\
    -bnone                          \
    -mcmodel=$MODEL                 \
    -march=i86                      \
    -Os                             \
    -std=c99                        \
    -Wc,-fpi87                      \
    -Wc,-zev                        \
    -Wc,-zls                        \
    -Wc,-x                          \
    -fnostdlib                      \
    -Wall -Wextra                   \
    -Wc,-wcd=303                    \
    -I$ELKSLIBCINCLUDE              \
    -I$ELKSINCLUDE1                 \
    -I$ELKSINCLUDE2                 \
    -I$WATCINCLUDE                  \ <--- delete this line
    "

You should be able to use the above information in order to get your script to work and get better results. Please let me know how you are doing on it, thanks!

ah yes things are making much more sense now, i removed watcom from my PATH.

I seem to be hitting this error
error.txt

Ok. Geez, my instructions as well as the current ewcc are still messed up (fix coming).

Now, you also need to add in a third include, which is where we have copied some watcom header files: libc/include/watcom.

Thus, the proper list should be:

ELKSLIBCINCLUDE=$TOPDIR/libc/include
ELKSINCLUDE1=$TOPDIR/libc/include/watcom
ELKSINCLUDE2=$TOPDIR/elks/include

That is, for your build, you need to include $TOPDIR/libc/include/watcom also.

Actually, the proper order should not matter, but could:

ELKSLIBCINCLUDE=$TOPDIR/libc/include
ELKSINCLUDE1=$TOPDIR/elks/include
ELKSINCLUDE2=$TOPDIR/libc/include/watcom

/usr/bin/watcom/h/strings.h(55): Error! E1009: Expecting ')' but found '('

Look at the error: you're including WATCOM's strings.h. Bad, change it. Reread my above comments, we're not talking about OWC PATH but include paths. I don't know how WCL works, as I mentioned, I only use owcc.

Look through the error messages, they are somewhat explanatory, then get some sleep!

src/ngircd/client.c(28): Error! E1055: Unable to open 'strings.h'

Check if #include "strings.h" or <strings.h>, needs to be the latter.

src/ngircd/client.c(94): Error! E1031: Name 'h_name' not found in struct/union hostent

This one is more tricky - I have no idea: there is no struct hosting on ELKS, so you'll have to dig down more to see where or what it is.

This could be something to do with Watcom TCP. The big problem you are likely to have, from what I was reading when you first posted this, is that this program uses Watcom TCP. I don't think it is compatible with UNIX/BSD sockets, which is what ELKS uses. So the TCP access portions may need rewriting.

src/ngircd/client.c(79): Error! E1011: Symbol 'PACKAGE' has not been declared

I have no idea what this is, there is no PACKAGE in ELKS C library. You can grep the Watcom clib sources for it, but that usually gets complicated very fast.

how do i disable watcoms tcp?

You can't, although I'm not sure what the compiler errors are other than that. What I'm talking about is the source code to NGIRCD is written for Watcom TCP. It may have to be recoded for UNIX/ELKS sockets. I haven't looked at the source code so I can't tell. You're welcome to chase down some of the source lines that the errors show and post them, or post a link so I can click it, as I am short on time myself.

No problem, but this undoubtedly has to do with your Makefile etc having been setup improperly with regards to the required include file order, and lots of other little things. This is why I wrote the ewcc script. It is too complicated to explain all that is required, but it is all in the ewcc script. Try running ewcc ngircd.c or whatever the filename you're trying to compile is.

That should work better. After that, you can study what ewcc does versus what you are doing in your Makefile, which hopefully is the issue. You can use ewcc for each of your source files, then ewlink *.obj to link, and its all done for you. I can't debug the many options OWC has, which is why I prepared a script to use for ELKS.

code that is throwing the error.

I can't compile that without removing all the local .h file includes, because I don't have them. I did comment them all out and ran ewcc and didn't get the error your getting though, which is good.

I hope that helps?

Yes, nice. But does it work? I don't think the ewcc script is smart enough to accept "-o file" or -c, etc. It was written quickly with the intent to compile a single .c file quickly, using the OWC toolchain and having the includes/defines/settings set compatibly for ELKS.

What I had in mind was for you to try manually compiling one or each of the .c files, rather than through a complex script, so that you/we could more easily understand the errors that might be produced from compatible compilation of the program you're porting using the OWC compiler. Then at least we know we have the compiler switches and include file ordering correct, and we can see what other errors there are. After that, if you want to make a more complex build, then moving to a complex make script will be easier.

I say all this because we haven't been able to determine whether it is your setup or the .c files themselves that are most contributing to making this port hard. Also, I doubt that ewcc will work other than manually, unless it is extended to be more like a cc replacement.

In summary, what happens when you just run "ewcc ngircd.c"? That is the file you had the problems with shown above, right?

No problem, take your time! I plan on updating ewcc and ewlink to be more useful also, when I have a bit more time.

It sounds like possibly another issue of the include files not being setup properly - I would have to see the source file it came from and how it is being compiled. Looking at sys/time.h, it looks pretty normal. Are you compiling using ecc or a different method?
I never heard back from you regarding whether trying ecc rather than your Makefile helped or not. Thanks!

Wow, very cool! Will it work with our tinyirc IRC client?

At 232K, I can see why you've had to use OWC's large model!

Once you get it working and approve, we'll definitely want to include it in our application distribution on larger images. I'm working on figuring out an automated way to do that starting with our next v0.9.0 release.

No problem @parabyte, there's no rush over here! The program can't easily be debugged with blink16, since networking isn't supported, but elksemu might allow you to skip having to create images every make cycle. I've gotten used to using printf or __dprintf sprinkled heavily through startup code in main() to more quickly find where it's stopping. Another idea is to compile with CONFIG_TRACE=y then set strace in /bootopts. This will produce output showing every system call, which will only work well if you're running from an emulated serial terminal in QEMU so that you can scroll backwards. That output is quite voluminous, but can help a lot for certain problems.

I am away at the moment and my computing experience is sparse!

if anyone wants to try this, and see if you can host a irc server post the ip here!