#LINK [SLL] and #COMPILE compiler directives

[Michael Mattias]

Use caution when #LINKing Static Link Libraries to avoid getting a compile-time error 637 when the SLL was created with PB/Win and you are attempting to link into a PB/CC program or vice-versa. See this post:

https://forum.powerbasic.com/forum/u...411#post814411

.. and a few which follow in that thread (full thread for above at https://forum.powerbasic.com/forum/u...ow-to-use-link)

This restriction/limitation/caution is not found in the PB documentation under either #LINK or #COMPILE

MCM

[Dale Yarker]

Use caution when #LINKing Static Link Libraries to avoid getting a compile-time error 637 when the SLL was created with PB/Win and you are attempting to link into a PB/CC program or vice-versa. See this post:

https://forum.powerbasic.com/forum/u...411#post814411

That is NOT what was said in that thread.

An SLL compiled in PBWin and containing DDT will not compile with PBCC. If no DDT it will compile without error in PBCC.

Reverse is also true. An SLL compiled in PBCC and containing console code will not compile with PBWin. If no console code it will compile in PBWin.

The documentation should mention the GUI/CLI limitation of cross-compiler use of SLLs. IF/THEN, SELECT CASE, string manipulation, file operations, etc, etc, etc, etc will work fine in an SLL no matter which compiler was used to create them.

Cheers,

[Stuart McLachlan]

The documentation should mention the GUI/CLI limitation of cross-compiler use of SLLs. IF/THEN, SELECT CASE, string manipulation, file operations, etc, etc, etc, etc will work fine in an SLL no matter which compiler was used to create them.

Or more generically:
An SLL compiled with PBCC or PBWIN can be linked in both compilers if, and only if, it does not contain any compiler specific statements/functions.
If an SLL uses any statement/function unique to a specific compiler (PBCC or PBWin), trying to #LINNK it will generate a compile time error.637.

Note that "GUI" is not a limitation per se. A cross-compiler SLL can contain TXT or GRAPHIC WINDOW functions.

[Steve Hutchesson]

The distinctions are pretty straight forward once you are used to them. PBWIN specific functions should only be used with PBWIN. PBCC specific functions should only be used with PBCC. Either compiler will say horrible things about your code if you mix them up. Anything else works in both compilers.

    #compile exe "yourfile.exe"
    #compiler "PBCC"
    #link "YourLib.ext"

or

    #compile exe "yourfile.exe"
    #compiler "PBWIN"
    #link "YourLib.ext"

Can't be much easier than that.

[Michael Mattias]

If it works sometimes and not others, isn't "Use Caution" an appropriate suggestion?

[Dale Yarker]

Strictly compile time, how about "Be aware"?

[Steve Hutchesson]

Michael,

I think its get the context first, UI versus console, the two compilers share a massive amount of code but their different targets say what is specific to each compiler. The next things is to remember the difference. I regularly get caught leaving a "WAITKEY$" in code that I developed in PBCC then used in PBWIN. I don't use DDT so I don't get caught the other way.

[Stuart McLachlan]

Another note of caution. Both PBCC and PBWIN have a "?" command, but they are compiler specific.
So SLL code containing "?" will compile with either compiler, but PBCC compiles it as PRINT, PBWIn compiles it as MSGBOX - making the SLL un-linkable with the "other" compiler.

(Consider the use of an API Messagebox or a TXT window if you need need to display text in a cross-compilable SLL)