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

Link error 1189 library limit of 65535 objects exceeded #833

Closed
larshg opened this Issue Aug 4, 2014 · 15 comments

Comments

Projects
None yet
7 participants
@larshg
Contributor

larshg commented Aug 4, 2014

After the merge of #790 I'm unable to compile the pcl_features library, due to link error in topic.

I guess it has to be divided into multple dll's or is there some other way to do it? As far as I have found, its not possible.

linkerror1189

Any one else has this error?

@VictorLamoine

This comment has been minimized.

Contributor

VictorLamoine commented Aug 4, 2014

This error seems like a limit of Visual Studio. From what I have read it is not possible to bypass this limit so something else have to be done.

@taketwo

This comment has been minimized.

Member

taketwo commented Aug 12, 2014

Are you compiling with PCL_ONLY_CORE_POINT_TYPES off? Perhaps turning it on will reduce the number of objects, though I am not sure. (And of course this would only be a workaround.)

@larshg

This comment has been minimized.

Contributor

larshg commented Aug 13, 2014

Hi @taketwo , I was compiling with PCL_ONLY_CORE_POINT_TYPES off, but changing it to on made it possible to compile - probably due to fewer point types being declared.

@taketwo

This comment has been minimized.

Member

taketwo commented Aug 13, 2014

Okay, this means we have a temporary workaround.
Proper solutions are welcome, of course.

@taketwo

This comment has been minimized.

Member

taketwo commented Aug 25, 2014

Found #350 while browsing closed pull requests. Another indication that features module is just too huge.

@GeraldLodron

This comment has been minimized.

GeraldLodron commented Sep 10, 2014

Anything new to this? pcl features still does not compile without setting PCL_ONLY_CORE_POINT_TYPES

@jpapon

This comment has been minimized.

Contributor

jpapon commented Sep 10, 2014

I think the only other solution is to use a compiler that doesn't have the 65k objects limit.

@GeraldLodron

This comment has been minimized.

GeraldLodron commented Sep 10, 2014

That would mean that (full) pcl loses visual studio support... bad for 50% of all developers I think

in my case I cannot switch, it is a company guideline to use VS... I would also prefer another compiler...

@jpapon

This comment has been minimized.

Contributor

jpapon commented Sep 10, 2014

Is there a reason you need to compile all of the point types against all of the feature classes?

@jspricke

This comment has been minimized.

Member

jspricke commented Sep 10, 2014

Setting PCL_ONLY_CORE_POINT_TYPES would only mean that you have to compile some more template instantiations by yourself, if you need less common point types. So I would make it default for 1.8 on Windows. Feel free to send a pull request if you have a platform to test.

@GeraldLodron

This comment has been minimized.

GeraldLodron commented Sep 10, 2014

No there is no reason to compile all types, additionally to the core point types we use pcl::PointNormals, pcl::PointXYZ, pcl::PointXYZI, pcl::PointXYZRGB and pcl::PointXYZRGBI. When i compile pcl with core types i get linker errors when using those:
e.g.:

error LNK2001: unresolved external symbol "private: virtual void __cdecl pcl::NormalEstimationOMP<struct pcl::PointXYZ,struct pcl::PointNormal>::computeFeature(class pcl::PointCloud<struct pcl::PointNormal> &)" (?computeFeature@?$NormalEstimationOMP@UPointXYZ@pcl@@UPointNormal@2@@pcl@@EEAAXAEAV?$PointCloud@UPointNormal@pcl@@@2@@Z)

Is there a workaround to easily add some specified point types to the "Core"? Or can i tell the compiler to compile those additional point types in my own program/lib? If yes, how?

@jspricke: what you mean with "So I would make it default for 1.8 on Windows"? I do not really understand what you want to say....

@jpapon

This comment has been minimized.

Contributor

jpapon commented Sep 10, 2014

Yes, you can include the relevant .hpp file(s) in your source and the compiler will create the objects you use if they were not explicitly instantiated in the main library. There's a tutorial which discusses this here.

This has the downside of seriously increasing your compilation time if you use a few classes.

@GeraldLodron

This comment has been minimized.

GeraldLodron commented Sep 10, 2014

omg, that was the trick, so many thanks....

@jspricke

This comment has been minimized.

Member

jspricke commented Sep 10, 2014

I've proposed a pull request (#897) for the next version (1.8).

@Freddixx

This comment has been minimized.

Freddixx commented Sep 10, 2014

Best news today.

@jspricke jspricke closed this in e93dfe5 Sep 11, 2014

taketwo added a commit that referenced this issue Sep 11, 2014

Merge pull request #897 from jspricke/windows_PCL_ONLY_CORE_POINT_TYPES
Set PCL_ONLY_CORE_POINT_TYPES on Windows (Closes #833)

gcasey pushed a commit to gcasey/pcl that referenced this issue Sep 23, 2014

Casey Goodlett
Merge remote-tracking branch 'gh/master' into robust-mean-and-covaria…
…nce-estimate

* gh/master: (166 commits)
  Fixes for issue PointCloudLibrary#924
  Fix setSize () in PCL visualizer
  PCL formula is in the official homebrew repo
  CMake pkg_check_modules sets GLEW_INCLUDEDIR
  Fix for Mac OS X
  Changes necessary for lccp pull request PointCloudLibrary#718
  Change to visualization to make things a bit nicer - mainly removed broken opacity
  Updated supervoxel examples with normals and better description of the camera transform
  Removed public interface for modifying neighbors of OctreePointcloudAdjacencyContainer. Neighbors can now only be added/removed from within OctreePointcloudAdjacency. This does *not* mean neighbors can't be modified, just that the list of neighbors itself can't be modified.
  Fix for problem where leaves could get lost, and warning would show up. Now we use leaf indices directly for seeding, instead of doing a look up Changed OctreePointcloud Adjacency to use std::list instead of std::set, added comparator to SupervoxelHelper so that the internal set of voxels owned by a helper is sorted by index instead of memory location Added brief comment explaining comparator
  Fix inconsistency between method declaration and implementation that resulted in build failure
  Remove Boost Chrono dependency
  Don't normalize path if function is not in Boost
  Disable precompilation of PPFRegistration
  Fix for issue PointCloudLibrary#758
  Moved pcl::PPFHashMapSearch::setInputFeatureCloud() and pcl::PPFHashMapSearch::nearestNeighborSearch() implementation from ppf_registration.hpp to ppf_registration.cpp since they belong to a not templated class
  Bump PCL version to 1.8.0
  Fixes PointCloudLibrary#896.
  Add a changelist for 1.7.2
  Set PCL_ONLY_CORE_POINT_TYPES on Windows (Closes PointCloudLibrary#833)
  ...

Conflicts:
	common/include/pcl/common/impl/centroid.hpp
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment