pd-zexy (upstream copyright)

[IOhannes m zmölnig]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/20/2010 12:41 PM, Jonas Smedegaard wrote:
> I finalized the packaging and uploaded to the NEW queue, where it is now
> waiting for ftpmasters to (hopefully) approve it.

cool.
i noticed that up till now, it has built everywhere but
- - linux/mips (scheduled)
- - hurd (scheduled)
- - kfreebsd (failed)


i expect the hurd build to fail as well, due to the same problem as the
kfreebsd builds: the filename extension for the external (module) is not
correctly autoguessed.

this can be easily fixed, by forcing a certain extension via configure
flags (which i have just pushed).
the "puredata" package uses the "pd_linux" extension for all externals
on Debian, so i just used that (even though it might seem uncorrect to
use the "linux" extension on a hurd or freebsd kernel).


> 
> 
> There are a few warnings like this:
> 
>   rawprint.c:45: warning: format '%X' expects type 'unsigned int', but
> argument 4 has type 'struct t_gpointer *'

i never really understood what to use for pointers in fprintf.
anyhow, in the given function it is save to cast to uint, as it is only
for pretty printing...

> 
> This might cause problems on architectures where int is of "unusual"
> size, if I understand it correctly.

i think the problem is more on x86_64 where the pointer is has the same
size as "long int"

> 
> 
> Apparently the following compile options are used:
> 
>   -g -O2 -g -Wall -O2 -mms-bitfields -fPIC -mfpmath=sse -msse -g -O2 -g
> -Wall -O2
> 
> This indicates that default compile options in upstream source is not
> overridden by CFLAGS declared by packaging which is generally bad (and a
> Policy violation, I believe - but too lazy to look it up right now), and
> especially may hurt emdebian and similar andvanced users depending on
> being able to override CFLAGS during packaging build time.

aye.
i think upstream will be switching to autoconf/automake which should fix
that.

> 
> More specifically, the upstream defaults include sse which I believe
> makes the resulting code require an i586 or even an i686 class machine. 
> I did not look closer and this might simply be due to this compilation
> happening on amd64 which always has this instruction set.  Just
> mentioning in case upstream assumes newer grades x64: Debian assumes i486.

aye.
the configure script does a test whether the compiler supports the
sse-flags. i think this is the case with modern gcc on x86 regardless of
the cpu used, so this might become a problem.

honestly, in the meantime i would wait till somebody complains (either a
user or the policy police) or the policy changes...
the fix shouldn't be too complicated to do (needs a patch against
configure.ac however)

on other platforms (not x86 and x86_64) the flags should be no problems
(since they are not used)

> 
> Also, some archs have problems with fPIC, and I believe it is mentioned
> in Debian Policy that normal builds should *not* use fPIC while static
> libraries (unused here, just mentioning for completenes sake) *should*
> use it.
> 

the fPIC flag is tested for during configure time, and it's only used if
the compiler supports it.
it was introduced, because x86_64 does require it.
it can be turned off by using "--disable-PIC", though of course this has
to exclude x86_64



gmasdr
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxu4PEACgkQkX2Xpv6ydvTowwCeKY4fFuZQ9AabQbITCWQKd3/H
GjsAnilHytpPlrJAhj2c4yT0bT7ZSplp
=CtpI
-----END PGP SIGNATURE-----