New FB release coming up

[integer]

Downloaded/installed wxFBE.
Also the vb rt redistributable.

Attempted to compile an existing fb program:
at compile time wxFBE said that it "COULD NOT FILE -luuid"

with no changes, the program will compile (and run ok) using FBIDE.
[under fb 0.24)

Where can I get a copy of luuid?
What is it used for and where should it be placed (i.e., what subdirectory) ?

My system is xp sp3

Thanks for any help.

oops.
when using fb 0.90
this results:

Command executed:
"C:\FreeBasic90\fbc.exe" "C:\mf_fingerprint-16b\FBIDETEMP.bas"

Compiler output:
C:\FreeBasic90\bin\win32\ld.exe: cannot find -luuid

Results:
Compilation failed

System:
FBIde: 0.4.6
fbc: FreeBASIC Compiler - Version 0.90.0 (05-03-2013) for win32
OS: Windows XP (build 2600, Service Pack 3)

THUS, the progblem is NOT with wxFBE.
It's a missing file.

[MOD]

In 0.90.0rc2 I have a libuuid.dll.a under /lib/win32/. This file is missing in 0.90.0rc1. Without any code, I can't say, why you would need this library.

[DOS386]

There is another severe bloat-BUG with 0.90rc2 : the DOS/DGJPP EXE's are now 60 KiB bigger than with 0.24:

Hello World simple 100 KiB -> 160 KiB
Hello World AntiBloat ("cputs") 60 KiB -> 120 KiB

I see the libs generously rearranged in 0.90 compared to 0.24 :-|

See also: http://www.freebasic.net/forum/viewtopic.php?t=11757

Another minor BUG: the exit function is called 2 times in the "AntiBloat" case (0.24 and 0.90rc2)

[MOD]

Now my post is moved but without moving integers post it's a senseless post in the other thread.^^

Admin: Please move integers post, too. (This post can be deleted afterwards.)

[fxm]

dkl, good job for this version 0.90:
At the two download pages (http://www.freebasic.net/get and http://www.freebasic.net/forum/viewtopi ... =1&t=21321), you could perhaps add the both links to 'Libraries' and 'Add-ons', and this for each of Win32/Linux/DOS binaries?

[podvornyak]

I'm using ubuntu 10.04 LTS. Geany IDE gives me this... What i missed? Both with and without musl.

Code: Select all

ld: /usr/local/bin/../lib/freebasic/fbextra.x: No such file: No such file or directory

fbextra.x is in the usr/local/lib
Geny compilation call is fbc -w all "%f"

[dodicat]

Thanks dkl, for all your work.

The disphelper :

ld.exe: cannot find -ldisphelper

seems to be missing again.
But don't worry about it.

[fxm]

The disphelper :
ld.exe: cannot find -ldisphelper

The external libraries are now separate packages again, and I think this way could work quite well.

At the two download pages (http://www.freebasic.net/get and http://www.freebasic.net/forum/viewtopi ... =1&t=21321), you could perhaps add the both links to 'Libraries' and 'Add-ons', and this for each of Win32/Linux/DOS binaries?

Example for win32:
Add-ons
Libraries

@dodicat,
(FB-win32-disphelper-0.81.zip)

[DOS386]

Yeah 0.90 is out: http://www.freebasic.net/forum/viewtopic.php?t=21321

Thanks to dkl and all contributors :-)

Any progress with the bloat-BUG http://www.freebasic.net/forum/viewtopi ... 64#p188564 (if it's not fixed in 0.90, can it be in 0.91 ? 0.99 ? 1.0 ?) ?

> fbc no longer depends on libbfd

what did it do ?

Compared 0.90rc2 vs 0.90final:

- "fbc.exe" changed - identical except dates
- 2 lib's changed - identical except dates
- junk EXE removed
- many changes in examples from the manual
- all other files unchanged

[dkl]

I just found a bug in the install.sh script in the FreeBASIC-0.90.0-linux packages, that caused them to copy the lib/freebasic/ into /usr/local/lib/freebasic/freebasic instead of /usr/local/lib/freebasic. It should be fixed now, I have reuploaded the two linux packages.

No idea how fbextra.x would end up at /usr/local/lib though either way, unless copied there manually by mistake. fbextra.x, fbrt0.o, libfb*.a should all be in /usr/local/lib/freebasic/ directory anyways.

--

As noted in the changelog.txt, fbc now uses a custom COFF/ELF32 reader instead of libbfd. It's much smaller (~16KB vs. ~500KB libbfd) because it only supports two formats, but that's all fbc currently needs. And this also got rid of all the libbfd ABI instability (every version is ABI incompatible to the last, every toolchain has a different one because they use different binutils versions) and licensing (GPL3, shouldn't be linked statically with GPL2+ fbc) issues. (this is an instance of bloat removal)

I have started comparing linker maps (fbc's -map option) for a simple hello world program compiled with FB-dos 0.90 and 0.24. So far I have made out one huge addition for 0.90 was the call to setlocale() that caused a pretty huge setlocal.o with 4.6KB of .text alone. But there must be more. It's possible that it's also related to the new gcc 4.8 DJGPP port which generates wasteful eh_frame sections now, although I didn't find those in final linked FB programs with objdump. I'll try to figure out more, but it's difficult...

The setlocale() call helped fix bugs on Linux and Win32, does it even make sense for DOS? I don't know.

[podvornyak]

No idea how fbextra.x would end up at /usr/local/lib

My fault. i mean /usr/local/lib/freebasic path.

I have reuploaded the two linux packages.

Thank you. Everything is working now.

[v1ctor]

Congratulations dkl, counting_pine and everybody that contributed to this release!

It'll be great to see FB reaching the 1.0 version finally!

Thanks for keeping the project alive.

[VANYA]

In general, I noticed on the incompatibility of many projects. For example GL2D also compile fails, something spoiled with macros: #include Once

[counting_pine]

VANYA also mentions a problem in the CHttpStream.bas example: http://www.freebasic.net/forum/viewtopi ... 50#p188650

Code: Select all

158:			function = *ctx->stream.buffer

(ctx->stream.buffer is a byte ptr.)
A simple fix is to cast to zstring ptr before the dereference, but would a more solid fix be to change the UDT so CStream.buffer is a zstring ptr to begin with? I'd like to defer here to someone with more experience of the code.

EDIT: decided zstring wasn't generally appropriate, so did the cast. Changes in http://sf.net/p/fbc/code/ci/a95d151

[angros47]

I noticed that the improvements added by Monochromator (dynamic linking in dos, pthreads) seems not to be included (at least, there is no dxe3gen.exe, neither samples). Will they be included in the next version?

Also, -lang qb still has a "bug": it doesn't accept scalars and arrays with the same name:

A code like this:

Code: Select all

dim a(10)
a=13.7
a(1)=1

?a(1),a

doesn't work in -lang qb, while it works in QB and QB64. I understand that qb compatibility has low priority in the to-do list (even lower since qb64 is on the scene), but fixing that (i.e., by making the compiler using a different namespace for scalars and arrays when in -lang qb) would greatly improve portability of old source codes and tutorials.