code-google-com / bullet

Automatically exported from code.google.com/p/bullet
0 stars 0 forks source link

cmake -DBUILD_SHARED_LIBS=ON has link errors and -DFRAMEWORK=ON doesn't work either #357

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago

See http://bulletphysics.org/Bullet/phpBB3/viewtopic.php?f=9&t=4681

Original issue reported on code.google.com by erwin.coumans on 6 Mar 2010 at 1:09

GoogleCodeExporter commented 9 years ago
First attempt to fix build for shared libraries, frameworks
http://code.google.com/p/bullet/source/detail?r=2054

Still, we need some test

Original comment by erwin.coumans on 6 Mar 2010 at 5:08

GoogleCodeExporter commented 9 years ago

Original comment by erwin.coumans on 6 Mar 2010 at 7:40

GoogleCodeExporter commented 9 years ago
Just for reference, including a patch summarizing changes discussed in the 
thread.

Original comment by ejtt...@gmail.com on 1 Jul 2010 at 1:33

Attachments:

GoogleCodeExporter commented 9 years ago
Updating patch to include fixes for building Extras (this is in order to be 
able to share a link to the patch file so our devs/users can build 2.76 for OS 
X frameworks easily until 2.77 comes out... if google code changes that 'token' 
parameter on the attachment URL I might have to find some other way to host the 
patch file, that would be annoying...)

Original comment by ejtt...@gmail.com on 1 Jul 2010 at 2:28

Attachments:

GoogleCodeExporter commented 9 years ago

Can you please create the patch again using the latest trunk?

There are some conflicts with fixes that were applied back in March, see for 
example
http://bit.ly/bjdihp

Also, please create the patch from within the Bullet top directory (not using 
additional parent directories such as bullet-2.76-patched)

Thanks a lot,
Erwin

Original comment by erwin.coumans on 3 Jul 2010 at 10:22

GoogleCodeExporter commented 9 years ago
All of the items in that patch have already been resolved in the current trunk.
However, some new items are currently causing trouble in revision 2171, namely 
some spurious TARGET_LINK_LIBRARIES(BulletSoftBody ...) lines in 
non-BulletSoftBody CMakeLists.txt files (it complains because it wants the 
first argument to match the "current" target library, it doesn't know about 
BulletSoftBody in the current CMakeLists.txt context.

Then there is a secondary issue with linking against OpenCL.  I added a 
LINK_FLAGS property when building on Apple with shared libs (or frameworks) to 
bring in this dependency.  Maybe someone more familiar with CMake knows a more 
elegant way to do this.  I have a feeling Linux will need a -lOpenCL for shared 
libs there, which this doesn't address.

Original comment by ejtt...@gmail.com on 16 Aug 2010 at 10:21

Attachments:

GoogleCodeExporter commented 9 years ago

Thanks a lot for the patch, I'll have a look at it.

Linux shouldn't compile anything OpenCL related in Bullet, or does it?

Original comment by erwin.coumans on 16 Aug 2010 at 10:55

GoogleCodeExporter commented 9 years ago
By the way, BulletSoftBodySolvers_OpenCL_Mini (MiniCL) should not link against 
OpenCL.

MiniCL is a (partial) replacement for OpenCL, so I imagine the target link 
libraries include MiniCL.

Original comment by erwin.coumans on 19 Aug 2010 at 10:24

GoogleCodeExporter commented 9 years ago
Applied in latest trunk and 2.77 BETA

Thanks for the feedback!

Original comment by erwin.coumans on 20 Aug 2010 at 12:09