Static lib output

Got an idea for enhancing PureBasic? New command(s) you'd like to see?
freak
PureBasic Team
PureBasic Team
Posts: 5929
Joined: Fri Apr 25, 2003 5:21 pm
Location: Germany

Post by freak »

> 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.
quidquid Latine dictum sit altum videtur
Mistrel
Addict
Addict
Posts: 3415
Joined: Sat Jun 30, 2007 8:04 pm

Post by Mistrel »

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.
srod
PureBasic Expert
PureBasic Expert
Posts: 10589
Joined: Wed Oct 29, 2003 4:35 pm
Location: Beyond the pale...

Post by srod »

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! :wink: A fully linked static lib is called an executable (or a dll).
I may look like a mule, but I'm not a complete ass.
User avatar
DoubleDutch
Addict
Addict
Posts: 3219
Joined: Thu Aug 07, 2003 7:01 pm
Location: United Kingdom
Contact:

Post by DoubleDutch »

which is the reason why we are not doing it so far
So far... seems like you have plans. 8)
https://deluxepixel.com <- My Business website
https://reportcomplete.com <- School end of term reports system
Fred
Administrator
Administrator
Posts: 16619
Joined: Fri May 17, 2002 4:39 pm
Location: France
Contact:

Post by Fred »

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.
Mistrel
Addict
Addict
Posts: 3415
Joined: Sat Jun 30, 2007 8:04 pm

Post by Mistrel »

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.
freak
PureBasic Team
PureBasic Team
Posts: 5929
Joined: Fri Apr 25, 2003 5:21 pm
Location: Germany

Post by freak »

DoubleDutch wrote:
which is the reason why we are not doing it so far
So far... seems like you have plans. 8)
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.
quidquid Latine dictum sit altum videtur
User avatar
pdwyer
Addict
Addict
Posts: 2813
Joined: Tue May 08, 2007 1:27 pm
Location: Chiba, Japan

Post by pdwyer »

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 :)
Paul Dwyer

“In nature, it’s not the strongest nor the most intelligent who survives. It’s the most adaptable to change” - Charles Darwin
“If you can't explain it to a six-year old you really don't understand it yourself.” - Albert Einstein
Mistrel
Addict
Addict
Posts: 3415
Joined: Sat Jun 30, 2007 8:04 pm

Post by Mistrel »

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.
User avatar
pdwyer
Addict
Addict
Posts: 2813
Joined: Tue May 08, 2007 1:27 pm
Location: Chiba, Japan

Post by pdwyer »

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?
Paul Dwyer

“In nature, it’s not the strongest nor the most intelligent who survives. It’s the most adaptable to change” - Charles Darwin
“If you can't explain it to a six-year old you really don't understand it yourself.” - Albert Einstein
Mistrel
Addict
Addict
Posts: 3415
Joined: Sat Jun 30, 2007 8:04 pm

Post by Mistrel »

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.
freak
PureBasic Team
PureBasic Team
Posts: 5929
Joined: Fri Apr 25, 2003 5:21 pm
Location: Germany

Post by freak »

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.
quidquid Latine dictum sit altum videtur
User avatar
pdwyer
Addict
Addict
Posts: 2813
Joined: Tue May 08, 2007 1:27 pm
Location: Chiba, Japan

Post by pdwyer »

(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 :P )
Paul Dwyer

“In nature, it’s not the strongest nor the most intelligent who survives. It’s the most adaptable to change” - Charles Darwin
“If you can't explain it to a six-year old you really don't understand it yourself.” - Albert Einstein
Mistrel
Addict
Addict
Posts: 3415
Joined: Sat Jun 30, 2007 8:04 pm

Post by Mistrel »

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.
Post Reply