GNOME Bugzilla – Bug 338844
glom build error on Cygwin
Last modified: 2006-12-27 15:14:23 UTC
Trying to build glom-1.0.0 on Cygwin with gcc-3.4.4: glom-1.0.0/glom/data_structure/glomconversions.cc: In function `Glib::ustring GlomConversions::get_text_for_gda_value(Field::glom_field_type, const Gnome::Gda::Value&, const std::locale&, const NumericFormat&, bool)': glom-1.0.0/glom/data_structure/glomconversions.cc:172: error: too many initializers for `tm' glom-1.0.0/glom/data_structure/glomconversions.cc:189: error: too many initializers for `tm' glom-1.0.0/glom/data_structure/glomconversions.cc: In function `tm GlomConversions::parse_date(const Glib::ustring&, const std::locale&, bool&)': glom-1.0.0/glom/data_structure/glomconversions.cc:418: error: too many initializers for `tm' glom-1.0.0/glom/data_structure/glomconversions.cc:466: error: too many initializers for `tm' glom-1.0.0/glom/data_structure/glomconversions.cc:483: error: too many initializers for `tm' glom-1.0.0/glom/data_structure/glomconversions.cc: In function `tm GlomConversions::parse_time(const Glib::ustring&, const std::locale&, bool&)': glom-1.0.0/glom/data_structure/glomconversions.cc:541: error: too many initializers for `tm' glom-1.0.0/glom/data_structure/glomconversions.cc:569: error: too many initializers for `tm' make[1]: *** [glomconversions.o] Error 1
I guess we should use memset() instead. Could you provide a patch for that? I am impressed and glad that you got this far on Windows.
I'm afraid that this is beyond my limited programming knowledge.
Created attachment 64143 [details] [review] cygwin_memset_fix.patch Does this patch fix it?
The patch fixes the compilation error with 1.0.2, and I get as far as linking. Now I see that this is going to be a little more difficult than I had hoped. On PLATFORM_WIN32, shared libraries and modules must have all symbols resolved at *link* time. This requires '-no-undefined' in LDFLAGS and all required link libs in LIBADD. 1) python_embed/python_module/glom.la is dependent on some symbols in the glom executable. This could be solved in one of two ways, either of which I can handle. 2) The glom executable depends on symbols in the python module; namely, python_embed/glom_python.cc depends on PyGlomRecord. This will NOT work, since a) PLATFORM_WIN32 doesn't recognize rpaths (and there is NO workaround for this), and b) you can't use -export-symbols-regex initglom and depend on a symbol besides initglom. I could only suggest changing python_embed/glom_python.cc to not directly reference PyGlomRecord, so that it need not link against python_embed/python_module/glom.la. If you can somehow take care of that, I should be able to handle the rest.
I have applied the memset patch.
Could you give me a patch for the build, so that I can try this on Linux?
Would it help to move some stuff into a libglom, that both glom and the glom python module could use?
> Would it help to move some stuff into a libglom, that both glom and the glom > python module could use? Yes, absolutely.
Maybe this works for you: http://www.murrayc.com/misc/glom-1.0.2testwithlibglom.tar.gz Please test. The libglom would be useful for other things anyway. I really would like a build patch that allowed me to experience the problem on Linux.
Sorry, libglom can't link: .libs/connectionpool.o:connectionpool.cc:(.text+0x2646): undefined reference to `FieldTypes::FieldTypes(Glib::RefPtr<Gnome::Gda::Connection> const&)' .libs/utils.o:utils.cc:(.text+0xc35): undefined reference to `Glom_PQunescapeBytea(unsigned char const*, unsigned int*)' .libs/utils.o:utils.cc:(.text+0x1515): undefined reference to `UsesRelationship::get_has_relationship_name() const' .libs/utils.o:utils.cc:(.text+0x157a): undefined reference to `UsesRelationship::get_relationship_name() const' .libs/utils.o:utils.cc:(.text+0x159d): undefined reference to `UsesRelationship::get_related_relationship_name() const' .libs/utils.o:utils.cc:(.text+0x1646): undefined reference to `UsesRelationship::get_relationship_name() const' .libs/utils.o:utils.cc:(.text+0x17c7): undefined reference to `UsesRelationship::UsesRelationship()' .libs/utils.o:utils.cc:(.text+0x180d): undefined reference to `UsesRelationship::get_relationship() const' .libs/utils.o:utils.cc:(.text+0x1833): undefined reference to `UsesRelationship::set_relationship(sharedptr<Relationship> const&)' .libs/utils.o:utils.cc:(.text+0x1864): undefined reference to `UsesRelationship::get_related_relationship() const' .libs/utils.o:utils.cc:(.text+0x188a): undefined reference to `UsesRelationship::set_related_relationship(sharedptr<Relationship> const&)' .libs/utils.o:utils.cc:(.text+0x1ed3): undefined reference to `UsesRelationship::get_has_relationship_name() const' .libs/utils.o:utils.cc:(.text+0x1f45): undefined reference to `UsesRelationship::get_relationship_name() const' .libs/utils.o:utils.cc:(.text+0x1f6b): undefined reference to `UsesRelationship::get_related_relationship_name() const' .libs/utils.o:utils.cc:(.text+0x2010): undefined reference to `UsesRelationship::get_relationship_name() const' .libs/utils.o:utils.cc:(.text+0x21e7): undefined reference to `LayoutItem_FieldSummary::get_summary_type_sql() const' .libs/utils.o:utils.cc:(.text+0x22b1): undefined reference to `UsesRelationship::get_sql_table_or_join_alias_name(Glib::ustring const&) const' .libs/utils.o:utils.cc:(.text+0x2569): undefined reference to `UsesRelationship::get_related_relationship_name() const' .libs/utils.o:utils.cc:(.text+0x270d): undefined reference to `UsesRelationship::UsesRelationship()' .libs/utils.o:utils.cc:(.text+0x2756): undefined reference to `UsesRelationship::get_relationship() const' .libs/utils.o:utils.cc:(.text+0x277c): undefined reference to `UsesRelationship::set_relationship(sharedptr<Relationship> const&)' .libs/utils.o:utils.cc:(.text+0x27b0): undefined reference to `UsesRelationship::get_related_relationship() const' .libs/utils.o:utils.cc:(.text+0x27d6): undefined reference to `UsesRelationship::set_related_relationship(sharedptr<Relationship> const&)' .libs/utils.o:utils.cc:(.text+0x2d74): undefined reference to `UsesRelationship::get_relationship() const' .libs/utils.o:utils.cc:(.text+0x2dda): undefined reference to `Relationship::get_has_fields() const' .libs/utils.o:utils.cc:(.text+0x2df7): undefined reference to `UsesRelationship::get_sql_join_alias_definition() const' .libs/utils.o:utils.cc:(.text+0x30a1): undefined reference to `UsesRelationship::get_sql_table_or_join_alias_name(Glib::ustring const&) const' .libs/utils.o:utils.cc:(.text+0x34e4): undefined reference to `Relationship::get_has_to_table() const' .libs/utils.o:utils.cc:(.text+0x3538): undefined reference to `Relationship::get_to_table() const' .libs/utils.o:utils.cc:(.text+0x35c0): undefined reference to `UsesRelationship::get_related_relationship_name() const' .libs/utils.o:utils.cc:(.text+0x392a): undefined reference to `GlomConversions::value_is_empty(Gnome::Gda::Value const&)' .libs/utils.o:utils.cc:(.text+0x3a70): undefined reference to `Field::sql(Gnome::Gda::Value const&) const' .libs/utils.o:utils.cc:(.text+0x3dd9): undefined reference to `LayoutItem_Field::get_formatting_used() const' .libs/utils.o:utils.cc:(.text+0x3df6): undefined reference to `FieldFormatting::get_choices(sharedptr<Relationship>&, Glib::ustring&, Glib::ustring&) const' .libs/utils.o:utils.cc:(.text+0x42db): undefined reference to `Relationship::get_to_table() const' .libs/utils.o:utils.cc:(.text+0x4719): undefined reference to `Relationship::get_to_table() const'
Could attach the complete build log, please? Are you using configure.in or doing a full autogen.sh? glom/libglom/Makefile.am does specify the libglom_datastructure.la sub-library, which should define FieldTypes::FieldTypes, etc, so I'm confused.
Never mind, 1.0.3 builds with minor patches, but it segfaults upon launch. Looks like a temporary problem with Cygwin, or my build was botched due to a reset in the middle. I'll build again with debug and keep you posted.
Could you upload the patch(es), please?
Created attachment 64832 [details] [review] glom-1.0.3 Cygwin build patch
I have applied most of that patch, apart from the --no-undefined part. I guess I shouldn't use that on Linux. Please update the patch when you start using the latest stuff from cvs or the new tarball. Can you post the backtrace for the crash, please? Or a valgrind memcheck log?
> I have applied most of that patch, apart from the --no-undefined part. I guess > I shouldn't use that on Linux. If you don't put '-no-undefined', then shared libraries won't build on Cygwin. As long as you always specify all necessary link libraries in LIBADD (which it must to build on Cygwin anyway), then it's fine on Linux too. Note that several GNOME libraries have unconditionally used -no-undefined for a few years already.
> Can you post the backtrace for the crash, please? Or a valgrind memcheck log? Pretty sure it's a bug in the Cygwin snapshot; I'll have to swap it for the latest stable to be sure.
Have you made any progress on this? I'd like to fix any problems that remain. By the way, is this a build against X11 on Windows, or against the GTK+ Windows port?
> Have you made any progress on this? I'd like to fix any problems that remain. No, it still SIGSEGVs on me; there have been numerous changes in the cygwin pthread handling as of late which have solved many problems so far, so I've been waiting to see further changes will help. > By the way, is this a build against X11 on Windows, or against the GTK+ Windows > port? This is a build against X11 on Cygwin.
Could you post a backtrace, please?
0x610b2866 in pthread_key_create () from /usr/bin/cygwin1.dll (gdb) bt
+ Trace 68963
Then it dumps stack and crashes.
Have you made any progress on this? Are all the necessary changes in glom's cvs now?
Could you please check that I have all the changes in cvs?
I get the following error compiling 1.2.0: glom/libglom/utils.cc:194: error: multiple storage classes in declaration of 'type_list_relationships'
You should be able to fix that just by removing the "static" from the start of that line.
By the way, that fix is in released tarballs now.
I got glom-1.2.1 to build with the fix in comment 25 and the two '-no-undefined' additions, but glom just crashes on startup and gdb with a debug build isn't helping. How do I proceed now?
> I got glom-1.2.1 to build with the fix in comment 25 That is in a tarball now, I believe. > and the two > '-no-undefined' additions Please provide a patch against cvs so that I can commit this. > How do I proceed now? If your gdb isn't working, you should at least be able to add some print()s to the code to discover roughly where it is crashing. Thanks.
Created attachment 78871 [details] [review] glom-1.2.2 -no-undefined patch It's working now; it was Cygwin being temperamental again. Here's the -no-undefined patch for 1.2.2.
Thanks. Applied. I look forward to the results of your testing.