Hello, Markus Duft wrote: > I implemented wgcc (a compiler wrapper behaving like gcc but calling > cl.exe). Since the target should be to compile sources with minimum > changes i have done lot's of work for this.
That's certainly a good idea. I would consider such a tool usable only if it had no arbitrary limits, such as a maximum size of 65000 bytes for an exports list, or similar. (I saw an MSVC error message once "Too many variables in function" for a function with more than 1024 local variables, and don't want to repeat such an experience.) > (gets even better in wgcc v2, one will not need to export anymore, just > import ;o)). This works for shared, and (!!) for static libraries, since > wgcc generates some symbols. Very nice. "Just import" is also the point of the proposed libtool changes. If everyone was using either GNU ld or your wgcc, one could consider implementing this functionality in GNU ld. But there are people who use MSVC direcly or using other wrappers. > This was one of the main problems, that any executeable sources can > _never_ know which library gets linked statically or shared. Yes, I agree that adding the extra export symbols not at DLL construction time but also at .EXE construction time is even better. It allows not only to use the same macro #define DLL_VARIABLE __declspec(dllimport) for all sources that end up in shared libraries but also for any source code, regardless whether it ends up being built shared or statically. > Maybe you want to have a look at it Where are the sources to your wgcc2 ? The source of wgcc1 doesn't appear to generate exports as needed. Bruno _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
