compile and dont find my lib.a ?

[honey data]

here to find the lib file?
im using the freedos install on dos not on windows

Code: Select all

'fbc -lib addn.bas
#include once "addn.bi"
function Addn( byval a as integer, byval b as integer) as integer export
	function = a + b
end function

Code: Select all

'addn.bi
declare function addn alias "Addn"( byval a as integer, byval b as integer ) as integer

Code: Select all

'fbc adds.bas

#include "addn.bi"
#inclib "addn"

print addn(10,20)

copiled using 'fbc -dylib addn.bas' give error on compile on crt0.o main not defined thanks
in compile 'fbc -lib addn.bas' the exit file is addn.a im not find the static lib

[rugxulo]

I'm not quite sure what you're trying to do, but the DOS/DJGPP port doesn't support dynamic libs, AFAIK.

https://www.freebasic.net/wiki/wikka.php?wakka=FaqDOS

Limitations ... Shared libraries (DLL's) can't be created/used (at least not "easily")

[rugxulo]

In the old thread (ten years ago!) titled "Bibliothèque externe", here's what was said:

Dynamic libraries could possibly be implemented in the DOS version (I experimented with DXE3 for a while), but it doesn't make much sense from my point of view - to load arbitrary libraries at runtime, you'd need to either link and export every function in libc, etc. in your program or make libc dynamically loaded (either way, increasing the size of your program and/or its required files by quite a lot). Any better ideas or patches are appreciated, though. :P

[honey data]

thanks


thanks

afther searching over the internet im finding nothing,
im want to build a dll or a dylib in dos mode on gcc to use in freebasic

Code: Select all

int adds(int x, int y)
{
	return x+y;
}

[caseih]

You're finding nothing because DLLs don't exist on MS-DOS. However, you can produce a .a file, which is an object archive or static library. If you have DJGPP installed, you can use it's archive utility to make library archives:
http://www.delorie.com/djgpp/v2faq/faq8_22.html

Once you have a static library, you link it in statically at compile time (the whole thing goes in the EXE). Even if you have a large static library archive, the linker is only going to pull in object code that's actually needed, if I'm not mistaken. The library is used with the following FB compiler syntax:

fbc -o my.exe my.bas libmylib.a

Like rugxulo said, which you apparently didn't read very carefully, DLLs simply don't make sense in MS-DOS. There's no mechanism, either in the OS, or the hardware platform to work with them. DLLs only make sense when the OS supports multiple processes, and the CPU supports protected memory and virtual memory mapping and addressing (MMU). 16-bit real mode (even huge, flat, 32-bit real mode) does not support those features on the CPU.

[honey data]

thanks is wat im wanted thanks

[srvaldez]

here to find the lib file?
in compile 'fbc -lib addn.bas' the exit file is addn.a im not find the static lib

I suggest that you prefix the name of your lib with "lib" so that instead of "addn.a" you have "libaddn.a" and then place that lib in the FB lib folder, then your code should work.

Code: Select all

#include "addn.bi"
#inclib "addn"

print addn(10,20)

[honey data]

thanks


help on this please

viewtopic.php?f=2&t=26430

[rugxulo]

DLLs simply don't make sense in MS-DOS. There's no mechanism, either in the OS, or the hardware platform to work with them. DLLs only make sense when the OS supports multiple processes, and the CPU supports protected memory and virtual memory mapping and addressing (MMU). 16-bit real mode (even huge, flat, 32-bit real mode) does not support those features on the CPU.

Back in 2006/7, one guy did some unofficial changes to DJGPP to get .so support. It was called DJELF, the successor of DXE3. Normally, DJGPP uses COFF, but he optionally used ELF instead. It's on most DJGPP mirrors under /djelf/ . It does work, I've tried it. Unfortunately, it's unmaintained and thus not mainlined, so it only supports old G++ 4.0.0 and DJGPP 2.04. There was little interest in reviving it.

For one thing, it makes keeping track of dependencies harder. While some may lament having to rebuild an .EXE from scratch, it's not that hard (normally). Having only a single .EXE is much more convenient than having tons of .DLLs. Even more important, IMO, is the fact that UPX for DJGPP doesn't support ELF. So you're looking at bigger binaries, which loses one of the other obvious advantages.

While I don't direly want DLLs for DJGPP, it would still be cool. Of course, even switching to ELF might have some benefits. But there are only very few developers left, and nobody cares about such niche projects.

Having said that, DXE3 is more robust than you think. I don't know the details and honestly am not familiar with it very much, but I think it is heavily used in such projects as UHexen2 (Hammer of Thyrion) and that one guy's port of Quake2. So you could look closer there if direly curious.

[marcov]

wdosx, a dos extender with a more windows centric model did DLLs iirc.

The main sense of DLLs IMHO is to be able to deliver/update parts of the program without recompiling the central part.

[angros47]

With version 1.06 creation and use of dynamic libraries under DOS should be possible