PureBasic Forums - English

> It would be an obvious solution to the inherit problems that exist with TailBite and future compatibility.
> Libraries produced by coffIT cannot be used in other languages if they use any function from the PureBasic libraries.

What makes you think any of this would be different if the PB Compiler generated the static lib ?
All these problems would remain, which is the reason why we are not doing it so far.

freak wrote:> It would be an obvious solution to the inherit problems that exist with TailBite and future compatibility.
> Libraries produced by coffIT cannot be used in other languages if they use any function from the PureBasic libraries.

What makes you think any of this would be different if the PB Compiler generated the static lib ?
All these problems would remain, which is the reason why we are not doing it so far.

When PureBasic compiles a shared DLL it links in the functions from the standard PureBasic libraries so that they are not required when the DLL is loaded into another language.

If this could be an option for static libraries produced by PureBasic then I believe the libraries produced would be immune to the problems inherent in TailBite and coffIT.

What I would like to see is a way of producing a static library that will reliably work on future versions of PureBasic and does not have to be recompiled for each new version.

Static libraries, by their very definition, are not linked -therefore, as Freak pointed out, you will have this same problem no matter how the .libs were created -whether by PB itself, coffIT or by hand assembly! A fully linked static lib is called an executable (or a dll).

which is the reason why we are not doing it so far

So far... seems like you have plans.

Mistrel wrote:What I would like to see is a way of producing a static library that will reliably work on future versions of PureBasic and does not have to be recompiled for each new version.

It's not that easy. If we includes every PB commands, helpers etc. inside the static lib, it will (may be) work called from another langage, but won't from PB (symbol duplications). If we don't includes the helpers, it will work until we change some PB internals (ie: a function signature). Static libs are very tighly tied to a PB version, exactly like C static libraries are very tied to a particular VC version. On another hand, PB uses a runtime (MSVCRT) which is older than the one shipped with VC7/8/9 (MSVCRT7/8/9) for compatibility reasons with older systems (we don't use the new features anyway). That means than you couldn't use it with newer VC.

I must be mistaken in my understanding of static libraries. In C if someone writes a static library using functions from the C standard library does that mean that it cannot be used without the C static libraries?

Permit me to rephrase the request. It would still be very useful if PureBasic could save to a static library, even if the library was compatible only with that version of PureBasic.

There are solutions already available such as TailBite and coffIT but these solutions are not official and may not always have a maintainer.

It would be a great asset to individuals who would like to write commercial libraries for PureGDK if a native solution was available for creating static libraries. DLLs are not always acceptable for large collections of libraries.

PureGDK for example is comprised of 126 TailBite libraries and 2 DLLs and links against itself to provide a plugin framework for third-party developers. This would not be possible with DLLs.

I love developing commercial solutions for PureBasic and want to continue to offer a static solution. But I worry about not being able to provide a service to my customers if TailBite should fail.

freak wrote:All these problems would remain, which is the reason why we are not doing it so far.

Alright, so all of these problems will remain. But at least commercial authors will have a reliable solution.

DoubleDutch wrote:

which is the reason why we are not doing it so far

So far... seems like you have plans.

Its just my polite way of not saying never

I must be mistaken in my understanding of static libraries. In C if someone writes a static library using functions from the C standard library does that mean that it cannot be used without the C static libraries?

Exactly. Those are external dependencies.
Every C program needs that though, so linking with another C program is (mostly) not a problem.

Alright, so all of these problems will remain. But at least commercial authors will have a reliable solution.

Most users will not be satisfied by that.
I expect we will have a lot of work on our hands with every new release from people
complaining about why things don't work anymore, or people not even knowing
that they use such a library and not understanding where their errors come from.
Already we get many false bugreports from problems caused by Tailbite libs.
If we make this an official compiler feature, i expect these to increase a lot.

For this reason, we would have a very hard time each time we introduced a change
which causes a binary incompatibility (which is quite common), but we need
to make those to develop PureBasic further.

We're just not ready to deal with all of this, sorry.

Mistrel wrote:PureGDK for example is comprised of 126 TailBite libraries and 2 DLLs and links against itself to provide a plugin framework for third-party developers. This would not be possible with DLLs.

Would it not have been possible with included source though? (honest question, I've never coded anything that big)

Very informative discussion though on this thread

The DLLs must be compiled. The TailBite files could be sources but you would lose support for crashing to an error line in your source. It would jump to the include file which usually isn't the problem.

How would you debug your code then?

One of the benefits of compiling to a TailBite library is that I can set the debugger to error on the line in your source and also report the correct line when the debugger is off.

I've never tried compiling from the source before and I don't know if it would work.

is the only reason for not wanting dll's that you don't want to distribute that many dlls files or that you don't want the extra work of working with dlls in your code?

A little of both, actually. It's simpler to not have to distribute all of the required DLLs and static linking is a lot simpler for a collection of libraries of this size.

If the time comes I can always consider moving to DLLs but it would take a lot of restructuring before it would even begin to work.

Well, if the future of Tailbite is really too uncertain for you, you could also move to
C to create the libs (you are probably accessing C functions anyway, right ?)

There are multiple benefits of that:
- You only need to rely on PB tools to create the library. (which we rely on as well, so this is futureproof)
- Since the libs are much more independent of the PB internals, its much easier to get them to run on more than one PB version.
(Its just because Tailbite'ed libraries depend so much on the binary interface of other PB functions that they break so often)

If you are concerned about the future of your product, this might be a step to consider.

(probably just showing my lack of understanding here but...)

If C can create libs that independant of PB internals and can run on many versions of PB... Why can't PB (not tailbite) create libs like the the C ones?

(I'm not saying it would be easy mind you )

I think it's because it links to the PureBasic libraries instead of the C standard library. As freak said these libraries may not be binary compatible between versions.