Maarten Baert's website

Game Maker / C++ projects

Home Model Creator ExtremePhysics Game Maker DLLs SimpleScreenRecorder   Recent comments Search

Last modified: Sun, 5 Jan 2014
Refresh

Recording Steam games


Recording Steam games is possible, but not so straightforward. As with any program, you can use 'Record the entire screen' or 'Record a fixed rectangle', but you will get better results with 'OpenGL recording'.

Warning

OpenGL recording works by injecting a library into the program that will be recorded. This library will override some system functions in order to capture the frames before they are displayed on the screen. If you are trying to record a game that tries to detect hacking attempts on the client side, it's (theoretically) possible that the game will consider this a hack. This might even get you banned, so it's a good idea to make sure that the program you want to record won't ban you, *before* you try to record it. You've been warned :).

Native Steam for Linux

  1. If you have a 64-bit system, make sure that you have the 32-bit SimpleScreenRecorder libraries installed, because all Steam games are 32-bit (as far as I know).

  2. In SimpleScreenRecorder, go to the input page and select OpenGL recording.

  3. Click the OpenGL settings button.

  4. Type %command% in the Command textbox.

  5. Uncheck Start the OpenGL application automatically.

  6. For most games, it's also a good idea to check Limit application frame rate.

  7. Continue to the output page and choose your favorite file format and codecs.

  8. Continue to the recording page. The log will show a line like this:

    Quote

    [GLInjectLauncher::Init] Full command: LD_PRELOAD=libssr-glinject.so SSR_GLINJECT_SHM=2129944 %command%

    Select the part from LD_PRELOAD to %command% and press Ctrl+C.

  9. Open Steam (while keeping SimpleScreenRecorder open).

  10. Right-click the game you want to record, and click Properties.

    Image: steam1.png

  11. Click the Set launch options button, and paste the command that you copied from SimpleScreenRecorder.

    Image: steam2.png

    Obviously the number 2129944 will probably be different :).

  12. Now start the game from Steam. SimpleScreenRecorder should now detect the game so you can start recording.

  13. When you're done, go back to the game properties and make the launch options textbox empty again. Otherwise the game will not start anymore after you've closed SimpleScreenRecorder's recording page.

Steam for Windows running through WINE

This is actually simpler than the native version of Steam, because the Windows version doesn't use OpenGL for the main Steam window.

  1. If you have a 64-bit system, make sure that you have the 32-bit SimpleScreenRecorder libraries installed, because Steam games are 32-bit (as far as I know).

  2. In SimpleScreenRecorder, go to the input page and select OpenGL recording.

  3. Click the OpenGL settings button.

  4. Type wine <path-to-steam-exe> in the Command textbox. Replace <path-to-steam-exe> with the location of the main Steam executable.

  5. Check Start the OpenGL application automatically.

  6. For most games, it's also a good idea to check Limit application frame rate.

  7. Continue to the output page and choose your favorite file format and codecs.

  8. Continue to the recording page. Steam should start automatically.

  9. Now start the game from Steam. SimpleScreenRecorder should now detect the game so you can start recording.


Comments

Marcmagus

Comment #1: Tue, 27 Aug 2013, 19:33 (GMT+1, DST)

Quote


This process doesn't work for recording Windows Steam games run under wine, but SimpleScreenRecorder is perfectly capable of recording these as well. It's necessary to launch wine with the OpenGL injection already running. What I've found easiest for me:

Follow the above steps through 8 (you are now on the Recording page)

9. Copy everything from "LD_PRELOAD" up to, but not including, "%command%".

10. At the shell, prefix your usual wine command with what you've just copied. Here's what mine looks like:

$ LD_PRELOAD=libssr-glinject.so SSR_GLINJECT_SHM=109051905 wine-steam

(I have a little shell script called wine-steam which sets my WINEPREFIX and changes directory into the steam directory to make life easier. The $ is my bash prompt, of course.)

11. Start the game from Steam. Do not change the launch options like you would for a Linux-native Steam game.

12. Once the game has started, start recording.

Maarten Baert

Administrator

Comment #2: Fri, 30 Aug 2013, 23:41 (GMT+1, DST)

Quote


@Marcmagus: That is indeed possible, but if you try that with the Linux version of Steam, it will record both the game and the Steam window itself, because they all use OpenGL. Doesn't the same happen with the WINE version?

