Run on GNU/Linux

[LADSoft]

get the executables (other than OCIDE) to run on GNU/LINUX

[chuggafan]

Well, if we want such a thing to happen, we should probably then add Linux support for OCC, etc.

Currently this would mean the following:

• Adding support for various LIBCs (E.G. glibc or BSDLibc)
• More calling conventions (System V notably)
• More object output formats (ELF32 and maybe ELF64)
• More debug formats (DWARF 3+)
• More manglers (Itanium ABI is the only one needed here)

Some documents:

Itanium ABI: http://itanium-cxx-abi.github.io/cxx-abi/

Dwarf Standards: http://dwarfstd.org/Download.php

SYSV abi: https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI

A collection of the ABIs noted here: https://refspecs.linuxfoundation.org/

GLIBC's abi stuff can seemingly be found in their git repository: https://sourceware.org/git/?p=glibc.git;a=summary The actual ABI can be found: https://sourceware.org/git/?p=glibc.git;a=blob;f=libc-abis;h=e702f6ae245c1528f5a608df8cfae4f037809de2;hb=HEAD

[LADSoft]

well probably this is too much to take on for the foreseeable future :)

[chuggafan]

Yes for getting things to compile, I'd agree, running the basic stuff thought should be fine, I might look into it more, but I did make a shim for semaphores between windows/Linux for OMAKE the other day as a theoretical thing. I'd imagine getting OCC to compile + run alone would be easier than what I listed though.

[GitMensch]

@chuggafan Can you come back to this up to "getting occ to compile and run" (it is "enough" that it could use whatever OrangeC library also was able to being compiled, no need to glibc support yet)?

[chuggafan]

I think, OCC needs at a minimum for re-writting: piper.c in parse86 and getting abspath() running from browse.c working everywhere to properly running, however, attempting to compile+link against a library would also be difficult as you would need to have those libraries with you or the symbol dumps, I think that olink might be able to handle the .def files, however the utils section ALSO has a lot of windows-specific stuff in it. Specifically in CmdFiles recurse-dirs (this has no equivalent on linux), the banner in Utils.cpp, and the GetModuleName in utils.cpp. So in summary, the minimum requirements for re-writing to compile for windows are (Sorry to add some, I did a search on the repo for everything for this list):

OBJLIB:

ObjSourceFile::RetrieveFileTime in ObjSourceFile.cpp,

OCC: Only thing in this list is required for IDE support, nothing else. piper.c in parse86

ORC stuff: We may or may not do this(?) Bitmap::ReadRC in Bitmap.cpp, A bunch of stuff in Dialog.cpp, VersionInfo::WriteRes in VersionInfo.cpp

Util stuff: CmdFiles::RecurseDirs in CmdFiles.cpp CmdFiles::Add in CmdFiles.cpp Utils::banner in Utils.cpp And finally: Utils::GetModuleName in Utils.cpp

All of these are Windows-only pretty much and need to be modified if we want to run on Linux, I purposely excluded OMAKE here since semaphores on Linux are much more difficult to work with than those on Windows.

[LADSoft]

the parse86 stuff is IDE support, you won't need it for linux because you can't do the IDE on linux anyway. It is questionable as to whether you want to translate ORC.EXE I guess?

[LADSoft]

i think there is a standard function 'opendir' or something. Only reason I haven't put it in the utils is because I also need to add it to the RTL...

[GitMensch]

i think there is a standard function 'opendir' or something. Only reason I haven't put it in the utils is because I also need to add it to the RTL...

@LADSoft Please do this.

@chuggafan Would you please be so kind to edit your previous post, striking the ocide+orc parts out (not deleting them) with an added comment?

Actually the piper should not be needed at all (any more) as popen solves the problems handled there already, doesn't it?

[chuggafan]

The piper.c stuff could be replaced by _popen and friends, yes, but it's nice to have that wrapper there so less can be edited. I did edit my comment for you as well.

Also: opendir is not defined by the C standard, and as far as I can tell Windows does not add this function, which means that we'd have to create a wrapper for it. Here seems to be a wrapper for it which confirms to me that it does not exist on windows. So... that means that we have to do conditional compiles based on which platform we're running since directories aren't standard in C yet and all C++ ABI's for C++17 (Which we don't support yet) for filesystem is unstable :/ so it looks like the Utils.cpp part will be the pain...

[LADSoft]

I was thinking we could take the win32 wrapper and stick it into the utils directory then rewrite the actual utils to use opendir... which will work until they get the file system object stable and we run up to C++ 2017... the wrapper could simply be elided on linux.

[LADSoft]

I remembered today that when i was getting it to compile on linux, there were a few minor problems with windows functions and so forth... and rather than make it compile to work I made it compile to compile. The sources need to be inspected for the preprocessor #define GCCLINUX to see what is going on...

[GitMensch]

Also: instead of using a non-standard GCCLINUX I highly encourage you to use the standard approach of HAVE_UNISTD_H etc. BTW: #313 brings working Travis builds back.

[johnsonjh]

I'd actually love this.

I was able to use OrangeC under Wine successfully, and compile things that worked.

I wasn't able to link one thing though, which uses Shlwapi.dll, with the following errors:

Error: Undefined External 'PathFindFileNameA' in module sirfilesystem.c
Error: Undefined External 'PathIsRelativeA' in module sirfilesystem.c
Error: Undefined External 'PathRemoveFileSpecA' in module sirfilesystem.c
        3 Errors, 0 Warnings
        Errors encountered, not creating output file

This is probably something with paths and Wine that I could fix if I was more familiar with Windows (and OrangeC).

Sorry for being a bit off topic, vs. running natively on Linux.

[chuggafan]

In win32 the A functions are 8 bit char versions, versus the W functions which are the wide string functions. It is more than likely that wine doesn't implement these functions since the latest release using the Pelles C headers have the function defined (since you could access them, that should be obvious enough...).

[johnsonjh]

Interesting - I'm quite sure that Wine does have that implemented. I'll have to look into it and see about building on actual Windows too, in a virtual machine.

I was trying to build https://github.com/aremmell/libsir/ in case you are interested.

It also complained about missing strnlen function which I thought was odd, but I just replaced those with strlen equivalents in the source. Otherwise, it needed just one or two other minor changes, and I built with:

env CC="wine64 ../bin/occ.exe" gmake MMDOPT="" NO_DEFAULT_CFLAGS=1 PTHOPT="" SIR_MSVCRT_MINGW=1

Worked fine until the linking step:

occ (OrangeC) Version 6.0.70.2
Copyright (C) LADSoft 2006-2021
Error: Undefined External 'PathFindFileNameA' in module sirfilesystem.c
Error: Undefined External 'PathIsRelativeA' in module sirfilesystem.c
Error: Undefined External 'PathRemoveFileSpecA' in module sirfilesystem.c
        3 Errors, 0 Warnings
        Errors encountered, not creating output file
gmake: *** [Makefile:113: build/lib/libsir.so] Error 1

Perhaps I should open a new issue, after trying to build on a real Windows machine too.

[chuggafan]

strnlen

That's a POSIX extension, not standard C, we can add support for it, but I haven't seen it before.

I'm not sure if you have shlwapi being added in, you'll either have to statically compile via pragma lib or manually add it in via the linker command line as a specifically used dll.

[johnsonjh]

strnlen

That's a POSIX extension, not standard C, we can add support for it, but I haven't seen it before.

Support for it would be great!

I'm not sure if you have shlwapi being added in, you'll either have to statically compile via pragma lib or manually add it in via the linker command line as a specifically used dll.

It should be set already. I'll try with real Windows later.

[LADSoft]

so shlwapi wasn't in the import library; i'm adding it but may not push until tomorrow. if you need something sooner you can make a library like this:

oimplib shlwapi.l \windows\system32\shlwapi.dll

and then just include it on the occ command line...

the main problem with running the compiler on linux isn't getting the compiler working; it is creating a runtime library for it... allthough I think @iahunq suggested we could at least make a native compiler and use it to cross-compile...

[chuggafan]

Tbh I genuinely think that there's no point in creating a custom runtime library since 99.999999% of all programs (on linux) will run on some version of glibc and they will link to the minimum supported version. To be quite honest, the Runtime Library is actually more standardized on linux than windows (even if it leads to some hilariously epic failures like the whole epic games on linux fiasco with glibc that the glibc devs still haven't fixed and the repository maintainers maintain instead).

If we're still ultra-needing to look, musl is often a replacement libc that's pretty decent.

[johnsonjh]

The midipix people have some sort of musl-on-windows thing happening, but I'd be pleased with OrangeC just as a Linux to Windows/DOS cross-compiler, at least to begin with, to have another option available.

[johnsonjh]

so shlwapi wasn't in the import library; i'm adding it but may not push until tomorrow. if you need something sooner you can make a library like this:

oimplib shlwapi.l \windows\system32\shlwapi.dll

and then just include it on the occ command line...

the main problem with running the compiler on linux isn't getting the compiler working; it is creating a runtime library for it... allthough I think @iahunq suggested we could at least make a native compiler and use it to cross-compile...

Thanks for investigating, I'm going to give it a try later.