Import "2ddrawing.a" <= getting Linker Error

[PureLust]

I get some problems by trying to import the PB-Library "2ddrawing" which should ba available on any System:

Code: Select all

Import "2ddrawing.a" 
   PB_2DDrawing_GlobalStructure.PB_2DDrawingInfo   ; non-threaded 
   PB_2DDrawing_Globals                            ; threadedsafe mode 
   PB_Object_GetThreadMemory(*Globals) 
EndImport

While trying this, I get the following Linker-Error:

gcc: 2ddrawing.a: No such file or directory
Error: Linker

Because this just tries to import a standard PureBasic-Library, it should be found on any system where PB is installed - shouldn't it?

Is this a bug in the "Import" command or does PB-Linux not create the temporary "2ddrawing.a" as it does with the "2ddrawing.lib" under Windows?

[Fluid Byte]

No one? I really want to know what can fix it.

[inc.]

IMHO native PB Libraries do differ in their architecture from regular .lib files.

If you just want to access an .a library like outputted out of a MinGW based Environment the you could try simply renaming its suffix to .lib and see if it works. Also its a good Idea to try using absoulte parts for "Import"'ing Libs.

[freak]

Just don't mess with the PB internals...

[Fluid Byte]

Just don't mess with the PB internals...

True. But we need this, I think...

Any suggestions freak or will you refuse to give any tips on this?

[freak]

I won't give any information on that, because then i would need to
explain every change we make in the future as well, and that i do not want to do.

Internal stuff differs for each OS and can change with any release.
You simply should not rely on these things.

For the 2ddrawing: There is no information in these structures which you
cannot get with normal PB commands or which is not already known when
you create the object you are drawing on (for example Width/Height)
So no, i do not think you need this...

[PureLust]

For the 2ddrawing: There is no information in these structures which you
cannot get with normal PB commands or which is not already known when
you create the object you are drawing on (for example Width/Height)
So no, i do not think you need this...

Ohh yes ... I prefer to use normal PB commands ... I really do.
And you are right that one should know these Informations while creating the drawing object, but there are a lot of informations you cannot get "back" later on.
If you need things like these in an common Procedure you don't know them there (I try to write a Userlib and I need theses values within this lib).
Using the unsupported PB-Internals is the only way I see at the moment to get to these kind of informations within a linked or included common subroutine.

If you may have a look at >this< german Thread, you can see some of the PB commands which are missing to write things like this.

Nevertheless here is an even more precise list:

- IsScreen() - checks if a screen is already opened
- ScreenWidth() - provides the Screen-Width
- ScreenHeight() - provides the Screen-Height
- ScreenDepth() - provides the Screen-Depth
- ScreenPixelFormat() - provides the PixelFormat of the Output channel

- IsOutpuBuffer() - checks if there is an actual Output channel (StartDrawing() has been called already)
- OutputWidth() - provides the Width of the Output channel
- OutputHeight() - provides the Height of the Output channel
- OutputDepth() - provides the Depth of the Output channel
- OutputPixelFormat() - provides the PixelFormat of the Output channel

I've already realised some of these commands by using just 2 lines of assembler and some PB-internal Informations. E.g.:

Code: Select all

Procedure ScreenHeight()
  !EXTRN _PB_Screen_Height 
  !MOV   Eax,[_PB_Screen_Height]
EndProcedure 

But as you've said: Because this is not native PB, it can differs for each OS and can change with any release.

Because of this it would be nice if you can implement some very easy commands like this or if you could just provide a pointer to a structure, so one can get this kind of information out somehow.