Last modified: Fri, 30 Aug 2013, 23:41 (GMT+1, DST)

Marcmagus

Comment #3: Thu, 12 Sep 2013, 22:20 (GMT+1, DST)

Quote


Not at all; I guess Steam under wine doesn't use OpenGL. I get just the game window. If I try to start recording before I have a game window, I get an error that the application hasn't created an OpenGL window yet.

The Steam overlay is captured by ssr when active, which is pretty much what I'd expect.

If you try to do it the native Steam approach, it doesn't work at all: not sure if that's because Windows handles environment variables differently or because the injection can't be reached from in the middle of wine like that.

The only drawback is that if you stop recording and want to start again you need to completely restart Steam, hence the FR for reusing a session.

Maarten Baert

Administrator

Comment #4: Mon, 16 Sep 2013, 15:21 (GMT+1, DST)

Quote


Quote: Marcmagus

Not at all; I guess Steam under wine doesn't use OpenGL. I get just the game window. If I try to start recording before I have a game window, I get an error that the application hasn't created an OpenGL window yet.

The Steam overlay is captured by ssr when active, which is pretty much what I'd expect.

If you try to do it the native Steam approach, it doesn't work at all: not sure if that's because Windows handles environment variables differently or because the injection can't be reached from in the middle of wine like that.

The only drawback is that if you stop recording and want to start again you need to completely restart Steam, hence the FR for reusing a session.

That's good to know, I've added it to the article.

The feature request for 'separate file per segment' is there in the master branch, by the way.

Glog78

Comment #5: Sun, 20 Oct 2013, 9:02 (GMT+1, DST)

Quote


Hi Marten,

when i try opengl recording with git from today i get the following error:

[SSR-GLInject] Warning: glXSwapBuffers called without existing frame grabber, creating one assuming window == drawable.
[SSR-GLInject] GLFrameGrabber for [0x930aa0-0x6e00013-0x6e00013] created.
[SSR-GLInject] Error: Can't attach to main shared memory (id = 109051905)!
[SSR-GLInject] Library unloaded.

do i miss something ?

Also how to determine the id , which i need to give to the library ?

Maarten Baert

Administrator

Comment #6: Sun, 20 Oct 2013, 19:16 (GMT+1, DST)

Quote


Quote: Glog78

Hi Marten,

when i try opengl recording with git from today i get the following error:

[SSR-GLInject] Warning: glXSwapBuffers called without existing frame grabber, creating one assuming window == drawable.
[SSR-GLInject] GLFrameGrabber for [0x930aa0-0x6e00013-0x6e00013] created.
[SSR-GLInject] Error: Can't attach to main shared memory (id = 109051905)!
[SSR-GLInject] Library unloaded.

do i miss something ?

Also how to determine the id , which i need to give to the library ?

It works fine for me ...

The id is shown in the log in SSR when you go to the recording page. Note that it will only work as long as the recording page is being shown. I can't choose the id, it is chosen by the kernel. And I don't want to keep the shared memory around any longer than necessary because it uses a lot of memory.

Last modified: Sun, 20 Oct 2013, 19:17 (GMT+1, DST)

Glog78

Comment #7: Mon, 21 Oct 2013, 6:58 (GMT+1, DST)

Quote


thanx the hint with the recording window helped much.

Vidar

Comment #8: Thu, 7 Nov 2013, 0:46 (GMT+1, DST)

Quote


Absolutely love your program but I wanted to ask something. Is it not possible to simply add a global variable in, for example, /etc/environment so that any OpenGL application gets injected automatically by just running it?

Last modified: Thu, 7 Nov 2013, 3:13 (GMT+1, DST)

Maarten Baert

Administrator

Comment #9: Thu, 7 Nov 2013, 19:47 (GMT+1, DST)

Quote


Quote: Vidar

Absolutely love your program but I wanted to ask something. Is it not possible to simply add a global variable in, for example, /etc/environment so that any OpenGL application gets injected automatically by just running it?

Yes, you can put the environment variables variables there, but it's a really bad idea. The library would be injected into literally every program. OpenGL recording isn't perfect yet and it will probably make some things crash. Besides, if you try to start an OpenGL program with GLInject loaded and SSR is not running, the program will fail to start.

If you only want to apply this to Steam games, then maybe this is what you're looking for:
https://github.com/MaartenBaert/ssr/issues/54

