936 reputation
31021
bio website
location
age
visits member for 3 years, 3 months
seen Jul 21 '13 at 4:38

Apr
3
comment dlclose does not call library destructors, dlopen called just once
thats good enough for me, i'll upgrade to 4.8 and see how it goes. If you update your answer with this information, i'll accept the answer
Apr
3
comment dlclose does not call library destructors, dlopen called just once
is not a mangling problem, if that were the case the destructor would not be called at all. Instead what happens is that it is called at application exit.
Apr
3
comment dlclose does not call library destructors, dlopen called just once
where do you got g++ 4.9? i only see 4.8 on the gcc page. Is that some development snapshot? or you did a typo in there?
Apr
3
comment dlclose does not call library destructors, dlopen called just once
you shouldn't use _fini anymore, they are obsolete and dangerous. In theory just destructor and constructor attributes and you should be fine
Apr
3
comment dlclose does not call library destructors, dlopen called just once
actually, what you mean it works? that the destructor is called before dlclose returns?
Apr
3
comment dlclose does not call library destructors, dlopen called just once
thanks @hroptatyr, that gives me hope and strength for the road ahead (of building and installing a new gcc version)
Apr
3
comment dlclose does not call library destructors, dlopen called just once
i suggest you to give a closer look to the documentation, just below the dlclose() section: "manpages.ubuntu.com/manpages/hardy/man3/dlopen.3.html "libraries should export routines using the __attribute__((constructor)) and __attribute__((destructor)) function attributes. See the gcc info pages for information on these, Constructor routines are executed before dlopen() returns, and destructor routines are executed before dlclose() returns."
Dec
23
comment Ubuntu Precise system headers moved somewhere else and sys/ucontext.h cannot be found
failure, for some reason this is not working, i've softlinked the whole /usr/include/x86_64-linux-gnu/sys folder to /usr/include/sys, but still getting the same error... no idea what is going on
Dec
21
comment Ubuntu Precise system headers moved somewhere else and sys/ucontext.h cannot be found
and of course, this situation carries on exactly the same to other distros based on Precise and Quantal, such as Linux Mint 13 and 14.
Dec
21
comment Ubuntu Precise system headers moved somewhere else and sys/ucontext.h cannot be found
This is such an awfully bad solution, that i would most likely downvote it, if it wasn't for the small fact that it is, with great likelihood, also the best possible solution available, given the known constraints of poor architectural and engineering decisions happening at ubuntu. I wouldn't go as far as upvoting it either. I will leave it sit a while, i will catch my breath tomorrow, or probably the day after, probably kick and punch some stuff at the gym, and after i get my morning coffee, i will accept this answer, unless a better one shows up. Also will ponder on other lines of work.
Dec
14
comment Video driver under lxc container?
i mean, i can see direct rendering: yes on the host, but that doesn't translate directly to the container, because the system installation (including the fglrx driver) will not be shared with the containers, right? That article seems to point that at least some direct rendering is possible using the open source driver, which is a good fallback plan for me, but if i could rely on the propietary fglrx ati driver it would be golden
Dec
14
comment Video driver under lxc container?
so, the question is: if i run LIBGL_DEBUG=verbose glxinfo | grep rendering inside the lxc container console, will i see "direct rendering: yes"?
Dec
3
comment indirect rendering issue on 12.04, using ati driver
i changed the symlink in /usr/lib32/dri to point to the x86_64 library and it doesn't give the warning anymore (i know, weird!) so the only remaining error is the cryptic and unhelpful: libGL: screen 0 does not appear to be DRI2 capable
Dec
3
comment indirect rendering issue on 12.04, using ati driver
ok now glxinfo gives this error: libGL error: dlopen /usr/lib32/dri/swrast_dri.so failed (/usr/lib32/dri/swrast_dri.so: wrong ELF class: ELFCLASS32)
Dec
3
comment indirect rendering issue on 12.04, using ati driver
the library is there! so i just need to make a symlink to the other path..
Dec
3
comment indirect rendering issue on 12.04, using ati driver
1st row: libgl1-mesa-dri: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so 2nd row: libgl1-mesa-dri-dbg: /usr/lib/debug/usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
Dec
3
comment indirect rendering issue on 12.04, using ati driver
i just did install libgl1-mesa-dri:i386, but the only library in that folder is /usr/lib32/dri/fglrx_dri.so; swrast_dri.so is still missing. Not sure if i should symlink it to the x86_64 version
Nov
23
comment process id from window id
fair enough. What is the cause of the difference? the application in question is a freeglut sample. Is there something api-wise that a good linux citizen application needs to do in order to have its PID set? Is there something i can do at application-launch so that the PID is set? like setting the x property by an external process?
Nov
23
comment How can I record an OpenGL game in Ubuntu?
there is a follow up for Yukon called glc: github.com/nullkey/glc
Nov
23
comment How can I record an OpenGL game in Ubuntu?
this is a joke right? that question is not a duplicate - those screencast recorder apps are limited to stuff being rendered off the hardware. opengl in gpu rendering requires specialized tools, due to the severe brokenness of the X11 architecture. This question must be reopened