Building FreeBASIC on OpenBSD

[counting_pine]

I haven't seen anyone in this thread actually reacting negatively to the idea. Some people are saying it's impractical, which is largely true. But noone's condemning it.

FBC only has one fully functional backend at the moment (the x86 one), but one for emitting code for GCC is in the works, and it should be possible to add others.
All it needs is for someone who knows what they're doing, and who has the inclination. They'll need to know how to write PPC assembly code, and how to to write an emitter for FBC that will write it.
Unfortunately, I don't think any of the FB developers have a PPC computer, and I don't know if any of us know how to write PPC code.

But I imagine that those of us who familiar with the workings of the emitter (not me) will give help to anyone who wants to attempt one. And perhaps also provide a branch in SVN for work to take place on it.

[marcov]

With regards to 3, Marcov, my understanding is that it might be a bit of a chicken-and-egg situation? That said, it may be possible to create a cross-compiler with FreeBASIC, though I have no idea how practical it would be...

Only at first sight. And while it is often thought that changing the language is the big solution it isn't, since makefiles (autoconf) need to be updated, validated for the new target, the runtime library seeded with the right constants targets added to the compiler (in C), deviances in types and libc wrapped etc etc. And most importantly, recognize and fix problems.

None is exactly trivial, and the crosscompiler itself is the least of your worries. With Free Pascal crosscompiling is routinely done by beginners. (but the targets have been prepared in the sources. WinCE is a popular cross- target because, obviously, running any full compiler suite on it is difficult because of size,cpu and memory constraints)

Changing the implementation language on the other hand, is something you have to live with on a daily basis.

It might be a good idea to change the FB implementation language for other reasons (like only be able to get quality contributors that know C++), but crosscompiling is not one of them.

From what I've seen from GPC, the problem is that while C/C++ programmers are more abundant, they are also less likely to work on a foreign language project (and if they do, soon it is indistinguishable from C/C++)

[marcov]

I don't know if any of us know how to write PPC code.

The CPU manuals are downloadable. IIRC on a IBM site. While I only debugged some lower level RTL routines, if there are questions I could try.

I bought an old powermac for Eur 20, and put Linux on it at the time. When PPC became a proper target, I bought a mini.

An older G3 should be quite affordable. Always buy older 2nd macs with all the memory you need installed, some have funky kinds of memory. SCSI is to be avoided if you can too.

[etko]

I just wanted to report, that I managed to compile current SVN on my X-less OpenBSD server/firewall. There was sligth problem With WITH_X directive, so far FBC is working on simple hello worlds etc.

[Mentat]

I just wanted to report, that I managed to compile current SVN on my X-less OpenBSD server/firewall. There was sligth problem With WITH_X directive, so far FBC is working on simple hello worlds etc.

Cool. What language did you use to compile it?

[fsw]

3) Compilers not written in itself are typically for toy languages. Apparantly the language is not suitable to write a compiler.

Every time somebody writes a compiler for a new language he/she needs to start somewhere - which would be with an already existing language (machine code anyone?).

At one point in time there will/can/should/could be a compiler rewrite with the newly created language, but sometimes this step does not happen because of certain circumstances.

Programmers should not disregard a programming language as a toy language just because the last step didn't happen (yet).

---

Found this one a while ago:
http://bsdbasic.com
It seems to be another BSD Basic (no files released yet)

fsw

[marcov]

3) Compilers not written in itself are typically for toy languages. Apparantly the language is not suitable to write a compiler.

Every time somebody writes a compiler for a new language he/she needs to start somewhere - which would be with an already existing language (machine code anyone?).

Sure.

At one point in time there will/can/should/could be a compiler rewrite with the newly created language, but sometimes this step does not happen because of certain circumstances.

That could be. I just want to point out that such circumstances can provoke other circumstances (requiring bi-lingual contributors, and a larger reliance on external testing) that might be negative.

Programmers should not disregard a programming language as a toy language just because the last step didn't happen (yet).

That statement was of course a bit tongue in cheek. (even major commercial compilers are sometimes written in a different language/dialect)

But while it was partially a provoking pun , there is some truth in the fact, specially for open source compilers, that language written in themselves have the advantage that more of the system is tested during the normal development cycle, specially for codegeneration bugs. "The compiler is the best testsuite".

[fsw]

..."The compiler is the best testsuite".

I concur 100%

;)

[etko]

Cool. What language did you use to compile it?

Is this supposed to be real question? Runtime library is written in C, compiler is written in FB itself. Check out DrV's tutorial for compiling on OpenBSD, it worked for me. It is well written. I would like to see some compiler maintainers looking more into supporting DOS, FreeBSD & OpenBSD targets.

[Mentat]

Cool. What language did you use to compile it?

Is this supposed to be real question? Runtime library is written in C, compiler is written in FB itself. Check out DrV's tutorial for compiling on OpenBSD, it worked for me. It is well written. I would like to see some compiler maintainers looking more into supporting DOS, FreeBSD & OpenBSD targets.

I didn't realize how dumb that question was until now. I think I meant version, but then again I don't know what I thought I was thinking.

Alright. Thanks.

[commodorejohn]

I'm currently trying to get FreeBASIC set up on an OpenBSD 5.5 install, but I'm caught in the laughable catch-22 of needing the compiler to compile the compiler. The tutorial for building FreeBASIC linked at the start of the thread has been helpful so far, but unfortunately, it tells me to use the binary of the compiler that I downloaded earlier, except it never told me where to get any such binary, and I can't find one on the FBC Sourceforge page. This is nuts. Can anyone hook me up with a suitable binary?

[dkl]

There may be a FreeBSD version floating around somewhere... but other than that, you can do this:

1. On OpenBSD, compile FB's rtlib/gfxlib2 using the native C compiler as usual

make rtlib gfxlib2

2. On Linux or Win32, use existing fbc to cross-compile src/compiler/*.bas into OpenBSD-compatible *.asm files

fbc -e -m fbc -target openbsd -r src/compiler/*.bas

3. Take the .asm files to OpenBSD

4. On OpenBSD, assemble them into *.o object files using the native assembler:

for i in src/compiler/*.asm; do
as $i -o `echo $i | sed -e 's/asm$/o/g'`
done

5. On OpenBSD, link everything into the final fbc executable (based on what fbc itself would do for OpenBSD):

ld -o fbc -dynamic-linker /usr/libexec/ld.so -s crt0.o crtbegin.o fbrt0.o src/compiler/*.o "-(" -lfb -lgcc -lpthread -lc -lm -lncurses "-)" crtend.o

Of course, if you have a Linux system and a Linux-to-OpenBSD GCC cross-compiler toolchain, that would make it even easier.

[commodorejohn]

Well, compiling on Windows and then assembling on BSD worked fine, but when I try to link it tells me "ld: crt0.o: No such file: No such file or directory"...

[dkl]

You have to insert the proper path to crt0.o on your system - it will be something like /usr/lib/crt0.o or similar, I don't know the specifics for OpenBSD. fbc locates it by running:

gcc -print-file-name=crt0.o

Or use gcc to link (that's easier anyways):

gcc -o fbc fbrt0.o src/compiler/*.o -lfb -lncurses -pthread

However it would still be good to compare gcc -v output against fbc's custom ld invocation to see whether fbc is still doing the right thing for OpenBSD, because it hasn't been tested in years.

[commodorejohn]

Okay, now it's telling me "ld: cannot find -lfb"...