Hi there,
It's been a little while and I though I would come check how this is going.
Surprisingly everything compiles out of the box, but the linking is where it seems to get into trouble with some versions of MinGW, using various tools etc. It would probably work if I didn't try to build shared libraries but given the significant filesizes involved It's really hard to justify the multiple-megabyte exectuables and modules that would get generated. Here are a few things probably at least worth mentioning:
Linking a monolithic libIfcParse.dll dies with "export ordinal too large".. Basically it means that the dll is trying to export more than 65000 symbols in a single table I think. Looking at the debian packages I see that there was an attempt at a non-monolithic which subdivided 2x3 from 4 but mutual dependencies between the various ifcGeom dlls made it unbuildable.
Also it might be worth mentioning about how you do your symbol exports, for example the _dllexport attribute on template instances on-the-fly in some releases, sorry I don't have that file anymore but essentially the issue was with clang++ ignoring the export attribute when you do something like this:
IFC_GEOM_API class ...<..>
And symbols were missing anyway from the dlls when I finally did massage it to build. Again, for some reason in these cases I have better luck when packages use -Wl,--export-all-symbols *.obj as opposed to -Wl,--whole-archive *.a but in the case of latest 0.6.0 or 0.7.0 it does not resolve the issue completely, with about a dozen symbols still missing from ifcGeom::Kernel as well as one or two from IfcParser..
Anyway these are very specific linking issues limited to very niche tools. I don't know if the feedback is useful in any way but I figured it would be better to give it than not.
Hi there,
It's been a little while and I though I would come check how this is going.
Surprisingly everything compiles out of the box, but the linking is where it seems to get into trouble with some versions of MinGW, using various tools etc. It would probably work if I didn't try to build shared libraries but given the significant filesizes involved It's really hard to justify the multiple-megabyte exectuables and modules that would get generated. Here are a few things probably at least worth mentioning:
Linking a monolithic libIfcParse.dll dies with "export ordinal too large".. Basically it means that the dll is trying to export more than 65000 symbols in a single table I think. Looking at the debian packages I see that there was an attempt at a non-monolithic which subdivided 2x3 from 4 but mutual dependencies between the various ifcGeom dlls made it unbuildable.
Also it might be worth mentioning about how you do your symbol exports, for example the _dllexport attribute on template instances on-the-fly in some releases, sorry I don't have that file anymore but essentially the issue was with clang++ ignoring the export attribute when you do something like this:
IFC_GEOM_API class ...<..>
And symbols were missing anyway from the dlls when I finally did massage it to build. Again, for some reason in these cases I have better luck when packages use -Wl,--export-all-symbols *.obj as opposed to -Wl,--whole-archive *.a but in the case of latest 0.6.0 or 0.7.0 it does not resolve the issue completely, with about a dozen symbols still missing from ifcGeom::Kernel as well as one or two from IfcParser..
Anyway these are very specific linking issues limited to very niche tools. I don't know if the feedback is useful in any way but I figured it would be better to give it than not.