Vidar

Comment #10: Thu, 7 Nov 2013, 21:26 (GMT+1, DST)

Quote


Quote: Maarten Baert

Yes, you can put the environment variables variables there, but it's a really bad idea. The library would be injected into literally every program. OpenGL recording isn't perfect yet and it will probably make some things crash. Besides, if you try to start an OpenGL program with GLInject loaded and SSR is not running, the program will fail to start.

I see... then I assume that the library cannot be injected after the application/game has been started, right? If it could that'd make things so easy. Start game > minimize > start SSR > back to game and record. Thanks for the link, gonna check that asap.

Last modified: Thu, 7 Nov 2013, 23:23 (GMT+1, DST)

Chaostiger

Comment #11: Sat, 25 Jan 2014, 20:30 (GMT+1, DST)

Quote


Hello, awesome program. I have an issue though. When I use the openGL method for Dota 2 native, it is only recorded as 640x480. It is running at 1920x1080. How can I fix this? Thanks.

Botpl

Comment #12: Thu, 20 Mar 2014, 20:08 (GMT+1, DST)

Quote


Hi.
Is there any way to conciliate Bumblebee with SimpleScreenRecorder?

Maarten Baert

Administrator

Comment #13: Sat, 22 Mar 2014, 23:53 (GMT+1, DST)

Quote


Quote: Botpl

Hi.
Is there any way to conciliate Bumblebee with SimpleScreenRecorder?

I think it's possible, but I've never tested it so I'm not sure. The right command would be something like:

optirun LD_PRELOAD=libssr-glinject.so SSR_GLINJECT_SHM=2129944 %command%

Or if you are compiling SSR from source and using the glinject-next branch:

optirun ssr-glinject %command%
Ubuntuaddicted

Comment #14: Tue, 25 Mar 2014, 12:07 (GMT+1, DST)

Quote


i tried opengl recording of Portal 2 last night and when I got to the last screen of ssr there was no line within the log window. Did opengl recording setup for steam games changes since you wrote your guide?

Maarten Baert

Administrator

Comment #15: Tue, 25 Mar 2014, 18:15 (GMT+1, DST)

Quote


Quote: Ubuntuaddicted

i tried opengl recording of Portal 2 last night and when I got to the last screen of ssr there was no line within the log window. Did opengl recording setup for steam games changes since you wrote your guide?

Yes, the glinject-next branch uses a different command:

ssr-glinject %command%

You don't need to change or remove this command anymore once the recording is done, you can just leave it in there, it won't do anything as long as SSR isn't recording.

Ubuntuaddicted

Comment #16: Thu, 27 Mar 2014, 1:31 (GMT+1, DST)

Quote


Quote: Maarten Baert
Quote: Ubuntuaddicted

i tried opengl recording of Portal 2 last night and when I got to the last screen of ssr there was no line within the log window. Did opengl recording setup for steam games changes since you wrote your guide?

Yes, the glinject-next branch uses a different command:

ssr-glinject %command%

You don't need to change or remove this command anymore once the recording is done, you can just leave it in there, it won't do anything as long as SSR isn't recording.

not sure i follow you, am i suppose to enter

ssr-glinject %command%

into the ssr command box or that line within the steam game launch options?

UPDATED: i'm really lost. I put ssr-glinject %command% into the steam launch options and Metro: Last Light won't even start now. The thing that's not occurring that used to work was when I would put %command% into the command box within ssr and continue to the recording tab it would actually have a command I could copy and paste into the steam launch options but now nothing shows up in the log box for ssr. Another issue may be that Metro Last Light is NOT an opengl game.

Last modified: Thu, 27 Mar 2014, 4:35 (GMT+1, DST)

Maarten Baert

Administrator

Comment #17: Sat, 29 Mar 2014, 15:25 (GMT+1, DST)

Quote


Quote: Ubuntuaddicted

not sure i follow you, am i suppose to enter

ssr-glinject %command%

into the ssr command box or that line within the steam game launch options?

UPDATED: i'm really lost. I put ssr-glinject %command% into the steam launch options and Metro: Last Light won't even start now. The thing that's not occurring that used to work was when I would put %command% into the command box within ssr and continue to the recording tab it would actually have a command I could copy and paste into the steam launch options but now nothing shows up in the log box for ssr. Another issue may be that Metro Last Light is NOT an opengl game.

