Qbasicnews.com

Would it be feasible, in the future, to permit the user to choose what libraries to link statically and what to link dynamically at compiletime? (it could be useful for static executables on lower-end systems or to maybe dynamically link rtlib to shave a few k off of an executable)

command such as this would be nice:

runtime dll call:

rtlib embedded linked:

keyword lib or link determine the method on how dll will be load by user program.

doing that would require two separate .a files for each lib, one with all the lib code to be statically linked and one import lib for the DLL, which would also have to be distributed.

Quote:doing that would require two separate .a files for each lib, one with all the lib code to be statically linked and one import lib for the DLL, which would also have to be distributed.

That doesn't sound too bad... is there a better alternative?

Why not just use the DLL? There are so many benefits to using DLLs over static libraries. Multiple programs can access the library at once, meaning less disk space used, and you can often upgrade the DLL without recompiling the application. So what if it's an extra file or two? The benefits far outweigh such a pitiful drawback.

well, it might not sound too bad until you realize that the lib you want to statically link is closed-source or does not have an option to build a static lib - you can't just magically convert a DLL into a static lib; the memory fixups wouldn't be done as in a DLL so none of the memory references would be right, etc...

Quote: and you can often upgrade the DLL without recompiling the application

I was waiting for someone to point out this little fact. I was getting ready to mention this, myself.

Is it just me, or is your website down?
I was going to go out to it to, but I get a "not found" page instead...

The website's down temporarily, but it'll be restored within the next couple of days. Still recovering from the RAID controller failure.