On Sun, 09 Nov 2008, Szak�ts Viktor wrote: Hi Viktor,
>>> The same thing I've already posted. The only way >>> hbrun-dll.exe can be built now is to use >>> 'set C_USR=-DHB_DYNLIB' >> Why? What is the error? > I've posted it to the dev list, they were coming > after those BCC warnings you've already fixed. > Missing symbols when trying to link hbrun-dll.exe. This should be fixed by adding PP and COMMON libs. using global export flag will not help here in any way. > Vista introduced a new feature which needs all executable > to be relocatable to be able to load the .exe to any address > to make unwanted code execution more complicated. This is > called ASLR. It looks this is the direction Windows is heading. > BTW, for reason above I've just enabled '/dynamicload /fixed:no' > MSVC linker option in my local app, which makes a bigger final > .exe with ASLR potential on Vista. BCC always adds relocation > info. Please remember that it may also reduce the speed. It's not only additional information but also possibly different code. > Do you think in Linux development there won't be similar > direction in the future? IOW, does 'no-shared' have a > bright future in Linux, or will it rather die out? Hard to say but in Linux it does not have the same meaning as in Windows. Please remember that Linux uses different memory blocks for code and data. Code segments are readonly and data segments does not have execution flag so it's not possible to add "unwanted code" in the way as in Windows. The above explanation looks for me like a pseudo security hack for missing basic protection present in most of *nixes and it does not increase security because it's still possible to write relocatable "unwanted code". >> But please make it by simple DLL_OBJ_DIR=$(OBJ_DIR) executed optionally >> so people who want to tuned final Harbour binaries for optimal code >> size can easy use current form. > That's what I did so far. I'm trying to keep everything > we have, except HB_BUILD_DLL option, which I'd like to > remove, but the internal logic should stay for the most > part. So it basically comes down to removing this option > and making building .dlls a must, regardless of the > internal implementation for GCC, and a quicker one for > BCC/MSVC. It's fine for me. > Now I have to change the build process to use HARBOURFLAGSLIB > and HARBOURFLAGSEXE instead of current HARBOURFLAGS and > HARBOURFLAGSDLL, the difference between them is -n1 option > vs -n. Executables should use -n, libs (.dll and .lib) > should use -n1. It's enough to add support for MAIN() as default startup function when non of functions is declared with HB_FS_FIRST and make all builds with -n1. We can also define that when MAIN() exists it's an application entry point instead of symbol defined with HB_FS_FIRST. It will have higher priority. In such case we can remove -n1 flag. Choose what you prefer and I'll implement it. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
