Where is the magic?

[Cretin Ho]

I'm on DragonflyBSD. It's Luna New Year when I committed the DragonflyBSD support, so I didn't have time to actually test it on a real DragonflyBSD VM. Now I'm on the VM now and too many problems appear. I think it should just work. Turned out I was wrong.

First, I forgot to add Dragonfly to known host in rtlib/fb_config.h. But this is easily fixed.

Second, the incompatibility between FreeBSD and Dragonfly in rtlib/dragonfly/sys_fmem.c

I fixed this by following the compiler's suggestion, I changed VM_TOTAL to VM_METER.

I have no idea if it's right or not. But it allowed me to going on.

The most troublesome part is having it to find the headers and the libraries.

You know, on both FreeBSD and Dragonfly, the headers are in /usr/local/include and the libraries are in /usr/local/lib

I just copied the code from FreeBSD for Dragonfly and expect it to work. It's not that simple. So I tried with the bootstrap-minimal.

I finally put these to makefile to let it find the correct headers:

ifeq ($(TARGET_OS),dragonfly)
ALLCFLAGS += -I/usr/local/include -I/usr/local/include/ncurses
endif

But finally it will fail to link ncurses, it said:

LINK bootstrap/fbc
/usr/libexec/binutils227/elf/ld.gold: error: cannot find -lncurses
lib/freebasic/dragonfly-x86_64/libfb.a(hinit.o):hinit.c:function fb_hTermOut: error: undefined reference to 'tgoto'
lib/freebasic/dragonfly-x86_64/libfb.a(hinit.o):hinit.c:function fb_hTermOut: error: undefined reference to 'tputs'
lib/freebasic/dragonfly-x86_64/libfb.a(hinit.o):hinit.c:function hInit: error: undefined reference to 'tgetent'
lib/freebasic/dragonfly-x86_64/libfb.a(hinit.o):hinit.c:function hInit: error: undefined reference to 'UP'
lib/freebasic/dragonfly-x86_64/libfb.a(hinit.o):hinit.c:function hInit: error: undefined reference to 'BC'
lib/freebasic/dragonfly-x86_64/libfb.a(hinit.o):hinit.c:function hInit: error: undefined reference to 'tgetstr'
lib/freebasic/dragonfly-x86_64/libfb.a(hinit.o):hinit.c:function hInit: error: undefined reference to 'PC'
lib/freebasic/dragonfly-x86_64/libfb.a(hinit.o):hinit.c:function hInit: error: undefined reference to 'ospeed'
lib/freebasic/dragonfly-x86_64/libfb.a(hinit.o):hinit.c:function hInit: error: undefined reference to 'tgetflag'
lib/freebasic/dragonfly-x86_64/libfb.a(hinit.o):hinit.c:function hInit: error: undefined reference to 'tgetstr'
collect2: error: ld returned 1 exit status
gmake: *** [makefile:1216: bootstrap/fbc] Error 1

But of course ncurses is there:

$ ls /usr/local/lib | grep ncurses
libncurses++.a
libncurses++w.a
libncurses.a
libncurses.so
libncurses.so.6
libncurses.so.6.2
libncursesw.a
libncursesw.so
libncursesw.so.6
libncursesw.so.6.2

In the makefile, there is various kind of CFLAGS (ALLCFLAGS,...) but no LDFLAGS at all.

Something like this doesn't work:

ifeq ($(TARGET_OS),dragonfly)
ALLCFLAGS += -I/usr/local/include -I/usr/local/include/ncurses -L/usr/local/lib
endif

I tried the following to make it find ncurses but no success:

$ LDFLAGS="-L/usr/local/lib -R/usr/local/lib" gmake -j4 bootstrap-minimal




I don't know why it has no problem finding everything on FreeBSD, but too troublesome on Dragonfly.

I have checked the source code and find nothing FreeBSD specific that could be potentially caused this.

The FreeBSD maintainers, could you give me some insights?

How could you do that? Or it just work?

In short: Where is the magic?

[marcov]

