38acdb8c30
--- Modified erd/src/erdinternal.c because Cygwin appears to define fpos_t as a long (it is not a structure, as with Linux) BASE/MSX/ERD/WDSSIM ------------------- Cygwin makefiles had been building code using MingW. This was confusing, as one might expect such makefiles to produce cygwin DLLs and executables and not native windows (i.e. MingW) DLLs and executables. Also, this was a problem because sometimes one would prefer to have Cygwin DLLs because one wants to produce Cygwin executables using them. Practically, it can be more convenient to produce Cygwin executables for a Windows target machine, just because the Cygwin environment is closer to a complete Unix environment. In fact the motivation for this was the need to build WDSSim for a windows target, and this led to annoying complications with libxml2 libraries and include files when trying to build everything as native Windows using MingW. Now, build/Cygwin makefiles are producing Cygwin DLLs/executables and NOT native windows DLLs/executables. The old Cygwin-MingW makefiles have been retained, but placed in new MingW build subdirectories for those cases when one really wants to use MingW to build for a native windows target. FILE NAME CONVENTIONS --------------------- All this is terribly confusing, and we wish for a plain old Linux environment. With regard to file and library names, there is significant potential to confuse things. Accordingly we have defined the following standard naming convention that eventually everything in ENGCVS should use. If one has a library called "mylib", the names of the various files should be the following, BY CONVENTION (i.e. they don't have to be these names, but if they aren't, then you'll just confuse the heck out of the rest of us). CYGWIN DLL (shared library) cygmylib.dll (DLL) (note 'cyg' prefix indicates it is a cygwin object) cygmylib.def (DEF) libcygmylib.dll.a (import lib) (note '.dll' indicates it is an import library pointing to a DLL) CYGWIN ARCHIVE libcygmylib.a (object archive) (note the absence of '.dll' indicates it is an object archive an not a DLL import lib) MINGW DLL (shared library) mylib.dll (DLL) (note this is a native windows DLL, and the absence of 'cyg' shows that) mylib.def (DEF) libmylib.dll.a (gcc import lib) mylib.lib (LIB) (msvc import lib, pointing to same DLL - produced using msvc LIB.EXE) MINGW ARCHIVE libmylib.a (object archive) LINUX SO (shared library) libmylib.so (SO - shared object library, Linux analogue to windows DLL) (No DEF or import library required) LINUX ARCHIVE libmylib.a (object archive) Note how these names uniquely specify the target (cygwin, windows, Linux) as well as the file type (DLL, SO, DEF, import lib, object archive). Or at least mostly uniquely - note that the object archive is the same name on Linux and under MinGW. This shouldn't be problem since Linux object archives shouldn't ever be present on Windows machines, and vice-versa. And if they are (by mistake/accident), the codes won't link or run so there will be definitive identification of the error. Finally, for an executable code "mycommand" we have the following CONVENTION: mycommand.exe (Windows/MingW or Windows/MSVC) cygmycommand.exe (Windows/Cygwin) mycommand (Linux) git-svn-id: https://epanet.svn.sourceforge.net/svnroot/epanet/BASE/trunk@221 c320cabd-cc23-0410-96d8-e60fbf53ed7f
5 lines
100 B
Bash
Executable File
5 lines
100 B
Bash
Executable File
#!/bin/sh
|
|
export PATH=libdir:$PATH
|
|
export LD_LIBRARY_PATH=libdir:$LD_LIBRARY_PATH
|
|
exec exename "$@"
|