GNOME Bugzilla – Bug 309030
Gtk::TreeModelColumn not imported properly on windows
Last modified: 2006-04-14 11:31:19 UTC
Please describe the problem: Gtk 2.4.14 & 2.6.8 gtkmm 2.4.8, 2.4.10, 2.4.11, 2.6.3 windows xp mingw gcc 3.4.2 & 3.4.4 The linker fails to link examples that use Treeview. Here is the output: Info: resolving VTT for Gtk::TreeViewColumn by linking to __imp___ZTTN3Gtk14TreeViewColumnE (auto-import) Info: resolving vtable for Gtk::TreeViewColumnby linking to __imp___ZTVN3Gtk14TreeViewColumnE (auto-import) messageslist.o: In function `ZN3Gtk14TreeViewColumnC1IN4Glib7ustringEEERKS3_RKNS_15TreeModelColumnIT_EE': C:/msys/1.0/home/Kid/gtkmm-2.6.3/examples/book/paned/../../../gtk/gtkmm/treeviewcolumn.h:(.text$_ZN3Gtk14TreeViewColumnC1IN4Glib7ustringEEERKS3_RKNS_15TreeModelColumnIT_EE[Gtk::TreeViewColumn::TreeViewColumn<Glib::ustring>(Glib::ustring const&, Gtk::TreeModelColumn<Glib::ustring> const&)]+0x1c): variable 'VTT for Gtk::TreeViewColumn' can't be auto-imported. Please read the documentation for ld's --enable-auto-import for details. C:/msys/1.0/home/Kid/gtkmm-2.6.3/examples/book/paned/../../../gtk/gtkmm/treeviewcolumn.h:(.text$_ZN3Gtk14TreeViewColumnC1IN4Glib7ustringEEERKS3_RKNS_15TreeModelColumnIT_EE[Gtk::TreeViewColumn::TreeViewColumn<Glib::ustring>(Glib::ustring const&, Gtk::TreeModelColumn<Glib::ustring> const&)]+0xb8): variable 'VTT for Gtk::TreeViewColumn' can't be auto-imported. Please read the documentation for ld's --enable-auto-import for details. C:/msys/1.0/home/Kid/gtkmm-2.6.3/examples/book/paned/../../../gtk/gtkmm/treeviewcolumn.h:(.text$_ZN3Gtk14TreeViewColumnC1IN4Glib7ustringEEERKS3_RKNS_15TreeModelColumnIT_EE[Gtk::TreeViewColumn::TreeViewColumn<Glib::ustring>(Glib::ustring const&, Gtk::TreeModelColumn<Glib::ustring> const&)]+0x173): variable 'VTT for Gtk::TreeViewColumn' can't be auto-imported. Please read the documentation for ld's --enable-auto-import for details. messageslist.o: In function `ZN12MessagesListD1Ev': C:/msys/1.0/home/Kid/gtkmm-2.6.3/examples/book/paned/messageslist.cc:51: variable 'VTT for Gtk::TreeViewColumn' can't be auto-imported. Please read the documentation for ld's --enable-auto-import for details. C:/msys/1.0/home/Kid/gtkmm-2.6.3/examples/book/paned/messageslist.cc:51: variable 'VTT for Gtk::TreeViewColumn' can't be auto-imported. Please read the documentation for ld's --enable-auto-import for details. messageslist.o: In function `ZN3Gtk14TreeViewColumnC1IN4Glib7ustringEEERKS3_RKNS_15TreeModelColumnIT_EE': C:/msys/1.0/home/Kid/gtkmm-2.6.3/examples/book/paned/../../../gtk/gtkmm/treeviewcolumn.h:(.text$_ZN3Gtk14TreeViewColumnC1IN4Glib7ustringEEERKS3_RKNS_15TreeModelColumnIT_EE[Gtk::TreeViewColumn::TreeViewColumn<Glib::ustring>(Glib::ustring const&, Gtk::TreeModelColumn<Glib::ustring> const&)]+0xf1): variable 'vtable for Gtk::TreeViewColumn' can't be auto-imported. Please read the documentation for ld's --enable-auto-import for details. C:/msys/1.0/home/Kid/gtkmm-2.6.3/examples/book/paned/../../../gtk/gtkmm/treeviewcolumn.h:(.text$_ZN3Gtk14TreeViewColumnC1IN4Glib7ustringEEERKS3_RKNS_15TreeModelColumnIT_EE[Gtk::TreeViewColumn::TreeViewColumn<Glib::ustring>(Glib::ustring const&, Gtk::TreeModelColumn<Glib::ustring> const&)]+0xf8): variable 'vtable for Gtk::TreeViewColumn' can't be auto-imported. Please read the documentation for ld's --enable-auto-import for details. Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
Use the '-Wl,--enable-runtime-pseudo-reloc' option at link time.
That won't work properly. While that app will link, it won't run. The solution is to dllimport/dllexport on windows. See https://sourceforge.net/tracker/index.php?func=detail&aid=1229226&group_id=2435&atid=102435 for more info.
That _declspec() declaration worked for me just great! Thanks. But I think that maybe the proper way would be to have -DGLIBMM_DLL as a CFLAG and the line read as: class GTKMM_API TreeViewColumn : public Gtk::Object
The best solution is to only use CFLAG when building gtkmm. Since gtkmm is currently using --export-all it would be some thing like: CFLAGS+= -DGTKMM_DLL ; when BUILDING gtkmm.dll #ifndef GTKMM_DLL #define GTKMM_API __declspec(dllimport) #else #define GTKMM_API #endif or the other case could be dllexport. This would need to be done separately for each dll glibmm, gdkmm, atkmm, pangomm, gtkmm. The ?MM_API would need to be applied to both data & classes. Hmm, isn't this already needed for vc++?
True, but -DGLIBMM_DLL turns on exports not only for Glibmm, but also Pangomm, Atkmm, Gtkmm, etc.
If we are already using --export-all, why would we also need __declspec() in the sources?
THe problem has to due with importing classes from the dll. More specifically it it's a problem when deriving froma class in a dll or using one of the templated constructs. Without the __declspec(dllimport) gcc doesn't know it needs to emit the type tables for use by the calling code. See the referenced g++ issue above for more info. Strictly speaking it's not a g++ bug since auto-import is an extension created to try and make windows dll's behave like .so's.
Yes, this can definitely be a pain. What would be preferable, IMHO, would be use use a .def or .sym file to define symbols to be exported, and leave the source alone. This would be -very- nice on C/Gtk/Glib etc where these declarations sprinkled all over the place are a terrible pain to deal with.
I've changed the summary to reflect the real problem which is deals with importing classes. When deriving from or instancing a template method of a class residing in a dll g++ needs to add the vtable and type info into application. This is currently on done when the class is marked dllimport. While this is being worked on in gcc HEAD I don't when it will be done nor if it will be backported to 3.4.
So, this would be a workaround for a bug in gcc? And that bug is that --export-all does not export everything? > Strictly speaking it's not a g++ bug since auto-import is an extension created > to try and make windows dll's behave like .so's. But it's clearly not behaving like a .so, so surely it's a bug?
Also, I don't seen any patch here.
Let's see if I can clear this up. --export-all works, everything is exported properly. The bug per se is with auto-import. When deriving, g++ needs the address of the vtable & type info structures of the base classes. These addresses must be constant, however they are relocatable in a dll. The solution is for g++ to generate new sturcts and use those. The bug is that it only knows to do this when the class is marked dllimport. There is a related issue with importing data. Currently warnings are generated when auto-import data such as Gtl::Stock::NEW. Its been a long time since this was last discussed but iirc dll's could not directly export data, instead it was simulated by having the import symbols point to a function which returned the data. I think that all compilers still generate data exports this way. I think that it's now possible to directly export data but I'm not certain. Auto-import links against the function symbol which means that some uses are not possible which is why the warning occurs. I'm don't remember if/how marking it dllimport deals with this but a least it stops the warnings. I don't really expect the fixes to be back ported to gcc 3.4.x. As for a patch, both solutions have already been mentioned.
> As for a patch both solutions have already been mentioned. Please pick the best one and provide an actual, tested, patch.
Created attachment 49172 [details] [review] Adds GTKMM_API to the class declaration. Use -p0 at the toplevel. This trivial one-liner should do the trick. It just does the GTKMM_API decl above.
I forgot to mention: that patch works, and we are using it in our port of Inkscape to Windows.
Hi guys, I also believe the GTKMM_API tag will do the trick. Cannot test it myself though as I recently experienced a very bad hdd crash on my laptop. I won't be able to rebuild gtkmm for a few days. If the patch works, please also patch the ChangeLog and add a comment that points to this bugzilla entry.
Committed in HEAD and in the gtkmm-2-6 branch. Thanks. Please try to create a cvs patch in future instead of patching a generated file.
Created attachment 61844 [details] [review] Similar patch for version 2.2.12 Just for the record, here is what I did to avoid the problems discussed here for version 2.2.12. It is essentially the same fix as the one that was commited for 2.6, but it also 1. Applies a similar update to Menu_Helpers::MenuList, where I got exactly the same problem. 2. Moves definition of templated TreeViewColumn constructor into the class declaration. This is a workaround for gcc 3.4 issues - when the code is organised this way, I can at least build the example code without getting an internal compiler error. 3. Adds "inline" keyword to TreeViewColumn::pack_start() and TreeViewColumn::pack_end() defintions. Unlike what you may be used to for templates, methods would not be inlined without this, and there was also a warning message about conflicts between dllimport and local method definitions. Note that gtkmm 2.6 always had "inline" here.
2. Do you know why this works in gtkmm 2.4/6/8, or is that code different?
Your patch also seems to remove a lot of reference documentation. Could you submit a corrected patch, please?
Regarding 2, I think the answer is that it actually doesn't. I'm talking about a workaround for the internal compiler error described in https://sourceforge.net/tracker/index.php?func=detail&aid=1229226&group_id=2435&atid=102435, and the way I interpret that text, you generally need at least version 4.1 of g++ in order to compile TreeViewColumn updated with "declspec(_dllimport)" (via GTKMM_API) - and that's also true for other gtkmm versions than 2.2. I'm not able to verify that right now, though, due to other build problems. I'm not sure I understand how to correct the patch - and at the same time ensure that there is consistency between the files. I wanted the patch to update both treeviewcolumn.hg and treeviewcolumn.h so that you would get the correct behaviour regardless of whether the source code generation step was included - so I edited the former and re-generated the latter via make - and got a .h file without documentation...
> Regarding 2, I think the answer is that it actually doesn't. I don't understand this. Can you concisely describe the suggested fix? > I wanted the patch to update both treeviewcolumn.hg and treeviewcolumn.h treeviewcolumn.h is a generated file - you should not be changing it. Making a cvs patch will make this clearer/easier. > so I edited the former and re-generated the latter via make - and got a .h file without documentation... Ah, OK, then it's not a problem, because that part of the patch will never be used. I should have looked at it more closely.
By the way, does it help if you use a newer glibmm (such as 2.10). I don't think that glib 2.10 and glibmm 2.10 will bring in extra dependencies.
Oh ignore that. That's no good for gtkmm 2.2.
(In reply to comment #22) > > Regarding 2, I think the answer is that it actually doesn't. > > I don't understand this. Can you concisely describe the suggested fix? Simply put, the TreeViewColumn has a construct of the form class A { public: ... template<class T> A(T arg); }; template<class T> inline A::A(T arg) { <Do the object init> } The patch changes that to class A { public: ... template<class T> A(T arg) { <Do the object init> }; }; These are two fully equivalent ways of defining an inline method (template), and I don't think you can generally say that one is "better" or "more correct" than the other. However, g++ versions prior to 4.1 apparently have a bug in the handling of constructors that are function templates, that under certain conditions causes a compiler crash during template instantiation (i.e. when compiling code that uses the constructor in question.) I'm not sure what excatly those conditions are, but I found that the crash stopped occuring for the gtkmm example code, and also some of my own tests, after I changed the code layout as indicated above.
(In reply to comment #23) > By the way, does it help if you use a newer glibmm (such as 2.10). I don't > think that glib 2.10 and glibmm 2.10 will bring in extra dependencies. > (In reply to comment #24) > Oh ignore that. That's no good for gtkmm 2.2. > This may be relevant in conjunction with another incarnation of this issue, however: I find that the fix doesn't really work when building gtkmm 2.6.5 on top of glibmm 2.6.1 using "MinGW" gcc. The addition of GTKMM_API makes no difference, as the macro will in fact have an emtpy body. "__declspec(dllimport)" is included if, and only if, GLIBMM_DLL is defined, which it actually isn't. This should be clear from the following section of glibmmconfig.h: #if defined(_WIN32) // Win32 compilers have a lot of varation #if defined(_MSC_VER) #define GLIBMM_MSC #define GLIBMM_WIN32 #define GLIBMM_DLL #elif defined(__CYGWIN__) #define GLIBMM_CONFIGURE #elif defined(__MINGW32__) #define GLIBMM_WIN32 #define GLIBMM_CONFIGURE #else So perhaps this bug ought to be reopened (can't do it myself...), or should I add a new one?
I reopened the bug. But please provide a simple testcase. It is very difficult to track this bug without an example that shows actual and expected results. I want to see/look for the clear link between a possible bug in gtkmm (on win32) and some bug in the mingw32 target of gcc. Ideally, we should have something like the bug tracking done for bug #158040 with Visual Studio.
Created attachment 62446 [details] Test program Code that may be used to reproduce error. Steps to reproduce: 1. i386-mingw32-g++ -I/usr/i386-mingw32/include/gtkmm-2.4 -I/usr/i386-mingw32/lib/gtkmm-2.4/include -I/usr/i386-mingw32/include/glibmm-2.4 -I/usr/i386-mingw32/lib/glibmm-2.4/include -I/usr/i386-mingw32/include/gdkmm-2.4 -I/usr/i386-mingw32/lib/gdkmm-2.4/include -I/usr/i386-mingw32/include/pangomm-1.4 -I/usr/i386-mingw32/include/atkmm-1.6 -I/usr/i386-mingw32/include/gtk-2.0 -I/usr/i386-mingw32/include/sigc++-2.0 -I/usr/i386-mingw32/lib/sigc++-2.0/include -I/usr/i386-mingw32/include/glib-2.0 -I/usr/i386-mingw32/lib/glib-2.0/include -I/usr/i386-mingw32/lib/gtk-2.0/include -I/usr/i386-mingw32/include/pango-1.0 -I/usr/i386-mingw32/include/atk-1.0 -g -c -o treeview.o treeview.C 2. i386-mingw32-g++ treeview.o -Wl,--enable-auto-import -lgtkmm-2.4 -lgdkmm-2.4 -latkmm-1.6 -lgtk-win32-2.0 -lpangomm-1.4 -lglibmm-2.4 -lsigc-2.0 -lgdk-win32-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangowin32-1.0 -lgdi32 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -liconv -o treeview.exe Expected results: Successful build of treeview.exe Actual results: treeview.o(.text$_ZN3Gtk14TreeViewColumnC1IN4Glib7ustringEEERKS3_RKNS_15TreeModelColumnIT_EE+0x113): In function `ZN12MessagesListC2Ev': /usr/work/port/src/tst/gtkmm/treeview.C:15: variable 'vtable for Gtk::TreeViewColumn' can't be auto-imported. Please read the documentation for ld's --enable-auto-import for details. treeview.o(.text$_ZN3Gtk14TreeViewColumnC1IN4Glib7ustringEEERKS3_RKNS_15TreeModelColumnIT_EE+0x122):/usr/work/port/src/tst/gtkmm/treeview.C:15: variable 'vtable for Gtk::TreeViewColumn' can't be auto-imported. Please read the documentation for ld's --enable-auto-import for details.
As for the segfault, I'm reproducing that using: 1. perl -pi.dllimport -e 's/GTKMM_API/__declspec(dllimport)/' /usr/i386-mingw32/include/gtkmm-2.4/gtkmm/treeviewcolumn.h 2. i386-mingw32-g++ -I/usr/i386-mingw32/include/gtkmm-2.4 -I/usr/i386-mingw32/lib/gtkmm-2.4/include -I/usr/i386-mingw32/include/glibmm-2.4 -I/usr/i386-mingw32/lib/glibmm-2.4/include -I/usr/i386-mingw32/include/gdkmm-2.4 -I/usr/i386-mingw32/lib/gdkmm-2.4/include -I/usr/i386-mingw32/include/pangomm-1.4 -I/usr/i386-mingw32/include/atkmm-1.6 -I/usr/i386-mingw32/include/gtk-2.0 -I/usr/i386-mingw32/include/sigc++-2.0 -I/usr/i386-mingw32/lib/sigc++-2.0/include -I/usr/i386-mingw32/include/glib-2.0 -I/usr/i386-mingw32/lib/glib-2.0/include -I/usr/i386-mingw32/lib/gtk-2.0/include -I/usr/i386-mingw32/include/pango-1.0 -I/usr/i386-mingw32/include/atk-1.0 -g -c -o treeview.o treeview.C 3. mv /usr/i386-mingw32/include/gtkmm-2.4/gtkmm/treeviewcolumn.h.dllimport /usr/i386-mingw32/include/gtkmm-2.4/gtkmm/treeviewcolumn.h Actual results: /usr/i386-mingw32/include/gtkmm-2.4/gtkmm/treeviewcolumn.h: In constructor `Gtk::TreeViewColumn::TreeViewColumn(const Glib::ustring&, const Gtk::TreeModelColumn<ColumnType>&) [with T_ModelColumnType = Glib::ustring]': /usr/i386-mingw32/include/gtkmm-2.4/gtkmm/treeviewcolumn.h:851: instantiated from `Gtk::TreeViewColumn::TreeViewColumn(const Glib::ustring&, const Gtk::TreeModelColumn<ColumnType>&) [with T_ModelColumnType = Glib::ustring]' /usr/i386-mingw32/include/gtkmm-2.4/gtkmm/treeview.h:1365: instantiated from `int Gtk::TreeView::append_column(const Glib::ustring&, const Gtk::TreeModelColumn<ColumnType>&) [with ColumnType = Glib::ustring]' treeview.C:19: instantiated from here /usr/i386-mingw32/include/gtkmm-2.4/gtkmm/treeviewcolumn.h:851: internal compiler error: in rest_of_handle_final, at toplev.c:2067 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions.
Actually, make that just: 1. i386-mingw32-g++ -DGLIBMM_DLL -I/usr/i386-mingw32/include/gtkmm-2.4 -I/usr/i386-mingw32/lib/gtkmm-2.4/include -I/usr/i386-mingw32/include/glibmm-2.4 -I/usr/i386-mingw32/lib/glibmm-2.4/include -I/usr/i386-mingw32/include/gdkmm-2.4 -I/usr/i386-mingw32/lib/gdkmm-2.4/include -I/usr/i386-mingw32/include/pangomm-1.4 -I/usr/i386-mingw32/include/atkmm-1.6 -I/usr/i386-mingw32/include/gtk-2.0 -I/usr/i386-mingw32/include/sigc++-2.0 -I/usr/i386-mingw32/lib/sigc++-2.0/include -I/usr/i386-mingw32/include/glib-2.0 -I/usr/i386-mingw32/lib/glib-2.0/include -I/usr/i386-mingw32/lib/gtk-2.0/include -I/usr/i386-mingw32/include/pango-1.0 -I/usr/i386-mingw32/include/atk-1.0 -g -c -o treeview.o treeview.C (GLIMM_DLL will activate "__declspec(dllimport)" in GTKMM_API, so that it won't be necessary to update the header.)
As mentioned at the top of this bug report, you should build with the -Wl,--enable-runtime-pseudo-reloc flag. --enable-auto-import is already on by default. Do not define GLIBMM_DLL (or GTKMM_DLL). Alternatively, please provide a testcase that fails at run time when built with -Wl,--enable-runtime-pseudo-reloc.
I think you are wrong. The conclusion drawn earlier here is that --enable-pseudo-reloc cannot be used. The patch provided and the resolution of the bug is based on that conclusion. In other words, a fix has been commited to CVS and the code re-rereleased based on that notion. Also, the fix works *in principle*, but is never really activate because it makes the wrong assumptions about the macro setup.
Created attachment 62455 [details] [review] Workaround for compiler problem (gtkmm 2.6 version) After patching this way, I can build the example program successfully provided that I use -DGLIBMM_DLL. The internal compiler error no longer occurs, and another problem encountered on the way is also resolved: Unless "inline" is mentioned explictly for the inlined method templates, the compiler will say /usr/i386-mingw32/include/gtkmm-2.4/gtkmm/treeviewcolumn.h: In instantiation of `void Gtk::TreeViewColumn::pack_start(const Gtk::TreeModelColumn<ColumnType>&, bool) [with T_ModelColumnType = Glib::ustring]': /usr/i386-mingw32/include/gtkmm-2.4/gtkmm/treeviewcolumn.h:158: instantiated from `Gtk::TreeViewColumn::TreeViewColumn(const Glib::ustring&, const Gtk::TreeModelColumn<ColumnType>&) [with T_ModelColumnType = Glib::ustring]' /usr/i386-mingw32/include/gtkmm-2.4/gtkmm/treeview.h:1365: instantiated from `int Gtk::TreeView::append_column(const Glib::ustring&, const Gtk::TreeModelColumn<ColumnType>&) [with ColumnType = Glib::ustring]' treeview.C:19: instantiated from here /usr/i386-mingw32/include/gtkmm-2.4/gtkmm/treeviewcolumn.h:826: warning: function 'void Gtk::TreeViewColumn::pack_start(const Gtk::TreeModelColumn<ColumnType>&, bool) [with T_ModelColumnType = Glib::ustring]' is defined after prior declaration as dllimport: attribute ignored /usr/i386-mingw32/include/gtkmm-2.4/gtkmm/treeviewcolumn.h:826: warning: 'void Gtk::TreeViewColumn::pack_start(const Gtk::TreeModelColumn<ColumnType>&, bool) [with T_ModelColumnType = Glib::ustring]' defined locally after being referenced with dllimport linkage and the linker treeview.o(.text$_ZN3Gtk14TreeViewColumnC1IN4Glib7ustringEEERKS3_RKNS_15TreeModelColumnIT_EE+0x13d): In function `ZN12MessagesListC2Ev': /usr/work/port/src/tst/gtkmm/treeview.C:15: undefined reference to `_imp___ZN3Gtk14TreeViewColumn10pack_startIN4Glib7ustringEEEvRKNS_15TreeModelColumnIT_EEb'
Ok, now I understand your point. You want to get rid of the --enable-pseudo-reloc flag. Two comments though : 1. I would like to see a simple gtkmm example where the use of --enable-pseudo-reloc either generates some gcc error (with the "Please submit a full bug report" blabla) at compile time, or where the example builds but crashes/does not work correctly at runtime. Can you provide such a testcase ? 2. For the problem you encounter, this probably comes from the GTKMM_API tag attached to the TreeViewColumn class declaration in treeviewcolumn.h. I have to delete this tag when building with Visual Studio to avoid similar error messages. What if you delete it and build gtkmm without defining GLIBMM_DLL ?
Ok, I tested your patch and it looks ok with mingw32. Need to test it against Visual Studio though. Now a single question : instead of moving the definition of the TreeViewColumn constructor to the class declaration, can't you simply it "inline" it like you do with the pack_start and pack_end methods ?
(In reply to comment #34) > Ok, now I understand your point. You want to get rid of the > --enable-pseudo-reloc flag. Yes. And perhaps more importantly, I think I was supposed to be able to get rid of it simply by using a gtkmm version released after this bug was marked as fixed. I didn't really try "--enable-pseudo-reloc" earlier, though, since it had been rejected by others in the above notes. I have now tested it a bit, but not been able to reproduce the runtime problems. (In reply to comment #35) > Now a single question : instead of moving the definition > of the TreeViewColumn constructor to the class declaration, can't you > "inline" it like you do with the pack_start and pack_end methods ? Actually, I think I can. I thought I found earlier that I had to move the code, but after testing some more, I believe adding "inline" is enough.
Created attachment 62666 [details] [review] Proposed resolution of remaining issues for gtkmm 2.6.5
How is this different than what GKTMM_API does? What is this DLL_EXPORT macro?
While GTKMM_API will sometimes contain "__declspec(dllimport)", it is empty when building gtkmm 2.6 with mingw32-gcc using the default compiler options. One might of course change the macro definitions, but the current setup is correct in that "dllimport" is not needed at the other points where GTKMM_API is specified. DLL_EXPORT represents the only way I could think of to distinguish beetween header file inclusion for the purpose of building gtkmm itself, and for compilation of gtkmm client software. I thought I might use GTKMM_BUILD for this, but it looks like that macro is never defined. The actual DLL_EXPORT setup comes from the libtool script on the main source directory. But I'm now starting to wonder what will happen if the client software also has dlls built via libtool...
Instead of using __declspec(dllimport) and DLL_EXPORT directly in the file, GTKMM_API should be used instead. But this requires some changes to glibmm that I will apply to CVS later today. When done, I will adapt Toralf's patch and commit the gtkmm changes to CVS. We just have to be a bit careful here, as gtkmm has to build with Visual Studio too. Stay tuned...
(In reply to comment #40) > Instead of using __declspec(dllimport) and DLL_EXPORT directly in the file, > GTKMM_API should be used instead. Are you sure? GTKMM_API is what was used earlier, and it turned out that it didn't quite work. As you say, a glibmm change may fix this problem, but is that really right thing to do? I think the update you have in mind will enable __declspec(dllimport) on a lot of other places where we don't necessarily need it. The point is, based on the tests I've done, and also the information added by others here, I've concluded that the "dllimport" in TreeViewColumn is needed for somewhat different reasons and under different conditions from the other cases where GTKMM_API (or GLIBMM_API) is used. More specifically, when using ming gcc with auto-import, "dllimport" is required for TreeViewColumn only - not the other declarations including GTKM_API. Maybe including this attribute in a number of extra places won't matter a lot, though...
Actually GTKMM_API did not work on purpose (because GLIBMM_DLL was not defined with mingw32/cygwin as we were supposed to rely on the auto-import feature of gcc). I have commited changes to glibmm that define GLIBMM_DLL and build glibmm with GLIBMM_BUILD when using mingw32/cygwin. As a result, GLIBMM_API and GTKMM_API (if gtkmm is built with -DGTKMM_BUILD) are now active. The main reason why we should use GTKMM_API for TreeViewColumn is consistency with Visual Studio. The only other places where GTKMM_API is used is in stock.h for the BuiltinStockID's. There will be no side effect here but I need to further test your patch with Visual Studio. As a side note, can you confirm that you have the same auto-import problem with Gtk::Menu ? Also, I'm targetting glibmm/gtkmm 2.8 and 2.10. Any reason why you prefer 2.6.x ?
I am slightly worried that we still don't know _why_ autoimport doesn't work for TreeViewColumn, but I guess we are dealing with MS.
(In reply to comment #42) > The main reason why we should use GTKMM_API for TreeViewColumn is consistency > with Visual Studio. There will be no side effect here but I need to > further test your patch with Visual Studio. Fair enough. > > As a side note, can you confirm that you have the same auto-import problem with > Gtk::Menu ? Yes, at least with the 2.0 API (version 2.2.12) - I got exactly the same behaviour for the menu MenuList class, there. I haven't actually reproduced the problem with version 2.6, but I haven't really tried, either - and the declaration does not seem to have changed. > > Also, I'm targetting glibmm/gtkmm 2.8 and 2.10. Any reason why you prefer 2.6.x ? Probably not. I started testing with 2.6.x mainly because someone else had built part of our code base with that version already. Also, we have to remain compatible with gtk version 2.6 on other platforms, but I suppose the API is quite stable anyway, and maybe I can also use a newer gtkmm with a somewhat older gtk?
Changes were committed to CVS (2.8 and head branches for glibmm and gtkmm) and include : 1. enable GLIBMM_API and GTKMM_API with mingw32/cygwin. The choice between dllexport and dllimport is done through the GLIBMM_BUILD and GTKMM_BUILD macros that are not defined at build time for glibmm and gtkmm respectively. 2. Tag some glibmm base classes (Object and ObjectBase) with GLIBMM_API to get rid of compiler warnings in Visual Studio/C++ Express 2005 3. Same thing with Gtk::Object in gtkmm. 4. Tag TreeViewColumn with GTKMM_API and inline the pack_start, pack_end and one of the constructors, as recommended by Toralf. 5. Updated Visual Studio projects file to VS/VC++ Express 2005. Everything now builds and runs fine without using the infamous '-Wl,--enable-runtime-pseudo-reloc' option at link time. I did not change anything to MenuList though, as I could not come up with an example that fails because of an auto-import error at build time.
Toralf, can you confirm that this works? Tell us if you need a tarball snapshot to do that. I'm eager to release a version with this fixed. Many thanks for the hard/clever work, Cedric.
I have released new versions of glibmm 2.8, glibmm 2.10, and gtkmm 2.8. Please reopen this bug if they do not fix the problem.