IIRC add /usr/local/lib to /etc ld.so.conf and run ldconfig. (important! on FreeBSD it really doesn't pick it up till you run it, while on linux editing is often enough)

There are security implementations of course, but if the system is not heavily multi user with untrusted users, it probably doesn't matter much

[Cretin Ho]

Finally I hacked the makefile again to have it link fbc normally:

# Use gcc to link fbc from the bootstrap .o's
# (assuming the rtlib was built already)
ifneq ($(filter darwin freebsd linux netbsd openbsd solaris,$(TARGET_OS)),)
BOOTSTRAP_LIBS := -lncurses -lm -pthread
endif
# DragonflyBSD hack
ifneq ($(dragonfly,$(TARGET_OS)),)
BOOTSTRAP_LIBS := -L/usr/local/lib -lncurses -lm -pthread
endif

Combined with my previous hack, a full bootstrap of fbc also success.

On DragonflyBSD, it already comes with most almost everything we needed. We only need to install gmake and the xorg meta-package to have all of the graphics libraries pulled in:

pkg install gmake xorg

Done.

[Cretin Ho]

When tried to compile a hello world test program, it failed to link again, the same error with ncurses above.

This hack allowed me to have a working test binary:

fbc -Wl -L/usr/local/lib test.bas

Even though it's kind of work now but since it's all combined of hacks but not actual ways to solve things, I will just let this thread as a reference but not creating a new pull request.

[Cretin Ho]

I will back working on DragonflyBSD port since the Solaris port is kind of complete now. Seems to be more difficult than the Solaris port, though.

[Cretin Ho]

Further news will be reported there:

viewtopic.php?f=17&t=29165&p=281111#p281111

[Cretin Ho]

IIRC add /usr/local/lib to /etc ld.so.conf and run ldconfig. (important! on FreeBSD it really doesn't pick it up till you run it, while on linux editing is often enough)

There are security implementations of course, but if the system is not heavily multi user with untrusted users, it probably doesn't matter much

It doesn't work. The only thing that works is you hacked the makefile to explicitly tell it where to look for libraries like I did above. And when you have a working fbc binary, the only thing that works is passing options directly to the linker using -Wl.

[Cretin Ho]

When tried to compile a hello world test program, it failed to link again, the same error with ncurses above.

This hack allowed me to have a working test binary:

fbc -Wl -L/usr/local/lib test.bas

Even though it's kind of work now but since it's all combined of hacks but not actual ways to solve things, I will just let this thread as a reference but not creating a new pull request.

I could compile the example qbsprite.bas and have the executable worked fine with this command:

fbc -Wl -L/usr/local/lib qbsprite.bas

I could compile the examle flame.bas, too, but the executable segmentation fault (core dumped) when running. With this example, I have to specify the include path, too, like this:

fbc -Wl -L/usr/local/lib flame.bas -i $HOME/FreeBASIC-1.08.0-source-bootstrap/inc

[Cretin Ho]

The internal workings of fbc is still somewhat mysterious for me. Even though I have hacked it to add missing bits for the Solaris port. This DragonflyBSD port really needs assisting from fbc developers. I have done my best. Becoming a fbc developer is not easy.

Anyway, you could check out the partial works here:

https://github.com/CretinHo/fbc/tree/dragonfly-fix

[marcov]

Yeah, my bad. The ld.so.conf is to let the program loader find dirs, not the linker.

Anyway, most compilers have a verbosity option to show the linker commandline (and sometimes even not call the linker at all).

Then you can copy that line from the output and try for yourself with some variations.

[Cretin Ho]

I think it's the gold linker used by DragonflyBSD that caused all of the troubles. The linker scripts generated by FreeBASIC doesn't seem to be liked by gold. Just my wild guess, though. I deleted the DragonflyBSD VM so I can't test this hypothesis, but forcing ld to be ld.bfd on DragonflyBSD is doable, even though troublesome and hackish.

[Cretin Ho]

This not found of libraries problem is common against any platforms that doesn't put everything /usr/lib like Linux does. FreeBASIC on Unix-like platforms is still too Linux specific. Confirmed on FreeBSD, one has to use the same -Wl -L/usr/local/lib trick as on DragonflyBSD in order to have a working binary. So it's not the problem of just my DragonflyBSD port.

Note: I used StW's build for FreeBSD.

[TeeEmCee]

You are correct that it's wrong to use the system ld on FreeBSD, we need to use the same ld as gcc (ld.bfd). I've been meaning to send a pull request for that.
After doing that, I don't think I needed to use -Wl -L/usr/local/lib to compile FB programs. Unless maybe I disabled ncurses...

[coderJeff]

There is some elf magic in https://github.com/freebasic/fbc/blob/m ... bjinfo.bas
And a little bit of information at objinfo in the wiki

Depending on the compile & link steps used, can have some difficulty with libraries that may not see on dos/win/lin.

fbc will add some extra information in a special section of object files and libraries to record the library dependencies.
fbc will read back these elf sections when fbc is used for linking to automatically specify the needed libraries to LD.

When building and testing for raspberry pi (ARM arch) and I had to add the checks for the elf files on ARM. After doing this it a lot easier to compile and link programs, especially when mixing source/object files/library files on fbc's command line.

I started testing on FreeBSD and noticed that the elf format uses other values in the magic elf header so fbc can't read back the information. So current when linking on FreeBSD have to specify all the needed libraries.

[marcov]

Yes. FreeBSD uses the ELF ident info to link the starting binary to alternate library paths. Linux to linuxator libs, and older FreeBSD version to their libraries under /compat/