Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resolved several MSVC compiling errors #87

Merged
merged 7 commits into from
Jul 18, 2019

Conversation

cntaylor
Copy link
Contributor

@cntaylor cntaylor commented Jul 13, 2019

  • The check.base unit tests all pass now.
  • The gstam_matlab_wrapper class compiles with now errors now.
  • Note that I had to remove all LieMatrix, LieVector, and LieScalar stuff
    to get this to work...

This change is Reviewable

* The check.base unit tests all pass now.
* The gstam_matlab_wrapper class compiles with now errors now.
* Note that I had to remove all LieMatrix, LieVector, and LieScalar stuff
to get this to work...
@cntaylor
Copy link
Contributor Author

Several of the "check." libraries seem to have multiple defined test functions. However, I was able to --using this branch and commit -- compile gtsam_toolbox and the examples seem to run in MATLAB, so I think it is all compiling properly. This happens despite the check.geometry and check.inference projects, for example, not compiling properly. Happy that I have been able to compile a MATLAB toolbox from source though. Now to add my own factors... :)

Copy link
Member

@dellaert dellaert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your fix. However, it's a really heavy-handed fix. Basically, you're saying: this feature does not work on Windows, we'll just remove it. However, while LieXXX are deprecated in GTSAM 4, it was consciously not removed to allow any project that was still referring to these classes to still work. This is also why the tests are still there. This is a great PR for GTSAM 5, where we will simply remove it, but not for GTSAM 4.

To fix the linking error, how about adding dummy *.cpp files instead? It's a bit weird to me though, because I believe there are other header-only classes. So I'm not 100% sure I believe your reasoning that it is the lack of cpp files that is causing the issue.

@cntaylor
Copy link
Contributor Author

It didn't seem like the optimal fix. However, all of the errors are of the type that "you have declared a function, but there is no definition for it", very similar to what would happen if you have the .h files but not the .cpp files in a normal circumstance. (Honestly, I was wondering if someone had removed the .cpp files when they deprecated, but not fully removed the requirement for that code from all sections of the repository.) Are the .h files supposed to be the full implementation of the Lie* classes?

@dellaert
Copy link
Member

You can answer that question :-) Just check which methods VS complains about have no body in the .h file?

@dellaert
Copy link
Member

BTW: the fact it compiles and links on mac/linux makes me think: none...

@cntaylor
Copy link
Contributor Author

cntaylor commented Jul 13, 2019 via email

@cntaylor
Copy link
Contributor Author

Well, I think I finally understand how this dllexport and dllimport stuff works with MSVC. Made the fix rather simple, actually. Take a look at this one and see what you think...

Copy link
Member

@dellaert dellaert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, this is getting closer :-) One thing I still don't understand is why the switch from class-level EXPORT to method-level EXPORT for PointX.h. And, why no EXPORT for Lie classes? Since you say you figured it out, I propose you add a (short) comment in all those classes as to why it is so.
Finally, please note there is a compile-time switch to typedef Point2 and Point3 to Eigen vectors. Would it be too much trouble (I know windows has a very slow compile!) to check whether everything still works under that flag?

@dellaert dellaert requested a review from jlblancoc July 15, 2019 16:13
Copy link
Member

@dellaert dellaert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome! Since you're merging into José's PR, I propose he merges when he validates this builds on his machine. @jlblancoc OK?

@jlblancoc
Copy link
Member

Sure, @dellaert !

Using-GTSAM-EXPORT.md Show resolved Hide resolved
Using-GTSAM-EXPORT.md Outdated Show resolved Hide resolved
@@ -0,0 +1,41 @@
# Using GTSAM_EXPORT

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wow, this doc is like a large Blog entry on the topic... good idea, @dellaert , @cntaylor ! 👍

@@ -0,0 +1,41 @@
# Using GTSAM_EXPORT

To create a DLL in windows, the `GTSAM_EXPORT` keyword has been created and needs to be applied to different methods and classes in the code to expose this code outside of the DLL. However, there are several intricacies that make this more difficult than it sounds. In general, if you follow the following three rules, GTSAM_EXPORT should work properly. The rest of the document also describes (1) the common error message encountered when you are not following these rules and (2) the reasoning behind these usage rules.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the GTSAM_EXPORT keyword has been created

Should it be clearer mentioning that it is CMake the one who automatically defines this symbol (as far as I know) when building dynamic libs?

Using-GTSAM-EXPORT.md Outdated Show resolved Hide resolved
Using-GTSAM-EXPORT.md Outdated Show resolved Hide resolved

Rule #1 doesn't seem very bad, until you combine it with rule #2

***Compiler Rule #2*** Anything defined in a header file is not included in a DLL.
Copy link
Member

@jlblancoc jlblancoc Jul 15, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Anything defined in a header file is not included in a DLL.

I'm not 100% sure of this... it is NOT exported if you mark it explicitly with inline. Otherwise, I'm not sure if there is a well-defined, standardized expected behavior (?).
(Edit: I mean, if one has:

class GTSAM_EXPORT Foo
{
public: 
 void doit(int &a) { a++; }
};

would doit() be exported? I think it will...
).

I'll kindly request the knowledge of @jolting here just in case he can help us to be accurate in the description...
@jolting

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please note that my expertise on DLLimport/export is what I have learned playing with GTSAM for the last week or so getting it to compile and looking up things online. So, I am theorizing to the best of my knowledge, but I certainly am not an expert.

That said, I have seen several website mention that if you declare a function in a header inside a class definition, the compiler automatically makes it an "inline" function. If it was not inline and you included this class definition in more than one file, then you would get a "multiple definitions of the function 'doit'" error. So this one is essentially marked inline and will not be put in the DLL.

Once again, I should probably change "define" to declare. My im-precision may be causing confusion. :(

I guess it may be possible that a non-inline function is declared in a header file and included in the DLL, but that seems like a corner case (due to the "multiple instances" compilation problem inherent with non-inline functions) so I don't think we need to worry about that too much.

Using-GTSAM-EXPORT.md Outdated Show resolved Hide resolved
Using-GTSAM-EXPORT.md Outdated Show resolved Hide resolved
@jlblancoc
Copy link
Member

I verified it builds, thanks @cntaylor ! I'll merge, please open a new PR if you want to add new fixes 👍

@jlblancoc jlblancoc merged commit 9f9cff4 into borglab:msvc-fixes Jul 18, 2019
@jlblancoc
Copy link
Member

@cntaylor I noticed that there is an inconsistent usage of export macros between GTSAM and GTSAM_UNSTABLE. I'll fix it in the branch msvc_fixes. Please, update your local copy of that branch if you also keep working on that...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants