From: Dill, J. <joh...@ui...> - 2004-06-30 15:42:54
|
>> Now I find when I copy libuirotime.so to libuirotime.dll, the linker = finds the library now, but when I try to run I get a message: >It is conventional to name shared libraries .dll. I do not think .so = is >recognized at all. You should name it .dll from the beginning, and = link >against it with that name. I changed my makefile system to output with dll extension and it seems = to work fine. >> The dynamic link library libuirotime.so could not be found in the = specified path >> 'LONG PATH'. >As for the second error, note that DLLs are searched for in the same >path as executables. eg, there is no LD_LIBRARY_PATH; PATH is searched >instead. Here, I'm still having problems. When I run the executable, it gives me = a path that it is checking, and if I copy the library to one of those = directories, it runs correctly. From where does the path come from. It = appears to search for the library in the mingw PATH, etc/profile, the = current directory, and the location of the executable. Is this a = correct assessment? Can I use export to change the path to add my = directory? I tried, but I'm not sure if I have the correct syntax. Is there any possibility to do something link -rpath to store the = runtime path with the executable? It appears when I do a ld.exe --help, = but doesn't appear to work. It would be nice if something like this could work, because it will be = annoying to change the PATH when I want to run a Release/Debug mode, or = test the executables for different compilers. Since I'm new to windows programming environment, what are the basic = rules of thumb on how to install shared libraries when on Windows? Many thanks for your help, John |
From: Aaron W. L. <aar...@aa...> - 2004-06-30 18:16:48
|
Dill, John wrote: >>As for the second error, note that DLLs are searched for in the same >>path as executables. eg, there is no LD_LIBRARY_PATH; PATH is searched >>instead. > > Here, I'm still having problems. When I run the executable, it gives me a path that it is checking, and if I copy the library to one of those directories, it runs correctly. From where does the path come from. It appears to search for the library in the mingw PATH, etc/profile, the current directory, and the location of the executable. Is this a correct assessment? Can I use export to change the path to add my directory? I tried, but I'm not sure if I have the correct syntax. PATH is actually a Windows global environment variable that has paths to the Windows command line tools. Your MinGW start scripts or MSYS appends the MinGW paths to this at startup. The Windows platform SDK has details on exactly how DLLs are searched for, so you really probably should check out that. The easy way to fix this is to just add it to your path: export PATH=c:/my/new/path/to/dll:%PATH I think the path will need to be a valid win32 path, not just a MSYS path which win32 doesn't understand. Also, you could just copy to the DLL to the same dir as the executable, or put it in c:\windows\system32, or some other place that Windows searches for the DLL. > Is there any possibility to do something link -rpath to store the runtime path with the executable? It appears when I do a ld.exe --help, but doesn't appear to work. This is not the proper way to do this on Win32, and almost certainly doesn't work. > Since I'm new to windows programming environment, what are the basic rules of thumb on how to install shared libraries when on Windows? Usually you just put them in the same dir as the executable, and everything 'just works.' Aaron W. LaFramboise |