pd-zexy compilation improvements

Sun Aug 22 18:06:35 UTC 2010

Hi IOhannes,

On Fri, Aug 20, 2010 at 10:09:22PM +0200, IOhannes m zmölnig wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1

Please quote only relevant parts.  PGP signing hints are never relevant 
to quote.

>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).

Indeed this looks weird.  If you consider it sane to use this approach 
then I guess it won't matter much.  But striving towards the ultimate, 
if this is a dirty hack then please elaborate on possible alternative 
approaches - even if tricky to achieve: others here might have ideas on 
how to reach a higher level of elegantry (or however that word is bent).

>> 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"

Hmm - if only those warning affect some printf I guess it can't ever 
wreak havoc and we should simply ignore them.

If not then I hope others here with actual skills in coding C (not just 
looking at compiler warnings like I comprehend) will join this 
conversation :-)

>> 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.

Excellent (to me - I like autotools!).

>> 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)

This is bad! - i.e. I Am The Policy Police ;-)

We should not wait until someone gets hurt by pd-sexy not working on 
e.g. VIA boards *and* figure out the cause of the problem *and* file a 
bugreport about it.

We should simply suppress the sse flag on 32bit x86, in my opinion.

Or if it really hurts, we should either a) offer to variants or b) 
convince upstream to implement support for both and detect at runtime if 
optimized code whould be used or not.

I notice that upstream intend to switch to autotools for next release.  
Perhaps you could convince upstream to add an option to add e.g. a 
--no-optimize or --no-buildtime-featuredetect flag so we can ensure 
compatibility generally for the archs we target - or if not too much to 
ask then above described runtime detection?

>> 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

Do others have more knowledge about this than me?

I suspect that it is not enough to simply test if -fPIC flag works - 
that it is more complicated than that, and more of a "Debian has decided 
to do it like this" rather than "this technically will certainly fail".

Kind regards,

 - Jonas

-- 
  * Jonas Smedegaard - idealist & Internet-arkitekt
  * Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20100822/e30c34fe/attachment.pgp>