Trying to build pytorch on ubuntu 24.04

[thinkpractice]

@pedronahum I've been trying to build pytorch on Ubuntu (for now without the dockerfile you provided). I do use your Dockerfile as inspiration. At the moment the build fails because it cannot find pthread_create which I find hard to believe because if I remember it correctly it's a POSIX function and should be present. I think it's a problem like the one discussed here.

Any ideas? Would also like to know how far you've come! Building your Dockerfile ATM!

[thinkpractice]

Getting an error while installing swiftly here. Change the command now to:

# Install Swift via Swiftly
RUN curl -O https://download.swift.org/swiftly/linux/swiftly-$(uname -m).tar.gz \
    && tar zxf swiftly-$(uname -m).tar.gz \
    &&./swiftly init --quiet-shell-followup \
    && . "${SWIFTLY_HOME_DIR:-/root/.local/share/swiftly}/env.sh" \
    && hash -r \
    && export PATH="/root/.swiftly/bin:$PATH" \
    && swiftly list-available

Looks like swiftly cannot be found. Will try to debug further.

[pedronahum]

Hi @thinkpractice,

The yml files and dockerfile are still work in progress. A few seconds ago I corrected the swiftly issue, so the latest commit addresses this, now I am testing the pytorch cloning/build. This is an adventure on its own. Paths are messy, particularly if building with clang and not gcc. Will let you when torch build is successful (hopefully this weekend).

[thinkpractice]

Ah thanks, yeah it's always an adventure when building things from source 😄 Good luck!

[pedronahum]

Hi @thinkpractice,

I am now able to compile pytorch from source in Ubuntu. Please have a look at https://github.com/pedronahum/TaylorTorch/blob/main/.github/workflows/ubuntu-ci.yml. Now I need to fix in Ubuntu the flags to compile TaylorTorch. One step a time :)

[thinkpractice]

@pedronahum nice work! I see you have removed the docker file? Will have a look at creating a script from your yml file so I can build pytorch locally.

[pedronahum]

Hi, Yes, I had to remove it as I was getting some out-of-memory errors and decided to focus on the ubuntu.ci.yml file. The yml file now compiles Pytorch and installs the relevant dependencies. Now I just need to fix some linker issues for TaylorTorch & DocC.

[pedronahum]

trying to add back the dockerfile now. Let me revert when is working.

[pedronahum]

Hi @thinkpractice: Dockerfile compiles now Pytorch from source. Yet I am still facing some link issues when building TaylorTorch in Ubuntu. Made many changes to make ci smoother, and to address several linux related issues.

[thinkpractice]

@pedronahum thanks! Didn't have much time these last weeks to help you with that but hopefully will have some more time soon :)

[pedronahum]

Hey @thinkpractice , amazing!!!! I just see you have made lots of progress!! Let me double check why the extension fails in Linux. I dont get this issue in my Mac. I will review this. Again, many many thanks for going through the rabbit hole. Have been trying to rebuild my ubuntu workstation :)

[thinkpractice]

@pedronahum you're welcome! I'm really looking forward to do some deep-learning in Swift on Linux! Hope we can make this happen 😄

If I understand correctly, the recursivelyAllKeyPaths function gets trapped into a infinite loop in Linux. At a certain time, it exhausts the stack memory and crashes. I already found out that it makes the sequential_parameter_keypaths_and_flattening test crash but also the ANKIExample and the KARATEExample. After disabling the test all other tests pass, so this is good news.

I guess the @_spi(Reflection) api behaves differently under Linux, may even be broken. This week, I want to investigate more thoroughly what exactly happens. Maybe there's already a recorded issue about this? And is this code you wrote or is it code from Swift for Tensorflow? If I understand correctly, @_spi(Reflection) is a private API and it may lead to apps using this API being rejected from the Apple App Store. Would it be an idea to explore an alternative solution? When Swift for Tensorflow was developed macros didn't exist yet in Swift. The Point-Free guys have a CasePathable macro that provides KeyPath functionality for enums. I guess the functionality we are looking for the KeyPathIterable should be similar, and maybe we could develop a macro for this. That being said, I have never written a Swift macro before 😉

Next to this, there's a couple of other things I want to focus on next week:

• MNISTExample crashes on my local Ubuntu, but runs fine in the container, so there must still be some left-over issues from compiling it locallly.
• Getting the pytorch build from source working in the ubuntu container. That is, if you think this is still necessary? I now use the pre-build libtorch which I download from the pytorch website. Is there any reason why we would need to build from source? If not I suggest using the pre-build versions. Do you agree?
• Try to get an overview of how the code is organized and see where I can contribute. I saw already that some functions that have several overloads that now could be completely re-written using variadic generics.

Any other things you have planned or where I could help?

And cool that you've been rebuilding your Ubuntu workstation 🤞!

[pedronahum]

hi @thinkpractice,

This is a very interesting error. I made some changes to the original S4TF code, was trying to preserve the spirit. But might be indeed a better solution to create a macro. I will investigate this further. In fact, someone has already did a lot of heavy lifting: https://github.com/Ryu0118/KeyPathIterable. Maybe this can help us to move things faster.

I read that Swift's C++ interop requires clang (to avoid ABI incompatibility issues, standard library mismatch, etc). So I am wondering if this is creating the reflection issue or not. As you can seen in actions, everything works in the mac profile.

Hoping to be able to help more this week with the ubuntu build. I went the rabbit hole of MLIR the last couple of weeks to see if we can avoid libtorch and use directly stable hlo, openxla; something to consider given all the challenges we are facing.

[thinkpractice]

@pedronahum

This is a very interesting error. I made some changes to the original S4TF code, was trying to preserve the spirit. But might be indeed a better solution to create a macro. I will investigate this further. In fact, someone has already did a lot of heavy lifting: https://github.com/Ryu0118/KeyPathIterable. Maybe this can help us to move things faster.

