I have a c based plugin that I originally wrote for Sketchup 2019, and have updated each year to support 2020, 2021, 2022 and 2023.
I have attempted to update it to 2024, but struggling.
I am using the new 2024 SDK, and Ruby 3.2.2 (as copied from SDK folder samples\common\ThirdParty\ruby), and building in Visual Studio 2019.
The plugin folder structure is identical to what have use in the past.
Still when I try to call a function in my 2024 .so file, I get
Error: #<LoadError: 127: The specified procedure could not be found. - C:/Users/mgraham/AppData/Roaming/SketchUp/SketchUp 2024/SketchUp/Plugins/su_myPlugin/bin64/myOmniPlugin.so>
C:/Users/mgraham/AppData/Roaming/SketchUp/SketchUp 2024/SketchUp/Plugins/su_myOmniPlugin/loader.rb:34:in `require_relative'
C:/Users/mgraham/AppData/Roaming/SketchUp/SketchUp 2024/SketchUp/Plugins/su_myPlugin/loader.rb:34:in `execute'
C:/Users/mgraham/AppData/Roaming/SketchUp/SketchUp 2024/SketchUp/Plugins/su_myPlugin/loader.rb:161:in `block in <module:mycode>'
The identical source code built with 2023 SDK and Ruby 2.7.0 works correctly in Sketchup 2023.
Tip: check that you are not using something deprecated in your Ruby code that was removed in R3.2+ In my case I used File.exists? which was removed in R3.2 so I also had a similar issue.
The [ current 2024 ] C API library for Windows is built using Microsoft Visual Studio 2022 (v143).
ā¦ and ā¦
SketchUp 2020, 2021, 2022, and 2023.0 for Windows were built using Visual Studio 2019, and so plugins [ for these versions ] should be built with the Platform Toolset set to Visual Studio 2019 (v142).
ā¦ further ā¦
Using a different Platform Toolset will likely cause the plugin to fail to load and cause SketchUp to crash.
So, this implies you should be compiling to the VS v143 Toolset for SketchUp 2024 C extensions.
Also ā¦
Between Ruby 2.7 and Ruby 3.2, the name of the DLL produced by the Windows Ruby installer
changed to: x64-ucrt-ruby320.dll.
ā¦
While we [ Trimble SketchUp ] canāt officially support binaries built against anything other than the headers/libs we provide, we changed our DLL name to match.
Updated to vs2022 and toolset v143. Rebuilt and tested with both my 2023 and 2024 version of my plugin. The 2023 version works, the 2024 version is still giving me the same error as above.
I donāt recall seeing that error previously. I made some PRās/commits that updated c source to work in Ruby 3.x for a couple of popular extension gems, but that error wasnāt mentioned. Theyāre from several years ago (2020?), so Iām a bit foggy as to the reasons. Also, Iāve never compiled code for use with SketchUp.
Iām surprised you arenāt seeing any errors when you compile the file. Feel free to PM me if you want another set of eyes on your code. Iām more a Ruby coder than a C coderā¦
This issue is about your c source. I wasnāt referring to Ruby code.
The error text your showed above implies that your *.so file isnāt loading (LoadError on require_relative). Obviously, calls to it wonāt work if itās not loading.
myLoader.rb (1.3 KB)
I have attached my ruby file. I have comment out the lines that do not work.
My toolbar appears
If line 7 is commented out, when I click each of the buttons, it shows the message in the ruby console.
As soon as I uncomment line 7, I get the require_relative error
This Ruby file does not show the problem. It is on the C-side.
And since it works for 2023 and Ruby 2.7 and not 2024 and Ruby 3.2 the issue is with versioning.
Are you sure that the version of Ruby being used for the 2024 edition is Ruby 3.2.2 ?
Generally, you cannot load the same compiled so into SU versions using Ruby 2.7 and Ruby 3.2.
You need to compile two editions and use a conditional expression in Ruby to load the correct one for what SU version the user is running.
case RUBY_VERSION.to_f
when 2.7
require_relative 'bin64/2.7/myPlugin.so'
when 3.2
require_relative 'bin64/3.2/myPlugin.so'
end
Yes we have additional dlls. The odd thing is that we create the same set of support dlls for both our 2024 and 2023 installs, and the 2023 works but 2024 does not
To set the paths to load our extra dlls, we have been doing the following in myLoader.rb (I left this part out of the file I sent previously). This has worked for all past versions of our plugin
#Get the environment path
orgPath = ENV['Path']
#Get the support path to add, based on Sketchup version
skPath = ENV['APPDATA'] + "\\SketchUp\\"
skVersion = ""
if (2300000000...2399999999) === Sketchup.version_number
skVersion += "SketchUp 2023"
end
if (2400000000...2499999999) === Sketchup.version_number
skVersion += "SketchUp 2024"
end
skPath += skVersion + "\\SketchUp\\Plugins\\su_myPlugin\\libsupport;"
#Add the support path to the beginning of the environment path list (in session only)
ENV['Path'] = skPath + orgPath
Also, if the file being evaluated is already within your extension subfolder, you can simply use the global __dir__ method, ie:
libPath = File.join(__dir__, 'libsupport')
NOTE: This is likely safer than assuming the plugin will be in the %AppData% āPluginsā path.
Some users move extensions into the %ProgramData% āPluginsā folder OR into some folder on another drive entirely (and use a load shim file in āPluginsā or an extension like Fredoās AdditionalPluginsPath extension to point SketchUp to some alternate user āPluginsā directory.)
We have an installer that builds the all the folder paths for the plugin. I have add a āputsā statement to my loader.rb to show what the paths are, and they are correct. My current theory is there is a support file unique to 2024 that is not being copied.