search

ValveSoftware / Proton

Compatibility tool for Steam Play based on Wine and additional components
Other
24.45k stars 1.07k forks source link

Issues Compiling Proton Without Steam Runtime #3058

Closed mikeseese closed 5 years ago

mikeseese commented 5 years ago

Hello!

I'm trying to follow the instructions on how to compile without the steam runtime. I'm using Vagrant 2.2.5 on Ubuntu 19.04, and I'm checked out at https://github.com/ValveSoftware/Proton/commit/c149aae8881f92b35e9d5627c74dac3ac3ed1586.

However, I've had to make some changes to get where I'm at now:

And then I was a bit more significantly off to the races without build errors, but I now come to a linker/undefined reference error that my Google Fu is not turning anything up:

make[3]: Entering directory '/home/vagrant/build/obj-wine32/dlls/winebus.sys'
../../tools/winegcc/winegcc -o winebus.sys.so -B../../tools/winebuild -m32 -fno-PIC \
  -fasynchronous-unwind-tables -shared ../../../../proton/wine/dlls/winebus.sys/winebus.sys.spec \
  -Wl,--subsystem,native bus_iohid.o bus_sdl.o bus_udev.o main.o -lntoskrnl -lsetupapi -ladvapi32 \
  ../../libs/port/libwine_port.a -L/home/vagrant/build/obj-tools32/lib
bus_sdl.o: In function `try_add_device':
/home/vagrant/build/obj-wine32/dlls/winebus.sys/../../../../proton/wine/dlls/winebus.sys/bus_sdl.c:1055: undefined reference to `is_already_opened_by_hidraw'
/usr/bin/ld: winebus.sys.so: hidden symbol `is_already_opened_by_hidraw' isn't defined
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
winegcc: gcc failed
Makefile:273: recipe for target 'winebus.sys.so' failed
make[3]: *** [winebus.sys.so] Error 2
make[3]: Leaving directory '/home/vagrant/build/obj-wine32/dlls/winebus.sys'
Makefile:9031: recipe for target 'dlls/winebus.sys' failed
make[2]: *** [dlls/winebus.sys] Error 2
make[2]: Leaving directory '/home/vagrant/build/obj-wine32'
../proton/build/makefile_base.mak:864: recipe for target 'wine32-intermediate' failed
make[1]: *** [wine32-intermediate] Error 2
make[1]: Leaving directory '/home/vagrant/build'
../proton/build/makefile_base.mak:17: recipe for target 'nested_make' failed
make: *** [nested_make] Error 2

After going through all of this, I feel like I'm missing some important build steps. Am I on the right host OS/distribution? Does it matter? What's a known reproducible environment which I can bootstrap to get this building properly? I'm not doing anything fancy (yet at least), and really just want to get a successful compilation. I'm willing to try dual booting a fresh Linux OS if there is a separate known-working configuration.

I need to get my build environment setup properly as I'll probably need to make changes (and hopefully contributions) in the future. I would appreciate any help! Thanks!

mikeseese commented 5 years ago

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

mikeseese commented 5 years ago

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

ghost commented 5 years ago

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 ;-)

aeikum commented 5 years ago

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).

mikeseese commented 5 years ago

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

aeikum commented 5 years ago

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

mikeseese commented 5 years ago

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.

aeikum commented 5 years ago

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.

mikeseese commented 5 years ago

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