This looks very very interesting, it's exactly what I was thinking of achieving! It also has var recursivelyAllKeyPaths: [PartialKeyPath<Self>] and var recursivelyAllAnyKeyPaths: [AnyKeyPath] properties, which should be equivalent to the ones in the TaylorTorch code. This would let us get rid of those @_spi imports. I would like to investigate this a bit further!

I read that Swift's C++ interop requires clang (to avoid ABI incompatibility issues, standard library mismatch, etc). So I am wondering if this is creating the reflection issue or not. As you can seen in actions, everything works in the mac profile.

Ah that explains the build with clang. I didn't think about this possibility, so I guess it's better for me to focus on building pytorch from source code in the docker. Another way to investigate this would be to build a macOS version with the pre-build torch versions. If I don't get the docker build going, I could try to do that on my MacBook Pro. In any case, we need to rule out any issues with the swift compiler on Linux. The KeyPathIterable may only point at a deeper issue, so if we would solve that using the macro above, there may still be other issues.

Hoping to be able to help more this week with the ubuntu build.

That would be great 😄 It's always good to have a second pair of eyes 😄

I went the rabbit hole of MLIR the last couple of weeks to see if we can avoid libtorch and use directly stable hlo, openxla; something to consider given all the challenges we are facing.

Nice! I think libtorch is a fast way forward. I remember there were talks about using MLIR a couple of years ago when I tried to assist in another attempt to revive Swift for Tensorflow. I think it's also what Mojo uses for their compiler. I don't know anything about hlo or openxla. Do they provide similar implementations to libtorch or are they more low-level?

[thinkpractice]

@pedronahum getting a bit confused with the Swift C++ Interop. It states here that by default Swift uses libstdc++ on Ubuntu for C++ Interop. It also states that Interop only works with clang and Apple clang, as you've already described. If we want to use libc++ though, we can only use libc++-18-dev which I assume comes with clang-18 (and that's why clang-18 was installed in the docker). However, swift packs clang-17 by default and I wonder if clang 17 and 18 are compatible. Would this explain some of the linker errors? And do we really need to build pytorch with libc++ or can we also build it with libstdc++ if this is the standard on Ubuntu. And if so, do we even need to build it with clang or can we just use the pre-build libraries. Maybe this is something we should ask on the swift forums instead?

[thinkpractice]

@pedronahum I think I found the problem. I isolated the KeyPathIterable code in a separate project here to test it without any pytorch related code, to see whether the crash is related to the c++ interop, or whether it's related to the _spi(Reflection) APIs. The example works fine with swift 6.2.1 but crashes when I run the code with the main-snapshot-2025-10-02 version we use for TaylorTorch. It's exactly the same error as I'm getting when I'm running the TaylorTorch code:

◇ Test recursionTest() started.
Swift/UnsafeRawBufferPointer.swift:468: Fatal error: UnsafeMutableRawBufferPointer.storeBytes out of bounds

So, long story short, I think we will be able to use pre-build versions of pytorch. I'm assuming SwiftInterop on Linux is using libstdc++ because most Linux libraries are built with that (i.e. GCC)? This would make sense because it would be a lot of work to recompile all Linux libraries using clang just for the sake of using the C++ interop. In this way, I think we can use any pre-compiled Linux c++ library for the Swift C++ Interop and just install that with apt or any other package manager. I think we need to ask for feedback on this assumption on the Swift forums though...

If this assumption is true though, it would save us a lot of work 😄 as we can just grab the libtorch builds from the website! Not sure whether this would work also on Mac because there clang uses libc++ by default... this of course also depends on how libtorch is build for macOS.

[thinkpractice]

@pedronahum indeed! I will investigate more today too 😄

[thinkpractice]

@pedronahum It looks like it's our "famous" test again crashing, in the crash log I'm seeing:

SequentialLayerTests.swift:183:34

sequential_parameter_keypaths_and_flattening()

which is the same test as we had problems with before. I've tried to reproduce the error when running the test in isolation with:

swift test --filter TorchTests.sequential_parameter_keypaths_and_flattening

but haven't been able so far. Because swift testing is multi-threaded now I'm suspecting something related to swift concurrency, but don't know for sure yet...

[pedronahum]

Hi @thinkpractice,

I managed to reproduce the issue :)

We may need to disabled the sequential_parameter_keypaths_and_flattening test. This is the same KeyPath issue we've been seeing - Swift's recursivelyAllWritableKeyPaths and KeyPath projection crash on Linux with complex nested structures. The crash indeed happens at line 183 when trying to model[keyPath: $0] - the same pattern that crashes in Adam optimizer. I contacted people who understand more about the compiler, and they asked for a simple/reproducible example (but this is very hard to isolate - will continue trying). Best, Pedro N.

[thinkpractice]

@pedronahum good to hear! Did you also test on macOS? I had some weird (and unexpected) crashes when running some SQLiteData tests on Linux too. I wonder whether there may be some Linux specific issues/bugs with the swift compiler.

Note also that the test now crashes on the next lines. First it would crash on the line where it would call recursivelyAllWritableKeyPaths, now it crashes indeed when accessing the keypath. As this is not a function that we've created ourselves, I guess indeed it might be a compiler problem. The alternative would be that the returned keypaths would not always be correct but I don't think this is likely.

I only could reproduce this when we're running all tests and I also see a lot of libomp related errors then, so could it be a threading issue maybe? Let's wait also what the compiler people have to say about it. I will see if I can find a way to reproduce it too.

kind regards,

Tim

[pedronahum]

Hi @thinkpractice, just to confirm that I dont see these issues on macOS. Still investigating what can be done here... Best, Pedro