| View previous topic :: View next topic |
| Author |
Message |
Nicias
Guru
Joined: 06 Dec 2005
Posts: 446
|
|
| Back to top |
|
 |
darkphader
Veteran
Joined: 09 May 2002
Posts: 1217
Location: Motown
|
 Posted: Wed Jun 25, 2014 2:33 am Post subject: |
 |
|
Unfortunately no.
_________________
WYSIWYG - What You See Is What You Grep |
|
| Back to top |
|
|
Chewi
Developer
Joined: 01 Sep 2003
Posts: 886
Location: Edinburgh, Scotland
|
| Posted: Wed Jun 25, 2014 6:28 am Post subject: |
|
|
| No? Damn, that sucks. It does mention it in the changelog though. I don't have a Blu-ray handy to try it right now. |
|
| Back to top |
|
|
darkphader
Veteran
Joined: 09 May 2002
Posts: 1217
Location: Motown
|
| Posted: Wed Jun 25, 2014 2:03 pm Post subject: |
|
|
| Chewi wrote: | | No? Damn, that sucks. It does mention it in the changelog though. I don't have a Blu-ray handy to try it right now. |
You don't need a disc to see the failure. Just run makemkvcon info in a terminal: | Code: | $ makemkvcon info
MakeMKV v1.8.11 linux(x64-release) started
Segmentation fault |
_________________
WYSIWYG - What You See Is What You Grep |
|
| Back to top |
|
|
Chewi
Developer
Joined: 01 Sep 2003
Posts: 886
Location: Edinburgh, Scotland
|
| Posted: Wed Jun 25, 2014 2:05 pm Post subject: |
|
|
Hmm yeah I get that too.  |
|
| Back to top |
|
|
deagol
n00b
Joined: 12 Jul 2014
Posts: 61
|
| Posted: Sat Jul 12, 2014 12:13 pm Post subject: |
|
|
I found a simple workaround: LD_PRELOAD
I copied the libc from a ubuntu live CD (Kubuntu 14.04, amd64, to be specific).
Then you can launch makemkv this way:
| Code: |
LD_PRELOAD=./libc.so.6 makemkv
|
I'm sure this would also work with an older libc from gentoo or other sources.
This seems to avoid the segfault with minimal fuss. |
|
| Back to top |
|
|
Chewi
Developer
Joined: 01 Sep 2003
Posts: 886
Location: Edinburgh, Scotland
|
| Posted: Sat Jul 12, 2014 12:32 pm Post subject: |
|
|
| I'm not sure how that works, deagol. I tried that and similar things but glibc is not backwards-compatible. Even if you rebuild makemkv with the older glibc, it doesn't help the fact that other libraries were still built against the newer version. |
|
| Back to top |
|
|
deagol
n00b
Joined: 12 Jul 2014
Posts: 61
|
| Posted: Sat Jul 12, 2014 6:16 pm Post subject: |
|
|
I had a closer look, and I think I found out why it's working for me...
The libc I copied from ubuntu is the following: libc-bin-2.19-0ubuntu6
My gentoo installations is using: sys-libs/glibc-2.19-r1
Looks like it's basically the same library or at least the same version!
So I compared the source of the two libraries but found out that assumption is wrong.
Ubuntu is using EGLIBC, which seems to be a alternate implementation of glibc.
So we may have a new workaround: compile a eglibc with the same version as glibc on our sytem, since as long as we have the same version they are compatible (enough) for us to use und use this version with LD_PRELOAD.
I tried that and it works for me.
Maybe a short manual what I have done:
| Code: | svn co svn://svn.eglibc.org/branches/eglibc-2_19 eglibc-2.19
cd eglibc-2.19/libc; mkdir build; cd build; ../configure --disable-sanity-checks; make -j9
cp libc.so /tmp
LD_PRELOAD=/tmp/libc.so /opt/bin/makemkvcon info
|
|
|
| Back to top |
|
|
darkphader
Veteran
Joined: 09 May 2002
Posts: 1217
Location: Motown
|
| Posted: Sat Jul 12, 2014 7:40 pm Post subject: |
|
|
| deagol wrote: | | Code: | svn co svn://svn.eglibc.org/branches/eglibc-2_19 eglibc-2.19
cd eglibc-2.19/libc; mkdir build; cd build; ../configure --disable-sanity-checks; make -j9
cp libc.so /tmp
LD_PRELOAD=/tmp/libc.so /opt/bin/makemkvcon info
|
|
Unfortunately the make fails here for me. | Code: | plural.c:182:5: error: conflicting types for ‘__gettextparse’
int __gettextparse (void);
^
In file included from plural.y:35:0:
plural-exp.h:97:23: note: previous declaration of ‘__gettextparse’ was here
# define PLURAL_PARSE __gettextparse
^
plural-exp.h:114:12: note: in expansion of macro ‘PLURAL_PARSE’
extern int PLURAL_PARSE PARAMS ((void *arg));
^
plural.c:63:25: error: conflicting types for ‘__gettextparse’
#define yyparse __gettextparse
^
plural.c:1127:1: note: in expansion of macro ‘yyparse’
yyparse (void)
^
In file included from plural.y:35:0:
plural-exp.h:97:23: note: previous declaration of ‘__gettextparse’ was here
# define PLURAL_PARSE __gettextparse
^
plural-exp.h:114:12: note: in expansion of macro ‘PLURAL_PARSE’
extern int PLURAL_PARSE PARAMS ((void *arg));
^
plural.c: In function ‘__gettextparse’:
plural.c:1296:7: error: too few arguments to function ‘__gettextlex’
yychar = yylex (&yylval);
^
plural.c:64:25: note: declared here
#define yylex __gettextlex
^
plural.y:69:12: note: in expansion of macro ‘yylex’
static int yylex PARAMS ((YYSTYPE *lval, const char **pexp));
^
plural.y:178:29: error: ‘arg’ undeclared (first use in this function)
((struct parse_args *) arg)->res = $1;
^
plural.y:178:29: note: each undeclared identifier is reported only once for each function it appears in
../o-iterator.mk:9: recipe for target '/home/smythe/src/eglibc-2.19/libc/build/intl/plural.o' failed
|
_________________
WYSIWYG - What You See Is What You Grep |
|
| Back to top |
|
|
Chewi
Developer
Joined: 01 Sep 2003
Posts: 886
Location: Edinburgh, Scotland
|
| Posted: Sat Jul 12, 2014 7:45 pm Post subject: |
|
|
| That's an interesting discovery and I hope the MakeMKV author takes note. eglibc is no longer being developed though. Debian has switched back to glibc. |
|
| Back to top |
|
|
darkphader
Veteran
Joined: 09 May 2002
Posts: 1217
Location: Motown
|
| Posted: Sat Jul 12, 2014 8:15 pm Post subject: |
|
|
Even though eglibc didn't build here I did make some headway. Built glibc-2.19 using the tar file in distfiles (just locally as in the eglibc example given above, did not install or overwrite anything in the system), applied no patches, and with the LD_PRELOAD command there is success. So it looks the problem is either with a Gentoo patch or something else occurring in the build process when emerging.
_________________
WYSIWYG - What You See Is What You Grep |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Sat Jul 12, 2014 8:37 pm Post subject: |
|
|
Interesting.
What cflags were used for the distfile done locally vs what is done with an ebuild?
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
Chewi
Developer
Joined: 01 Sep 2003
Posts: 886
Location: Edinburgh, Scotland
|
| Posted: Sat Jul 12, 2014 8:42 pm Post subject: |
|
|
| You can probably achieve the same affect by building it with Portage while enabling the vanilla USE flag. Don't actually install it though! I wonder if it's because of FORTIFY_SOURCE. Some distros, including Gentoo, enable it by default, but I'm not sure whether Debian does. I saw it cause segfaults in Wine until they worked around it. |
|
| Back to top |
|
|
darkphader
Veteran
Joined: 09 May 2002
Posts: 1217
Location: Motown
|
| Posted: Sat Jul 12, 2014 9:57 pm Post subject: |
|
|
| Anon-E-moose wrote: | Interesting.
What cflags were used for the distfile done locally vs what is done with an ebuild? |
I didn't set any for the local build. Make.conf has CFLAGS="-O2 -march=native -fomit-frame-pointer -pipe", nothing too extreme.
_________________
WYSIWYG - What You See Is What You Grep |
|
| Back to top |
|
|
darkphader
Veteran
Joined: 09 May 2002
Posts: 1217
Location: Motown
|
| Posted: Sat Jul 12, 2014 10:24 pm Post subject: |
|
|
| darkphader wrote: | | Anon-E-moose wrote: | Interesting.
What cflags were used for the distfile done locally vs what is done with an ebuild? |
I didn't set any for the local build. Make.conf has CFLAGS="-O2 -march=native -fomit-frame-pointer -pipe", nothing too extreme. |
Tried it again with "-O2 -march=native -fomit-frame-pointer -pipe" for CFLAGS and CPPFLAGS and it still works. Maybe it is FORITFY_SOURCE.
_________________
WYSIWYG - What You See Is What You Grep |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Sat Jul 12, 2014 10:43 pm Post subject: |
|
|
You only get FORTIFY_SOURCE with hardened.
Are those having problem running hardened?
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
Chewi
Developer
Joined: 01 Sep 2003
Posts: 886
Location: Edinburgh, Scotland
|
| Posted: Sat Jul 12, 2014 10:48 pm Post subject: |
|
|
That's not true, FORTIFY_SOURCE is used on all Gentoo systems that haven't built gcc/glibc with the vanilla USE flag. It is also used by default on Fedora and openSUSE.
| Code: | $ gcc -dM -E - < /dev/null | fgrep FORTIFY_SOURCE
#define _FORTIFY_SOURCE ((defined __OPTIMIZE__ && __OPTIMIZE__ > 0) ? 2 : 0) |
I tried building makemkv with -U_FORTIFY_SOURCE but it didn't help. Maybe that's because of parts of it are precompiled or maybe I'm just barking up the wrong tree. |
|
| Back to top |
|
|
darkphader
Veteran
Joined: 09 May 2002
Posts: 1217
Location: Motown
|
| Posted: Sat Jul 12, 2014 11:01 pm Post subject: |
|
|
I tried to locally build glibc with FORTIFY_SOURCE but the configure fails: | Code: | checking for tls_model attribute... no
configure: error: support for the tls_model attribute is required |
Without setting FORTIFY_SOURCE the tls_model always passes: | Code: | | checking for tls_model attribute... yes |
Even using -D_FORTIFY_SOURCE=0 (as opposed to 1, or 2) it still fails. I can pass -U_FORTIFY_SOURCE with no issues.
_________________
WYSIWYG - What You See Is What You Grep |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Sun Jul 13, 2014 12:13 am Post subject: |
|
|
| Chewi wrote: | That's not true, FORTIFY_SOURCE is used on all Gentoo systems that haven't built gcc/glibc with the vanilla USE flag. It is also used by default on Fedora and openSUSE.
| Code: | $ gcc -dM -E - < /dev/null | fgrep FORTIFY_SOURCE
#define _FORTIFY_SOURCE ((defined __OPTIMIZE__ && __OPTIMIZE__ > 0) ? 2 : 0) |
I tried building makemkv with -U_FORTIFY_SOURCE but it didn't help. Maybe that's because of parts of it are precompiled or maybe I'm just barking up the wrong tree. |
| Code: | eblit-src_unpack-post() {
if use hardened ; then
cd "${S}"
einfo "Patching to get working PIE binaries on PIE (hardened) platforms"
gcc-specs-pie && epatch "${FILESDIR}"/2.17/glibc-2.17-hardened-pie.patch
epatch "${FILESDIR}"/2.19/glibc-2.19-hardened-configure-picdefault.patch
epatch "${FILESDIR}"/2.18/glibc-2.18-hardened-inittls-nosysenter.patch
einfo "Installing Hardened Gentoo SSP and FORTIFY_SOURCE handler"
cp -f "${FILESDIR}"/2.18/glibc-2.18-gentoo-stack_chk_fail.c \
debug/stack_chk_fail.c || die
cp -f "${FILESDIR}"/2.18/glibc-2.18-gentoo-chk_fail.c \
debug/chk_fail.c || die
|
This is from the glibc ebuild. The handler doesn't happen unless it's hardened.
And just because gcc has it defined doesn't mean it's used. It's simply defined.
I'd have to look at the source code for gcc to see if it gets used.
I don't know what else it does, and I do know that it's also in glibc 2.17 which does work
so it's likely something else.
I'm just throwing out suggestions and thoughts.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
Chewi
Developer
Joined: 01 Sep 2003
Posts: 886
Location: Edinburgh, Scotland
|
| Posted: Sun Jul 13, 2014 8:19 am Post subject: |
|
|
That appears to be one specific security feature. If you look at those files, you'll see they don't even use FORTIFY_SOURCE or FORTIFY_LEVEL. The vanilla glibc sources are littered with these. Though that makes me think that even if you built it manually without Portage, it would still enable FORTIFY_SOURCE because it's enabled in gcc.
I just built glibc with the vanilla USE flag on and "makemkvcon info" still segfaults for me if I try to use LD_PRELOAD or LD_LIBRARY_PATH. I'll give it a try without Portage next.
Update: That does indeed work. Hmm. I'll go through the ebuild later. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Sun Jul 13, 2014 9:52 am Post subject: |
|
|
It may very well be something hidden in the eclass directory of portage,
something in toolchain* or something else that gets pulled in with an ebuild.
Later I'll check and see if I can pinpoint when people started having problems
and whether they changed something in the eclass dir at that time.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
Chewi
Developer
Joined: 01 Sep 2003
Posts: 886
Location: Edinburgh, Scotland
|
| Posted: Sun Jul 13, 2014 10:26 am Post subject: |
|
|
I've got it, I've got it! It's this.
| Code: | # We take care of patching our binutils to use both hash styles,
# and many people like to force gnu hash style only, so disable
# this overriding check. #347761
export libc_cv_hashstyle=no |
I need to do some more research around it and double-check that it really is this but if I build glibc manually with that variable set to no then it segfaults. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Sun Jul 13, 2014 11:21 am Post subject: |
|
|
If one runs the configure command, ie build glibc without emerge/ebuild,
then it runs a check on that variable and at least on my system the check comes back as yes, not no.
But there is something else going on, my best guess, is something changed inside glibc or the binutils because that
override is used in glibc 2.17 and last I checked that worked on my system with makemkv.
If compiling it from scratch works then it does provide a workaround for the problem, not optimal of course.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
Chewi
Developer
Joined: 01 Sep 2003
Posts: 886
Location: Edinburgh, Scotland
|
| Posted: Sun Jul 13, 2014 11:34 am Post subject: |
|
|
| Anon-E-moose wrote: | If one runs the configure command, ie build glibc without emerge/ebuild,
then it runs a check on that variable and at least on my system the check comes back as yes, not no. |
Exactly, setting it to no causes the problem.
| Anon-E-moose wrote: | But there is something else going on, my best guess, is something changed inside glibc or the binutils because that
override is used in glibc 2.17 and last I checked that worked on my system with makemkv. |
I checked and that line was added back in 2011, way before 2.17, but I don't think that matters. There are many factors at play here. There may have even been more than one problem. All I know is that for the current version, this seems to be the key. |
|
| Back to top |
|
|
Chewi
Developer
Joined: 01 Sep 2003
Posts: 886
Location: Edinburgh, Scotland
|
| Posted: Sun Jul 13, 2014 12:17 pm Post subject: |
|
|
| I don't think there's much we can do about this on our end and the problem lies in the closed source code so I've now sent mike admin a PM on the MakeMKV forums. |
|
| Back to top |
|
|
|
Multimedia
