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

Attachment: signature.asc
Description: Digital signature

_______________________________________________
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Reply via email to