Thanks Tom that’s great news, I’ll change the project in Github to utilise that. That should sort out all the issues when building on different platforms too. Much much much appreciated!
So I have more or less successfully build an .so library project. I’m a bit confused actually.
I have 100% opened up a new Dynamic Library project. I then add the neccessary header search paths, compiler flags and linker flags necessary to build the project.
Extra compiler flags:
-fPIC
Extra linker flags:
-shared -lpython2.7 -lboost_python
C++ standard to use:
C++11
Header search paths:
/usr/include/python2.7
Binary name:
renderman
This project now compiles great on Linux, but the binary created is prefixed with lib (which is okay) and suffixed with .a (not okay.) I thought the -shared linker flag created a .so file. If I change the binary name to renderman.so, the created binary is actually librenderman.so.a
Ultimately the code seems to work in Python if I change the binary from whatever Projucer called it to renderman.so. It would be great not to have to rename it if possible though!
Are you using the latest version of JUCE on the develop branch? We’ve made a lot of changes to the exporters recently, so this could either be something we’ve missed, or, hopefully, something we’ve already fixed.
No I’m a bit behind as I was using a fork that allows for Projucer to build QtCreator projects (it would be great to have official support for this - I’ve yet to see a better IDE for Linux. I also know you guys have priorities too!)
I’ll see how it goes with the latest dev branch and report back! Again, many thanks 
Using the Develop branch doesn’t seem to fix the problem, the binary is still being both prefixed with ‘lib’ and suffixed with ‘.a’ no matter what I put…
The ‘lib’ prefix is because that’s the convention for both static and dynamic libraries on Linux (and MacOS). Many build tools will fail to find your library if it isn’t named like that.
The ‘.a’ suffix was a JUCE bug - I’ve just pushed a fix to the develop branch.
Thank you Tom, that fixed the Linux side of things. Really appreciate the prompt responses and good explanations.
I now have a similar problem with MacOS, that is when I build a XCode project with the binary name as ‘librenderman.so’, the actual binary is suffixed with a ‘.dylib’ and so is called ‘librenderman.so.dylib’.
Python only allows me to import modules from .so files so would it be possible to get the MacOS binary suffix producer functionality working please?
Many thanks
It’s working as expected; .dylib is the standard extension on MacOS (even if Python requires something different).
Does it work if you just rename the library librenderman.dylib -> librenderman.so?
Yeah renaming the file works fine, it’s just if you add a suffix to the binary name in the Projucer, the Projucer implies that it will be the file type as it says “If you don’t add a suffix to this name, a suitable platform-specific suffix will be added automatically”. Honestly no problem though, I’ll write a little script that modifies the name.
The Projucer tooltip is prefixed by “The filename to use for the destination binary executable file”. It’s quite common to use a custom suffix for executables on MacOS and Linux, but it’s very rare for non-executables like libraries. This could certainly be clearer though.