Re: [Jackit-devel] Re: RFC: EXP merge of OSX portability work
Robert Joerdens <rjo-lists@gmx.de> writes:
> Make dist doesn't work from a fresh checkout/autogen.sh:
>
> * depcomp is missing in CVS in config/ AFAICS
> * files/links seem to be missing for the config includes. make dist
> fails from a fresh checkout
...
> it works after building it in the cvs checkout dir and then doing make
> dist.
I always run `make' before `make dist' or `make distcheck'. I do that
to ensure that all distributed files are up-to-date. This is what the
"Goat Book" (_GNU Autoconf, Automake, and Libtool_) recommends.
Is that a problem for Debian packaging? Normally, we provide the
`*.orig.tar.gz' file. This is mainly an issue of building from CVS.
> * Debian has i386 as an (the?) architecture for all intel i386 and
> upwards. But OTOH not really because libstdc++ already needs the
> presence of i486 instructions. I had to force config/configure.host to
> use i486 as architecture for i386. The diff contains the patch.
This code is based on libstdc++v3. It inherits that same limitation,
which affects <atomicity.h>. The i386 version of exchange_and_add()
has a built-in spin lock, which is undesirable for JACK.
We could cheat and pretend that i386 really means i486. I see that's
what you did. I doubt anyone wants to run JACK on a real 386 anymore.
--- config/configure.host 16 Feb 2004 16:07:25 -0000 1.1.2.5
+++ config/configure.host 23 Mar 2004 17:43:40 -0000
@@ -69,7 +69,7 @@
alpha*)
try_cpu=alpha
;;
- i[567]86 | x86_64)
+ i[3567]86 | x86_64)
try_cpu=i486
;;
hppa*)
I'll commit this patch and the one below as 0.195.16. If we do this,
I guess I could delete the cpu/i386 directory, entirely. But, I'll
wait a while before doing anything like that.
The 0.195.x version is a hack to keep it distinct from the current CVS
HEAD. If we go ahead with this merge, it will become 0.96.0.
> * An idea of the Debian packages is here:
> http://people.debian.org/~jordens/debs/
Cool! So it *can* be packaged if you kick the tires a bit. ;-)
> * I'm trying it on a few architectures I can get my hands on.
> powerpc, sparc, seem fine. ia64, s390 get detected as generic which is a
> regression IIRC.
What does config.guess return for those two? I suspect the CPU names
are `ia64' and `s390'. Looks like there's a bug in my configure.host
logic, (libstdc++ runs that script in a different directory).
Here's the fix...
--- config/configure.host 16 Feb 2004 16:07:25 -0000 1.1.2.5
+++ config/configure.host 23 Mar 2004 17:18:54 -0000
@@ -95,7 +95,7 @@
try_cpu=sparc
;;
*)
- if test -d cpu/${host_cpu}; then
+ if test -d $srcdir/config/cpu/${host_cpu}; then
try_cpu=${host_cpu}
else
try_cpu=generic
> * the generic atomicity implementation seems to be broken. I didn't look
> into this further:
OK, I should be able to debug that on my Athlon box.
BTW, I know that os/generic/time.h is currently broken, but it should
not affect you. It *will* affect anyone building for IRIS or AIX. We
can fix them when the need arises.
I appreciate the help, Robert. You and Guenter and Ralph Giles
provided valuable and timely assistance. There were fewer problems
than I had expected so far, considering the number of untested
platforms involved. The GCC folks did a good job on this.
Many thanks to you all,
--
joq
Reply to: