Hi, At the moment I have problems compiling libSM, masked uuid flag via profiles/prefix/darwin/macos/10.6/package.use.mask: # linux-utils comes without uuid lib on darwin 10 x11-libs/libSM uuid As far as I can see ossd-uuid library exists and masking uuid use flag for all packages is not an option. Reproducible: Always
please provide me with a compilation build log failure
Build error: ... checking if IPv6 support should be built... no checking for struct sockaddr_in.sin_len... yes checking for socklen_t... yes checking if Xtrans should support os-specific local connections... no checking for uuid_create... no checking for LIBUUID... no configure: error: requested libuuid support but uuid.pc not found !!! Please attach the following file when seeking support: !!! /opt/portage/var/tmp/portage/x11-libs/libSM-1.2.0/work/libSM-1.2.0/config.log * ERROR: x11-libs/libSM-1.2.0 failed (configure phase): * econf failed * * Call stack: * ebuild.sh, line 62: Called src_configure * environment, line 3402: Called xorg-2_src_configure * environment, line 4286: Called econf '--disable-dependency-tracking' '--disable-ipv6' '--disable-docs' '--without-xmlto' '--with-libuuid' '--without-fop' '--disable-static' * ebuild.sh, line 563: Called die * The specific snippet of code: * die "econf failed" * * If you need support, post the output of 'emerge --info =x11-libs/libSM-1.2.0', * the complete build log and the output of 'emerge -pqv =x11-libs/libSM-1.2.0'. * The complete build log is located at '/opt/portage/var/tmp/portage/x11-libs/libSM-1.2.0/temp/build.log'. * The ebuild environment file is located at '/opt/portage/var/tmp/portage/x11-libs/libSM-1.2.0/temp/environment'. * S: '/opt/portage/var/tmp/portage/x11-libs/libSM-1.2.0/work/libSM-1.2.0' From util-linux ebuild: want_libuuid() { # bug #350841, currently only not on OS X Snow Leopard [[ ${CHOST} != *-darwin10 ]] }
Yeah, this is an interesting bug. It seems the FreeBSD folk disabled the configure check to find if uuid is available just by "default", e.g. in the libc. It must be that they rely on e2fsprogs or util-linux for uuid. Can you check what happens if you uncomment the use uuid || ac_cv_have_uuid_create=no line?
(In reply to comment #3) > Yeah, this is an interesting bug. It seems the FreeBSD folk disabled the > configure check to find if uuid is available just by "default", e.g. in the > libc. It must be that they rely on e2fsprogs or util-linux for uuid. > > Can you check what happens if you uncomment the use uuid || > ac_cv_have_uuid_create=no line? I also am experiencing this bug on OSX 10.6 with gentoo prefix. Looking at the ebuild the line you mentioned is already uncommented for 1.2.0. Just in case you meant the opposite I decided to comment it out and that had no effect..
Sorry, guys, but I can not put more time into investigating.
(In reply to comment #5) > Sorry, guys, but I can not put more time into investigating. Removing the uuid use flag from libSM gets it to compile for me as well. On my Gentoo workstation uuid.pc is owned by util-linux. Looking at the files installed for util-linux package on my osx 10.6 prefix uuid is never installed. Removing the uuid use flag by putting "x11-libs/libSM uuid" in $EPREFIX/usr/portage/profiles/prefix/darwin/macos/package.use.mask works for me. Should this e added by default to the macos profiles? Maybe even for all packages with uuid in USE flags? What are the potential issues with this?
JTRiley, I think it's not correct move to disable it for all packages. I briefely scanned packages that use the flag and some of them use different implmentations, so they depend on different packages.
(In reply to comment #7) > JTRiley, I think it's not correct move to disable it for all packages. I > briefely scanned packages that use the flag and some of them use different > implmentations, so they depend on different packages. Hmmm OK but these packages are likely to also fail without disabling the flag because there is no uuid/libuuid currently on macos, right? I don't think we should keep the flag enabled unless we can actually compile against something. If one of those packages absolutely requires uuid then they wouldn't work on macos anyway is my guess...
ok, here is why what where for as much as I know. The libuuid by util-linux produces an incompatible header with existing stuff in a Darwin 10 system. Darwin is like FreeBSD and Solaris equipped with uuid in libc for ages. The thing now is that libSM apparently needs something fancy that uuid on these systems doesn't provide. I basically got lost/sidetracked how to solve this correctly. I think we shouldn't be providing uuid on any platform that has it itself, since system headers may rely on it. Perhaps just fixing util-linux' headers to be compatible would work good enough as well.
libSM's configure check is actually quite stupid. Worked around it now to trick it into using the host provided uuid functionality on Darwin (and Solaris). Thanks
