Update stepcode to latest

[mumbricht]

This should fix everything. The last problem I fixed was the package names, which changed in the latest versions. Build tests work.

[ramcdona]

I will try to find some time to look at this.

Can you confirm that the result is a statically linked build?

On Linux:

ldd vsp

On MacOS:

otool -L vsp

On Windows:

dumpbin /dependents vsp.exe

These programs will list any/all dynamic dependencies of the vsp executable. It should list only system libraries. For example, 3.49.0 on MacOS this gives:

./vsp:
	/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 24.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1345.120.2)
	/System/Library/Frameworks/UniformTypeIdentifiers.framework/Versions/A/UniformTypeIdentifiers (compatibility version 1.0.0, current version 709.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1700.255.5)
	/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 2487.60.105)
	/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 64.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 2503.1.0)
	/System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics (compatibility version 64.0.0, current version 1774.5.3)
	/System/Library/Frameworks/CoreText.framework/Versions/A/CoreText (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 2503.1.0)
	/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)

[mumbricht]

Here is the output of the .deb from the github build actions:

ldd vsp
        linux-vdso.so.1 (0x00007ff48ea69000)
        libGLEW.so.2.2 => /lib64/libGLEW.so.2.2 (0x00007ff48c540000)
        libxml2.so.2 => /lib64/libxml2.so.2 (0x00007ff48c3e2000)
        libcminpack.so.1 => /lib64/libcminpack.so.1 (0x00007ff48ea29000)
        libX11.so.6 => /lib64/libX11.so.6 (0x00007ff48c29d000)
        libGLU.so.1 => /lib64/libGLU.so.1 (0x00007ff48c243000)
        libGL.so.1 => /lib64/libGL.so.1 (0x00007ff48c1d0000)
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007ff48be00000)
        libm.so.6 => /lib64/libm.so.6 (0x00007ff48c0db000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007ff48e9fb000)
        libc.so.6 => /lib64/libc.so.6 (0x00007ff48bc0d000)
        /lib64/ld-linux-x86-64.so.2 (0x00007ff48ea6b000)
        libz.so.1 => /lib64/libz.so.1 (0x00007ff48c0b3000)
        liblzma.so.5 => /lib64/liblzma.so.5 (0x00007ff48c07e000)
        libflexiblas.so.3 => /lib64/libflexiblas.so.3 (0x00007ff48b600000)
        libxcb.so.1 => /lib64/libxcb.so.1 (0x00007ff48b5d6000)
        libOpenGL.so.0 => /lib64/libOpenGL.so.0 (0x00007ff48b5b2000)
        libGLX.so.0 => /lib64/libGLX.so.0 (0x00007ff48b581000)
        libXext.so.6 => /lib64/libXext.so.6 (0x00007ff48e9e3000)
        libGLdispatch.so.0 => /lib64/libGLdispatch.so.0 (0x00007ff48b509000)
        libgfortran.so.5 => /lib64/libgfortran.so.5 (0x00007ff48b000000)
        libquadmath.so.0 => /lib64/libquadmath.so.0 (0x00007ff48b4c2000)
        libXau.so.6 => /lib64/libXau.so.6 (0x00007ff48e9de000)

I don't have access to a windows machine to test the windows build. Since the build scripts diverge for WIN32, that's where things might change. That said, I have no reason to believe the changes would result in shared libraries for any of the bundled dependencies, particularly for stepcode.

[ramcdona]

When I was working with this, the primary difficulty I had was getting it to work with static libraries. The person who has been developing StepCode lately has not been testing the static library path, so there seemed to be several things broken about it. It is exactly where I expect things to go wrong.

[mumbricht]

The Cmake flags are set to static libs, both with the default CMAKE flag and the stepcode specific CMAKE flag:

        -DBUILD_STATIC_LIBS=ON
        -DSC_BUILD_STATIC_LIBS=ON

I don't have a full CI pipeline to check to make sure that everything is being done correctly, so I'm relying on your build action, the fedpkg sandbox, and the self-test frameworks where applicable.

I've built the STEPCode package so that it will be available as a Fedora package, and it does fail on aarch64.

In the bundled case, would it throw an error if it builds a shared lib?

[ramcdona]

In my experience, no.

The problem I had may have been related to trying to force shared libs to OFF.

For example, STEPCode builds the schema parser during the build process. It needs its own libraries to do that. When building with shared libs off, the schema parser may have failed to build.

The next problem is when you search for the libraries to build VSP. If it finds the shared libraries instead of the static ones, it may use that.

Letting it build the shared libraries may be a good solution -- let the STEPCode build and schema generation work as expected. Then we just have to make sure it has and finds the static libs when it builds VSP.