I found is_already_opened_by_hidraw defined in bus_udev.c. I ran nm on it:

vagrant@debian9:~/build$ nm obj-wine32/dlls/winebus.sys/bus_udev.o 
00000004 C driver_key
00000014 r __FUNCTION__.19679
00000000 r __FUNCTION__.19685
00000070 T udev_driver_init
000000b0 T udev_driver_unload
         U vsnprintf
00000000 d __wine_dbch_plugplay
         U __wine_dbg_header
00000000 t wine_dbg_log.constprop.0
         U __wine_dbg_output

which does verify the symbol is not defined. i see that it kind of matches up if HAVE_UDEV is not defined

looks like libudev-dev:i386 package was not installed as well on initialization

going to try a vagrant destroy and bring everything back up with an updated Vagrantfile with the missing packages

After going through all of this, I feel like I'm missing some important build steps.

I literally have no interest in building Proton but just wanted to comment that it seems like you're doing fine whether or not you missed anything because you are able to make your way through the code well enough. So if you can't get to the end in some way then there's something really wrong about that ;-)

The Vagrant build VM is intended to be used with the Steam runtime. I'm not sure it would be useful to try to build in the VM without the runtime. In that case, you're building against the Debian 9 Vagrant VM, which is maybe useful to you or maybe not. What's your end goal, here?

Anyway, in terms of the immediate problem you're dealing with, yes, it seems the new code I added requires libudev to be available at build-time. You could add an implementation of is_already_opened_by_hidraw that just returns FALSE to the else-section of the #ifdef, near the bottom of bus_udev.c. I'd accept a merge request for something like that. Or just fix your package setup (but then we're back to the "do you really want to be doing this?" question, above).

So if you can't get to the end in some way then there's something really wrong about that ;-)

Ha, thanks @byte1024 for the vote of confidence

Thanks @aeikum for the quick response!

The Vagrant build VM is intended to be used with the Steam runtime. I'm not sure it would be useful to try to build in the VM without the runtime.

Well I'm guessing proton and without steam runtime put together is an overall "not officially supported" area for this repo haha. The readme and comments within files made it seem like this would be supported. I'm also fairly certain the issues I'm having are generic (i.e. missing system dependencies) and would be occurring either way.

In that case, you're building against the Debian 9 Vagrant VM, which is maybe useful to you or maybe not.

Not particularly useful one way or another. It seemed from reading the readme, that using Vagrant would be the officially approved way to get a reproducible build environment.

What's your end goal, here?

I want to use proton as an alternative to only using wine to run non-steam applications. My particular targets are Adobe Creative Cloud applications. There have been long-standing issues with wine supporting these, and I wanted to try to see if proton had success. I figure (with high certainty), that it won't work out of the box, and therefore I want to make sure I have a working build environment to iterate changes to get it to work.

Anyway, in terms of the immediate problem you're dealing with...

I was actually able to resolve the specific issue I was having by installing the missing package libudev-dev:i386. The 64 bit dev files were available, but not the 32 bit. By installing this, a #define HAVE_UDEV was defined, which defined the missing symbol appropriately.

We hypothetically could close this issue and I can open a new one (or reopen this one) if I come into another issue. I'll let you @aeikum decide. I am compiling (still compiling, so not sure yet if I've gotten over all the bumps yet) FWIW

Testing if a non-Steam application will work is kind of orthogonal to the runtime. The purpose of the runtime is to provide a stable set of libraries that will work on any distro. If you don't build against the runtime, then there is a good chance that your build will only function on the distro on which you built Proton. In this case, you're building on Debian 9, so it will possibly only work on Debian 9, or closely related distros. If you are not going to build against the runtime, you should build Proton on your target distro.

Or, build it against the runtime (or just use the Proton we ship) and run your application through the Steam client. You can do this with the "Add a non-Steam game" feature at the bottom-left of the Library page in the Steam for Linux client. (Though this feature isn't used a whole lot, so you may run into problems.)

All that said, I think you're right that you will find no more joy running Adobe CC applications in Proton than in Wine :) If this is something you want to work on, I'd suggest running your application through upstream Wine, or through wine-staging. You may find this guide helpful. https://www.codeweavers.com/about/blogs/aeikum/2019/1/3/working-on-wine-part-1-the-wine-ecosystem

Testing if a non-Steam application will work is kind of orthogonal to the runtime. The purpose of the runtime is to provide a stable set of libraries that will work on any distro. If you don't build against the runtime, then there is a good chance that your build will only function on the distro on which you built Proton. In this case, you're building on Debian 9, so it will possibly only work on Debian 9, or closely related distros. If you are not going to build against the runtime, you should build Proton on your target distro.

Ah! Good to know! That would have been fun haha :sweat_smile:. I was thinking the runtime was used to provide steam-specific/game-specific functionalities, and I was just cutting out some extra fat that I didn't need

Or, build it against the runtime (or just use the Proton we ship) and run your application through the Steam client. You can do this with the "Add a non-Steam game" feature at the bottom-left of the Library page in the Steam for Linux client. (Though this feature isn't used a whole lot, so you may run into problems.)

Totally; I was just being preemptive when I knew I was going to run into issues and need to make a build to try to fix each and every little issue

All that said, I think you're right that you will find no more joy running Adobe CC applications in Proton than in Wine :) If this is something you want to work on, I'd suggest running your application through upstream Wine, or through wine-staging. You may find this guide helpful. https://www.codeweavers.com/about/blogs/aeikum/2019/1/3/working-on-wine-part-1-the-wine-ecosystem

Duly noted. I wasn't quite sure exactly what proton brings to the table. Large applications such as the Adobe suite do use more intensive graphics support, so I figured that proton's marriage of wine and dxvk would help tremendously.

Last I heard, the issues with CC are related to pretty aggressive DRM and/or networking requirements. Searching the Wine bug tracker, and/or the wine-staging patch list, may turn up work others have done in this area. You can of course use DXVK with Wine and wine-staging.

Great, thanks for the tips! I think it's safe to close this issue