Maybe try starting with something simpler first, to make sure that OpenGL recording actually works. Try installing 'mesa-utils' and run:

ssr-glinject glxgears

You should get three colored gears and SSR should be able to record it. If this doesn't work, it means that SSR didn't compile or install properly.

In order to make recording for Steam games work, you may have to disable the Steam overlay (the checkbox right above the launch options button).

If that still doesn't fix the crash, you should also disable the steam runtime. I don't think this will be needed on Ubuntu though. But this is how you do it: Quit Steam, then start it from a terminal with this command:

STEAM_RUNTIME=0 steam

This will only work if you have all the required dependencies installed which is probably not the case initially. I'm still trying to find a solution for this. The problem appears to be that my GLInject library is pulling in some system libraries that interfere with the Steam runtime.

Dubslow

Comment #18: Mon, 7 Apr 2014, 2:13 (GMT+1, DST)

Quote


Okay, there's something going wrong here.

Firstly, I want to double check/confirm that the former glinject-branch was merged into master? I ask for two reasons: 1) github has master, wayland, backport, and libdrm branches, but no glinject-next branch, and 2) despite pulling only from master, the version I installed from my local git clone also does not output any SHM stuff into the recording page log when I attempt to do OpenGL recording.

With that evidence, it seems to me that glinject-next was merged into master, thus rendering the content on this page largely out of date.

Now, I've skimmed the last few weeks of comments here, and while I admit to some confusion about how to operate OpenGL injection, I have nonetheless attempted to get it working, only to run into abject failure.

I tried running "ssr-glinject glxgears" both with and without SSR already open (not recording, however); in all cases, regardless of SSR or its settings w.r.t. OpenGL, the command fails with the following output:

ssr-glinject glxgears
ssr-glinject: LD_PRELOAD = libssr-glinject.so 
ssr-glinject: command = glxgears
[SSR-GLInject] Library loaded (64-bit).
[SSR-GLInject] Library successfully initialized.
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
[SSR-GLInject] Warning: glXSwapBuffers called without existing frame grabber, creating one assuming window == drawable.
[SSR-GLInject] GLFrameGrabber for [0x1155090-0x4200002-0x4200002] created.
[SSR-GLInject] Error: Shared memory id is missing!
[SSR-GLInject] Library unloaded.

(Additionally, whatever fragment of OpenGL attempted to run completely ruined that portion of my monitor, the white fragment in the top left; however since I've had that issue with certain other things as well, I believe this may be a Cinnamon issue than an OpenGL one.)

The same thing happened even with either of "ssrglinject %command%" or "%command%" in the OpenGL settings pop up, then forwarded to the recording page. Attempting to begin recording before running the command failed in the obvious way (couldn't get frame size of the un-run application).

SSR certainly did compile and install correctly, because this is the exact installation I've been using for all my other things, including livestreaming (without OpenGL of course, as this was my first foray into the area).

I'd be happy to help "research" this further in whatever way you need.

Last modified: Mon, 7 Apr 2014, 2:15 (GMT+1, DST)

Maarten Baert

Administrator

Comment #19: Mon, 7 Apr 2014, 23:15 (GMT+1, DST)

Quote


Quote: Dubslow

Firstly, I want to double check/confirm that the former glinject-branch was merged into master? I ask for two reasons: 1) github has master, wayland, backport, and libdrm branches, but no glinject-next branch, and 2) despite pulling only from master, the version I installed from my local git clone also does not output any SHM stuff into the recording page log when I attempt to do OpenGL recording.

Correct.

Quote: Dubslow

With that evidence, it seems to me that glinject-next was merged into master, thus rendering the content on this page largely out of date.

The documentation always refers to the latest stable version. glinject-next has been merged but not released yet, so I can't update this page yet without confusing even more users.

Quote

I tried running "ssr-glinject glxgears" both with and without SSR already open (not recording, however); in all cases, regardless of SSR or its settings w.r.t. OpenGL, the command fails with the following output:

It looks like you are loading an old version of the glinject library. You either didn't install it properly, or there is an older version of the library still lying around from a previous SSR install (e.g. from a package that installed to a different location).

The new version of glinject will print something like this:

