Xpra: Ticket #971: errors with osx moduleset builds

Related to #533.

I've hit some weird gtk module import problems which forced me to pull the download link for 0.15.5 on osx.

It looked like some modules / libraries needed to be rebuilt. So I tried a few guesses (gtk), and when that didn't work I took the big hammer:

jhbuild clean

(and skip the ones that fail to clean) Then:

jhbuild list | xargs

And rebuild all the modules from this list (since I can't find an easy to force a rebuild of all the modules).

jhbuild buildone -f THELIST

Which failed on:


Using the modulesets was meant to make it easier to rebuild things reliably... now I'm not so sure!

This is not the first time either, a recent update to ffmpeg (or was it x264) caused the gstreamer plugins to fail until they got rebuilt against the update lib.

@smo: did those packages get updated? when? if so, why didn't we automatically rebuild them? why does it break? and more importantly, how do I fix it.. How do we prevent these kinds of problems in the future? should at least have a way of easily locking a particular version so we can rebuild it reliably?

PS: it is possible that some of these errors are specific to my OSX 10.5 gcc 4.2 compiler, but I am not about to switch my build vm, as this one has worked reliably for years (something that is not so easy with OSX virtualized - no other version has been this reliable for me). But I would consider building a new gcc as part of the moduleset build if that helps (who knows what osx patches are required for that though..)



Tue, 01 Sep 2015 07:13:47 GMT - Antoine Martin: owner changed


Wed, 02 Sep 2015 01:54:18 GMT - Smo:

I will have to look into when these have changed recently as I haven't had that much time to work on them.

Most of our issues here is because I have not implemented good dependency checking. Jhbuild does provide this but I did not add these. This is something I could spend some time on so we can avoid it in the future.

Usually I find it best to just

mv ~/gtk ~/gtk.old
jhbuild bootstrap
jhbuild build

Just start over from scratch I know this isn't ideal but this is what I usually do. It takes my machine about 3-4hours to get everything compiled again.

I don't think these are specific to your machine but something probably I updated then you built it and we failed to build stuff dependent on it.


Wed, 02 Sep 2015 08:34:30 GMT - Antoine Martin:

OK, started again from scratch, which got rid of all the issues above, but I hit a new one instead! Maybe you're building on a newer system with 64-bit support?

configure: error: Oops, mp_limb_t is 32 bits, but the assembler code
in this configuration expects 64 bits.
You appear to have set $CFLAGS, perhaps you also need to tell GMP the
intended ABI, see "ABI and ISA" in the manual.
*** Error during phase configure of gmplib: ########## Error running ./configure --prefix /Users/osx/gtk/inst --libdir '/Users/osx/gtk/inst/lib'    *** [71/97]

Which I have worked around by running configure with:

ABI=32 ./configure ...

@smo: please confirm, apply and/or close.


Thu, 17 Sep 2015 17:58:22 GMT - Smo:

My build system is still 32bit so I will have to conform this. If I add that environment variable we will have to make note of it or it will break on 64 bit builds which we are working towards.


Fri, 18 Sep 2015 04:54:45 GMT - Antoine Martin:

@smo: maybe we can stick this in jhbuildrc-custom somewhere? or run configure like this:

ABI=`python -c 'import struct;print( 8 * struct.calcsize("P"))'` ./configure ...

This will give 32 or 64 depending on the architecture python is built for.


Thu, 24 Sep 2015 21:34:19 GMT - Smo:

Yes this can be added.

I'm going to do some updates from the upstream osx jhbuild stable moduleset before I continue with this.

Next is to get an environment for myself to build this 64bit stuff so I can work on these errors and bring 64bit up to par.


Thu, 24 Sep 2015 22:00:02 GMT - Smo:

Updates in r10674

I kept back gmp-6.0.0 which we had upgraded some time back but I noticed again that the stable-moduleset upstream uses gmp 4.3.2 and a few patches.

I would think having the newer version would be better and has worked for us?

Maybe there is something I don't know.


Fri, 25 Sep 2015 09:37:35 GMT - Antoine Martin:

Yes, we do want the latest gmp, 4.3.2 is way too old for such a critical low level library.


Thu, 08 Oct 2015 22:07:37 GMT - Smo:

I can't reproduce the issue with gmp that you were seeing I see this from configure

checking ABI=32
checking whether /usr/bin/gcc-4.2 is gcc... yes
checking compiler /usr/bin/gcc-4.2 -arch i386 -I/Developer/SDKs/MacOSX10.5.sdk/usr/include -arch i386 -I/Developer/SDKs/MacOSX10.5.sdk/usr/include
 -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -I/Users/sp
ikesinc/gtk/inst/include -arch i386 -I/Developer/SDKs/MacOSX10.5.sdk/usr/include -I/Users/osx/gtk/inst/include -arch i386 -I/Developer/SDKs/
MacOSX10.5.sdk/usr/include -isysroot /Developer/SDKs/MacOSX10.5.sdk -isysroot /Developer/SDKs/MacOSX10.5.sdk... yes
checking compiler /usr/bin/gcc-4.2 -arch i386 -I/Developer/SDKs/MacOSX10.5.sdk/usr/include -arch i386 -I/Developer/SDKs/MacOSX10.5.sdk/usr/include
 -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 has sizeof(
long)==4... yes
checking for gcc... /usr/bin/gcc-4.2
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether /usr/bin/gcc-4.2 accepts -g... yes
checking for /usr/bin/gcc-4.2 option to accept ISO C89... none needed
checking for /usr/bin/gcc-4.2 option to accept ISO C99... -std=gnu99
checking for /usr/bin/gcc-4.2 -std=gnu99 option to accept ISO Standard C... (cached) -std=gnu99
checking how to run the C preprocessor... /usr/bin/gcc-4.2 -std=gnu99 -E
checking build system compiler /usr/bin/gcc-4.2 -std=gnu99... yes
checking for build system preprocessor... /usr/bin/gcc-4.2 -std=gnu99 -E
checking for build system executable suffix...
checking whether build system compiler is ANSI... yes
checking for build system compiler math library... -lm
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking if the assembler knows about MMX instructions... yes
checking if the assembler knows about SSE2 instructions... yes
using ABI="32"
      CC="/usr/bin/gcc-4.2 -std=gnu99"
      CFLAGS="-arch i386 -I/Developer/SDKs/MacOSX10.5.sdk/usr/include -arch i386 -I/Developer/SDKs/MacOSX10.5.sdk/usr/include -isysroot /Developer
/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5"

Is it possible because I am doing this on hardware and you are on a VM?

If it doesn't hurt anything I will add comment:5 to the configure line in the moduleset


Tue, 27 Oct 2015 21:28:46 GMT - Smo:

I tried adding this to gmplib in our moduleset but it has issues parsing it. We are able to add os.environ["ABI"] = "32" in .jhbuildrc-custom will that be enough to fix it?


Wed, 28 Oct 2015 02:56:04 GMT - Antoine Martin:

Works:

rm -fr ~/gtk/source/gmp*
echo 'os.environ["ABI"] = "32"' >> .jhbuildrc-custom
export PATH=$PATH:~/.local/bin/
jhbuild buildone -f gmplib

Now rebuilding everything with jhbuild -f just to make sure this doesn't break anything else.


Thu, 29 Oct 2015 18:27:55 GMT - Smo: status changed; resolution set

I also tested something similar with no issues. Closing this for now.


Sat, 23 Jan 2021 05:11:14 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/971