I would like to load opengl32.dll at runtime (using LoadLibrary from Win32) and then load OpenGL2/3/4 functions. I tried to use glew for that, but it can't resolve some wgl functions.
So is there an easy way I can use glew to import OpenGL functionalities while loading opengl dynamically ?
It is possible to do what you are asking for, but you will have to go about it differently. Typically, when a shared library (or dll) is manually loaded at runtime, you will have to search, by symbol, for the functions you want to use and assign them to handles so you can call them.
What you are doing now will never compile because you are explicitly using symbol names that the linker cannot find. You have to replace all of these unresolved function calls with queries into your manually loaded shared library (opengl32.dll).
There's some good code you can use for reference in the glfw project. Take a look at both the _glfwInitWGL and loadWGLExtensions functions.
Related
This this Python Enhancement Proposal states that:
While it is possible, statically linking glibc is usually a bad idea
because certain important C functions like dlopen() cannot be called
from code that statically links glibc.
I don't have experience about how dynamically/statically linked library work internally, so I don't understand why you can't refer to a symbol dynamically from a static library?
I created a Qt static library following the instruction here:
http://qt-project.org/wiki/How_to_create_a_library_with_Qt_and_use_it_in_an_application
Then I tried to link the library with my own (non-Qt) application, and GCC complained about undefined references. Examining the library content using Linux nm utilty I found the function I intend to call has cryptic letters added before and after it.
Reading the instruction from the instruction link more closely, it suggests that I need to use use an import define so the right Qt macro can be called to import the function (which I assume renames the function to match the naming scheme in the library). But I don't really want to introduce Qt dependency in my main application.
What I really want to do is to build a UI frontend library with Qt, and my main application will simply link to it without having any Qt dependency. Is this possible? Or am I using Qt in an unintended manner?
Thanks.
It sounds like you're running into C++ namespace mangling. Try adding an 'extern "C" {}' block around your libraries export.
The main point of the QLibrary::resolve function is to provide an abstraction layer so you don't have to worry about the win32 command or the linux command for resolving a symbol. It shouldn't be necessary to use a library created with Qt.
I have created a program using a number of statically linked libraries. My question is, are these libraries required to be present when running the executable? It seems that the libraries are accessed as the program will not run if the libraries are not present and their path not included in the LIBPATH environment variable. I had the impression that since they were statically linked they would not be required at runtime.
No, static linking means they are included in the binary you build (and so they are "loaded" when you compile and link, if you will).
i have to create a dynamically linked library in zOS . What are the options to be passed to the compiler.
Also, how to check if a library in zOS is dynamically linked[dependent] on other libraries.
we have ldd in linux, which shows this linkage. Do we have a 'ldd' equivalent in zOS land?
You don't say it directly, but I assume you mean a C/C++ DLL. You can do shared libraries in other languages as well (even assembler), but the steps would be different.
First, you need to decide what you want to export. A lot of the IBM examples use the compiler EXPORTALL directive, but be aware this can lead to very slow executables, depending on your coding style. If you don't do EXPORTALL, you'll need #pragma export for anything (code or data) you want to export. Don't forget you can export data (variables) as well as executable functions...sometimes you'll need this to share data with DLL functions.
Then, you need to set your compile options on both client (caller) and DLL to use the DLL linkage...this is the -Wc,DLL compile option and when enabled, it generates extra logic in your program to load and manage the DLL. It's a good idea to also include #pragma csect for your exported functions if you think you'll ever have the need to update the DLL without replacing it entirely.
When you link your DLL, be sure to specify the -Wl,DLL option (there are lots of ways...this part is different if you link in batch - I'm assuming you're building in a make file of some sort). The link will generate the actual DLL, as well as a "side deck" containing "IMPORT" statements for all of your exported functions. You'll need these to link any of the client-side programs that you expect to call the DLL. For example, if your imports are in a file called AAA.x, c89 -Wc,DLL myapp.c AAA.x would compile the calling code, with awareness that functions in AAA.x are off in some sort of DLL.
To your point about DLLs calling other DLLs, don't forget that a DLL can both "serve" and "consume" functions...by including the side deck for functions in other DLLs, you can have a DLL that provides some functions while calling other DLLs to access others.
The actual DLL itself can be in several places depending on the nature of your app. If you're UNIX Services friendly, it's just an executable in LIBPATH. It can also be STEPLIB, LNKLST, LPA and so forth.
If you need to, you can access your DLLs explicitly at runtime using dlopen(), dlsym() and so forth. Generally, this lets you control exactly which DLL you're using (sometimes handy if the user can provide one himself), and it gives you what amounts to function pointers that are resolved within the DLL.
There are some other basic things to consider when linking, such as ensuring that your code is reentrant. Most of these are spelled out in the IBM documentation, and if you build with things like "c89" (or equivalent), the correct options are usually setup for you automatically (in fact, to get a good idea of what's going on, turn on the verbose output and see all the parameters for yourself).
If you need to build up a cross reference of what calls what, the UNIX Services "nm" command can give you that information. If you produce detailed link-edit listings, all the data is in there too when you're building your DLLs.
Good luck!
I'm using a licensed version of Flex Builder Pro to develop an application.
I compiled the swc and generated swf successfully using ANT tasks.
It contains an Advanced Data Grid also. When this application is accessed, I get a runtime error and it fails to load.
TypeError: Error #1007: Instantiation attempted on a non-constructor.
at mx.controls::AdvancedDataGridBaseEx/getSeparator()
at mx.controls::AdvancedDataGridBaseEx/createHeaderSeparators()
at mx.controls::AdvancedDataGrid/createHeaderSeparators()
at mx.controls::AdvancedDataGridBaseEx/drawSeparators()
at mx.controls::AdvancedDataGridBaseEx/updateDisplayList()
at mx.controls::AdvancedDataGrid/updateDisplayList()
at mx.controls.listClasses::AdvancedListBase/validateDisplayList()
at mx.managers::LayoutManager/validateDisplayList()
at mx.managers::LayoutManager/doPhasedInstantiation()
at Function/http://adobe.com/AS3/2006/builtin::apply()
at mx.core::UIComponent/callLaterDispatcher2()
at mx.core::UIComponent/callLaterDispatcher()
I'm adding datavisualization.swc and datavisualization_rb.swc in the build paths.
How can I successfully compile the application without any runtime errors?
Please help.
Include the swcs in the library path as shown here.
Maybe this helps: http://kb2.adobe.com/cps/403/kb403121.html
By coincidence I had the same error a couple of days ago. The source of this problem was a library against I built, which was linked statically against an older version of the datavisualization libraries. Normally libraries should only be compiled against other libraries using the external-library-path compiler option, but this library was compiled incorrectly.
So that library contained older parts of datavisualization that were referenced by code in the library, while my code referenced newer parts from the datavisualization library itself. The result was a mix of older and newer datavisualization classes at runtime.
So check the SWCs that you include in your library path. You can extract these with a ZIP tool. You will then find a catalog.xml file in there. Search for mx/controls/AdvancedDataGrid in this file. In case you can see it included in the catalog, you've found the bogus library.