ssr-glinject: LD_PRELOAD = libssr-glinject.so 
ssr-glinject: command = glxgears
[SSR-GLInject] Library loaded (64-bit).
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
[SSR-GLInject] Warning: glXSwapBuffers called without existing frame grabber, creating one assuming window == drawable.
[SSR-GLInject] [GLXFrameGrabber 1] Created GLX frame grabber.
[SSR-GLInject] [/dev/shm/ssr-channel-maarten/video-12683632896-5273-glx0001-glxgears] Created video stream.
[SSR-GLInject] OpenGL version = 4.4 (4.4.0 NVIDIA 334.21).
[SSR-GLInject] [/dev/shm/ssr-channel-maarten/video-12683632896-5273-glx0001-glxgears] frame size = 300x300.
Quote

(Additionally, whatever fragment of OpenGL attempted to run completely ruined that portion of my monitor, the white fragment in the top left; however since I've had that issue with certain other things as well, I believe this may be a Cinnamon issue than an OpenGL one.)

More likely a Steam issue, I believe. It's not the first time I've seen the Steam window failing to update. Or it could be a combination of the two.

Dubslow

Comment #20: Tue, 8 Apr 2014, 1:31 (GMT+1, DST)

Quote


Quote: Maarten Baert

It looks like you are loading an old version of the glinject library. You either didn't install it properly, or there is an older version of the library still lying around from a previous SSR install (e.g. from a package that installed to a different location).

Huh. I don't know how that could have happened, seeing as I've only installed from my own compilation, and that with the provided script.

At any rate, I did

sudo rm $(locate libssr-gl | grep /usr)

and reinstalled, and that seemed to fix at least this basic issue.

Quote: Maarten Baert

More likely a Steam issue, I believe. It's not the first time I've seen the Steam window failing to update. Or it could be a combination of the two.

Well the picture I gave you was the result of running `ssr-glinject glxgears` -- Steam was not involved (but I have had the same issue with Steam windows from time to time). This is what makes me think it's an issue with Cinnamon.

At any rate, I still have no idea how to get the glinject working. After properly installing libssr-glinject, I tried "ssr-glinject glxgears" with an SSR instance open and set to OpenGL recording, but the command spat this:

ssr-glinject glxgears
ssr-glinject: LD_PRELOAD = libssr-glinject.so 
ssr-glinject: command = glxgears
ERROR: ld.so: object 'libssr-glinject.so' from LD_PRELOAD cannot be preloaded: ignored.
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
303 frames in 5.0 seconds = 60.442 FPS
<etc ...>

I tried ignoring terminal by setting the OpenGL command (in the SSR popup) to "glxgears", checking "Launch automatically", and going to the recording page, whence the glxgears window appeared and started turning just fine, however attempting to start recording. However, in that case, the SSR log window came back with this:

[PageRecord::StartOutput] Starting output ...
[PageRecord::StartOutput] Error: Could not get the size of the OpenGL application. Either the application wasn't started correctly, or the application hasn't created an OpenGL window yet. If you want to start recording before starting the application, you have to enable scaling and enter the video size manually.
[PageRecord::StartOutput] Error: Something went wrong during initialization.

This appeared while I was watching the gears autolaunched by SSR.

At this point I'm inclined to attribute the issues to my own ignorance, so I happily await a new release so this page can be updated. :-)

Maarten Baert

Administrator

Comment #21: Tue, 8 Apr 2014, 2:56 (GMT+1, DST)

Quote


Quote: Dubslow

At any rate, I still have no idea how to get the glinject working. After properly installing libssr-glinject, I tried "ssr-glinject glxgears" with an SSR instance open and set to OpenGL recording, but the command spat this:

ssr-glinject glxgears
ssr-glinject: LD_PRELOAD = libssr-glinject.so 
ssr-glinject: command = glxgears
ERROR: ld.so: object 'libssr-glinject.so' from LD_PRELOAD cannot be preloaded: ignored.
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
303 frames in 5.0 seconds = 60.442 FPS
<etc ...>

This makes no sense, glxgears is 64-bit and ld.so can't load libssr-glinject.so, so either libssr-glinject.so can't be found or only the 32-bit version can be found. Did you use simple-build-and-install, or did you use some other command to install the library?

Try to delete the build and build32 folders, and run ./simple-build-and-install again. That should fix it if it's simply a problem with the build system. If that fails, I would like to see the output of find /usr -name libssr-glinject.so | xargs file (locate can be out of date unless you run sudo updatedb first).

Dubslow

Comment #22: Tue, 8 Apr 2014, 3:16 (GMT+1, DST)

Quote


Quote: Maarten Baert

This makes no sense, glxgears is 64-bit and ld.so can't load libssr-glinject.so, so either libssr-glinject.so can't be found or only the 32-bit version can be found. Did you use simple-build-and-install, or did you use some other command to install the library?

Try to delete the build and build32 folders, and run ./simple-build-and-install again. That should fix it if it's simply a problem with the build system. If that fails, I would like to see the output of find /usr -name libssr-glinject.so | xargs file (locate can be out of date unless you run sudo updatedb first).

The simple-build-and-install put the libs in both /usr/lib32 and /usr/lib64 (and I locateed that after sudo updatedb.

To be extra certain, here's a terminal session:

bill@Gravemind ~/twitch/ssr ∰∂ sudo updatedb
bill@Gravemind ~/twitch/ssr ∰∂ locate libssr-gl
/home/bill/twitch/ssr/build/glinject/libssr-glinject.la
/home/bill/twitch/ssr/build/glinject/.libs/libssr-glinject.la
/home/bill/twitch/ssr/build/glinject/.libs/libssr-glinject.lai
/home/bill/twitch/ssr/build/glinject/.libs/libssr-glinject.so
/home/bill/twitch/ssr/build32/glinject/libssr-glinject.la
/home/bill/twitch/ssr/build32/glinject/.libs/libssr-glinject.la
/home/bill/twitch/ssr/build32/glinject/.libs/libssr-glinject.lai
/home/bill/twitch/ssr/build32/glinject/.libs/libssr-glinject.so
/usr/lib32/libssr-glinject.la
/usr/lib32/libssr-glinject.so
/usr/lib64/libssr-glinject.la
/usr/lib64/libssr-glinject.so
bill@Gravemind ~/twitch/ssr ∰∂ sudo rm $(!!)
sudo rm $(locate libssr-gl)
bill@Gravemind ~/twitch/ssr ∰∂ sudo updatedb
bill@Gravemind ~/twitch/ssr ∰∂ locate libssr-gl
bill@Gravemind ~/twitch/ssr ∰∂ rm build
bill@Gravemind ~/twitch/ssr ∰∂ rm build32
bill@Gravemind ~/twitch/ssr ∰∂ ./simple-build-and-install

<configure, compile, configure again compile again>

Making install in glinject
make[1]: Entering directory `/home/bill/twitch/ssr/build/glinject'
make[2]: Entering directory `/home/bill/twitch/ssr/build/glinject'
 /bin/mkdir -p '/usr/lib64'
 /bin/bash ../libtool   --mode=install /usr/bin/install -c   libssr-glinject.la '/usr/lib64'
libtool: install: /usr/bin/install -c .libs/libssr-glinject.so /usr/lib64/libssr-glinject.so
libtool: install: /usr/bin/install -c .libs/libssr-glinject.lai /usr/lib64/libssr-glinject.la
libtool: finish: PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/sbin" ldconfig -n /usr/lib64
----------------------------------------------------------------------
Libraries have been installed in:
   /usr/lib64

<some other stuff for the make installs>

Making install in glinject
make[1]: Entering directory `/home/bill/twitch/ssr/build32/glinject'
make[2]: Entering directory `/home/bill/twitch/ssr/build32/glinject'
 /bin/mkdir -p '/usr/lib32'
 /bin/bash ../libtool   --mode=install /usr/bin/install -c   libssr-glinject.la '/usr/lib32'
libtool: install: /usr/bin/install -c .libs/libssr-glinject.so /usr/lib32/libssr-glinject.so
libtool: install: /usr/bin/install -c .libs/libssr-glinject.lai /usr/lib32/libssr-glinject.la
libtool: finish: PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/sbin" ldconfig -n /usr/lib32
----------------------------------------------------------------------
Libraries have been installed in:
   /usr/lib32

<...>

Running post-install script ...
Done.
bill@Gravemind ~/twitch/ssr ∰∂ ssr-glinject glxgears
ssr-glinject: LD_PRELOAD = libssr-glinject.so 
ssr-glinject: command = glxgears
ERROR: ld.so: object 'libssr-glinject.so' from LD_PRELOAD cannot be preloaded: ignored.
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
303 frames in 5.0 seconds = 60.525 FPS
<When I closed the window:>
XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":0"
      after 47 requests (47 known processed) with 0 events remaining.
bill@Gravemind ~/twitch/ssr ∰∂ sudo updatedb
bill@Gravemind ~/twitch/ssr ∰∂ find /usr -name libssr-glinject.so | xargs file
find: `/usr/share/doc/google-chrome-stable': Permission denied
/usr/lib32/libssr-glinject.so: ELF 32-bit LSB  shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=5f2e2a5cf488555867c3de4b27f6ae77f5b75d2a, not stripped
/usr/lib64/libssr-glinject.so: ELF 64-bit LSB  shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=de1cb84ba7dfb219190553e9b46a5aa8acad5180, not stripped
bill@Gravemind ~/twitch/ssr ∰∂

Last modified: Tue, 8 Apr 2014, 3:32 (GMT+1, DST)

Maarten Baert

Administrator

Comment #23: Tue, 8 Apr 2014, 3:27 (GMT+1, DST)

Quote


What's the output of cat /etc/ld.so.conf.d/*? Is /usr/lib64 in there?

Dubslow

Comment #24: Tue, 8 Apr 2014, 3:34 (GMT+1, DST)

Quote


Quote: Maarten Baert

What's the output of cat /etc/ld.so.conf.d/*? Is /usr/lib64 in there?

Huh. How strange.

bill@Gravemind ~/twitch/ssr ∰∂ cat /etc/ld.so.conf.d/*
# Multiarch support
/lib/i386-linux-gnu
/usr/lib/i386-linux-gnu
/lib/i486-linux-gnu
/usr/lib/i486-linux-gnu
# libc default configuration
/usr/local/lib
# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu
# Legacy biarch compatibility support
/lib32
/usr/lib32
# Legacy biarch compatibility support
/libx32
/usr/libx32

I guess modern Debian-family distros are well and truly past the use of lib32 and lib64.

Edit: lib64 appears largely unused.

 ls -l /usr/lib64
total 80
drwxr-xr-x 2 root root  4096 Jan 18  2013 kde4
-rwxr-xr-x 1 root root   987 Apr  7 20:11 libssr-glinject.la
-rwxr-xr-x 1 root root 70858 Apr  7 20:11 libssr-glinject.so
 ls -l /lib64
total 0
lrwxrwxrwx 1 root root 32 Nov 29 11:00 ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.17.so
lrwxrwxrwx 1 root root 20 Jan 26 17:30 ld-lsb-x86-64.so.2 -> ld-linux-x86-64.so.2
lrwxrwxrwx 1 root root 20 Jan 26 17:30 ld-lsb-x86-64.so.3 -> ld-linux-x86-64.so.2

Last modified: Tue, 8 Apr 2014, 3:53 (GMT+1, DST)

Maarten Baert

Administrator

Comment #25: Tue, 8 Apr 2014, 4:00 (GMT+1, DST)

Quote


Quote: Dubslow
Quote: Maarten Baert

What's the output of cat /etc/ld.so.conf.d/*? Is /usr/lib64 in there?

Huh. How strange.

bill@Gravemind ~/twitch/ssr ∰∂ cat /etc/ld.so.conf.d/*
# Multiarch support
/lib/i386-linux-gnu
/usr/lib/i386-linux-gnu
/lib/i486-linux-gnu
/usr/lib/i486-linux-gnu
# libc default configuration
/usr/local/lib
# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu
# Legacy biarch compatibility support
/lib32
/usr/lib32
# Legacy biarch compatibility support
/libx32
/usr/libx32

I guess modern Debian-family distros are well and truly past the use of lib32 and lib64.

Edit: lib64 appears largely unused.

 ls -l /usr/lib64
total 80
drwxr-xr-x 2 root root  4096 Jan 18  2013 kde4
-rwxr-xr-x 1 root root   987 Apr  7 20:11 libssr-glinject.la
-rwxr-xr-x 1 root root 70858 Apr  7 20:11 libssr-glinject.so
 ls -l /lib64
total 0
lrwxrwxrwx 1 root root 32 Nov 29 11:00 ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.17.so
lrwxrwxrwx 1 root root 20 Jan 26 17:30 ld-lsb-x86-64.so.2 -> ld-linux-x86-64.so.2
lrwxrwxrwx 1 root root 20 Jan 26 17:30 ld-lsb-x86-64.so.3 -> ld-linux-x86-64.so.2

Usually lib64 either doesn't exist or it is symlinked to the correct directory. You can easily change the simple-build-and-install script so it installs it in the right directory. I will try to update the script and use a more robust detection system.

Maarten Baert

Administrator

Comment #26: Tue, 8 Apr 2014, 4:22 (GMT+1, DST)

Quote


According to this, /usr/lib64 should be a symlink to /usr/lib. So the right solution would be to move your files from /usr/lib64 to /usr/lib, delete /usr/lib64 and then symlink it to /usr/lib.

I can't easily detect the right solution in situations like this, because some distributions do weird things (on Fedora, /usr/lib is 32-bit and /usr/lib64 is 64-bit).

Dubslow

Comment #27: Tue, 8 Apr 2014, 4:32 (GMT+1, DST)

Quote


On Debian systems, the "proper" thing to do would be to put them in either of /usr/lib/i386-linux-gnu or /usr/lib/x86-64-linux-gnu as apporpriate; perhaps you could check "if those exist (i.e. if this is a debian derived distro) then install there, else /usr/lib{32, 64}.

Maarten Baert

Administrator

Comment #28: Tue, 8 Apr 2014, 5:09 (GMT+1, DST)

Quote


Quote: Dubslow

On Debian systems, the "proper" thing to do would be to put them in either of /usr/lib/i386-linux-gnu or /usr/lib/x86-64-linux-gnu as apporpriate; perhaps you could check "if those exist (i.e. if this is a debian derived distro) then install there, else /usr/lib{32, 64}.

But clearly some of your packages didn't do that, otherwise the lib64 directory wouldn't even exist :). Anyway, I will try to detect those instead, but I'm also changing something else at the moment so this will take some time. Can you change the paths yourself for now?

Edit: also, please realize that by doing this, I will probably create more problems for other Debian and Ubuntu users at some point in the future because they will end up with two versions of the library in different locations, so now I have to add additional code to handle that case too ...

Last modified: Tue, 8 Apr 2014, 5:11 (GMT+1, DST)

Dubslow

Comment #29: Tue, 8 Apr 2014, 19:04 (GMT+1, DST)

Quote


Quote: Maarten Baert

But clearly some of your packages didn't do that, otherwise the lib64 directory wouldn't even exist :).

The only things in my /usr/lib64 are "libssr-glinject.so", "libssr-glinject.la", and "kde4/ kcm_adobe_flash_player.so". Considering that there are

dpkg --list | wc -l
3215

more than 3000 packages on this system and there is only one manually-installed adobe flash lib (for which there hasn't been a new version in three years+) in /usr/lib64, I'd say it's pretty unused by all packages. :P

(Also note that even if it didn't exist, the make install runs a mkdir -p /usr/lib64, so the directory not existing wouldn't have stopped it anyways.)

Quote: Maarten Baert

Edit: also, please realize that by doing this, I will probably create more problems for other Debian and Ubuntu users at some point in the future because they will end up with two versions of the library in different locations, so now I have to add additional code to handle that case too ...

I think that's well-worth it to do things the "proper" way. Average users won't know the difference, and "power users" would consider it very strange for something to be in /usr/lib64.

Edit: Just saw the commits -- thanks for all the work you continue to do :D

Last modified: Tue, 8 Apr 2014, 21:02 (GMT+1, DST)

Maarten Baert

Administrator

Comment #30: Tue, 8 Apr 2014, 20:53 (GMT+1, DST)

Quote


Quote: Dubslow

(Also note that even if it didn't exist, the make install runs a mkdir -p /usr/lib64, so the directory not existing wouldn't have stopped it anyways.)

No, because simple-build-and-install only sets /usr/lib64 as LIBDIR if it already exists. So if you run simple-build-and-install without /usr/lib64, it won't be created.

Quote: Dubslow

I think that's well-worth it to do things the "proper" way. Average users won't know the difference, and "power users" would consider it very strange for something to be in /usr/lib64.

I'm already doing that in the last version.

Dubslow

Comment #31: Tue, 8 Apr 2014, 21:03 (GMT+1, DST)

Quote


Quote: Maarten Baert

No, because simple-build-and-install only sets /usr/lib64 as LIBDIR if it already exists. So if you run simple-build-and-install without /usr/lib64, it won't be created.

Damn flash (lol).

I just saw the commits -- thanks for the continuing work! :D

Write a comment