> + lots more undefined reference errors. I tried running the link step in > my build without the '-shared' option and I got the same set of errors. > Does '-shared' work in Cygwin gcc? Some random web page [1] suggests > that it does, but I thought I saw in 'man ld' that the correct option is > -Bdynamic. > > You might also want to try running the link step with the -v option > (show the real command being run) or the -t option (show the files being > loaded by the linker.
I've tried hardvesting documentation on linking issues and especially on weak linking which apparently is being used in linux. I found several references saying that cygwin does not support weak linking. http://projects.cs.kent.ac.uk/projects/kroc/trac/changeset/4308 http://www.caam.rice.edu/caam/trs/2003/TR03-15.pdf => 2.3 Linking and Weak Symbols -------------------------------------------------------------------------------- The ‘problem’ with this scheme is that it requires either that the binary format supports tagging these undefined symbols as weak or that the linker allows user symbols in a DSO to remain unresolved. Neither of these is an option under Cygwin: Windows PE-COFF binaries do not support weak symbols and, unlike Linux, the Cygwin linker will complain when DSOs contain unresolved symbols. -------------------------------------------------------------------------------- Btw - I have tried this #pragma weak on gcc compilation - like this: #pragma weak global_namespace u.vptr = dlsym(handle, "gcc_plugin_set_param"); if(u.vptr) { u.fptr_set_param(0,(void*) global_namespace); } //if and after that gcc does compiles, however it crashes when I have tried to run it wil plugin. I haven't traced exact location, but I suspect this weak link - global_namespace. I have several practical questions about gcc compilation - 1. how to make it faster ? Apparently "make" will try to rebuild everything including standard libraries, meanwhile I'm intrested only in building gcc executables. 2. gcc.exe is not produced by default, after build I can see plenty of other binaries cc1.exe, cpp.exe, g++.exe, xgcc.exe, cc1plus.exe - but not gcc.exe. gcc.exe is produced only after "make install" and even then I don't see from which .exe files it were copied from. Then some question related to dehydra. Should we try to drop out weak linking approach and try somehow to link it manually ? I've checked from where dehydra plugin gets initialized - it's from c- opts.c, which is generic code - not c/c++ front end. (not in cp/ folder). Is there a possibility that your plugin will be enabled from example java code, and plugin will not work after that ? Should plugin gets initialized in c/c++ frontend code and pass 'global_namespace' pointer from there ? > > CIL link which your document mentiones is one approach to source code > > regeneration, however > > new language always bit scares me. No matter how advanced it is. > > CIL users like it a lot, but it is C only. How many CIL users there are ? If over 1000 then I'll probably check it through bit deeper. :) > If you can give me any practical compilation assitance with cygwin, it > > would be great. > > _______________________________________________ > > Unfortunately, I am totally not a Cygin expert. Neither I'm I. But about to become one unfortunately. :) _______________________________________________ dev-static-analysis mailing list [email protected] https://lists.mozilla.org/listinfo/dev-static-analysis
