Re: pd-zexy compilation improvements
On 29/08/10 17:50, Hans-Christoph Steiner wrote: > On Sun, 2010-08-29 at 21:35 +0200, Roman Haefeli wrote: >> On Sun, 2010-08-29 at 14:44 -0400, Hans-Christoph Steiner wrote: >> Also it seems as if dh_shlibdeps looks only for .so-files. I haven't figured out what trickery was used in the gem package to let it find also .pd_linux-files. But having a plain .pd-linux file in the temporary directory and running dh_shlibdeps doesn't produce anything useful. >>> >>> You can also check out debian/rules in pd-motex and pd-pmpd. It passes >>> the names of the .pd_linux files to dh_shlibdeps. >> >> >> Actually, you're not passing the file names to dh_shlibdeps, but >> directly to dpkg-shlibdeps. >> According to 4.4.3 of Debian's new maintainer's guide [1] the >> recommended way would be to pass customized arguments to the debhelper >> tools after " -- ", so that they get passed to the respective dpkg tools >> (or whatever the dh_tool is a wrapper for). >> >> However, this does not seem to work here for some reason. >> >> $ dpkg-shlibdeps /.pd_linux >> >> actually creates a reasonable debian/substvars file. >> >> $ dh_shlibdeps -- /.pd_linux >> >> which is supposed to do exactly the same (according to the >> documentation) does not seem to find a file to check for libraries. >> >> So, I guess "dh_shlibdeps -- " is not passing _all_ arguments to >> dpkg-shlibdeps? My perl skills are too limited to investigate the reason >> for this behaviour myself. >> >> Since the recommended way is not working, I guess it is OK to call >> dpkg-shlibdeps directly in the pd-packages (as you, Hans, did in >> pd-motex and pd-pmpd)? Or what do you (all) think?\ > > That sounds very familiar. I think I tried dh_shlibdeps first also, and > then went with dpkg-shlibdeps for that reason. > Ah, yes, there is bug #35733 about it. I've pinged the bug report. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: pd-zexy compilation improvements
On Sun, 2010-08-29 at 21:35 +0200, Roman Haefeli wrote: > On Sun, 2010-08-29 at 14:44 -0400, Hans-Christoph Steiner wrote: > > > > > > > Also it seems as if dh_shlibdeps looks only for .so-files. I haven't > > > figured out what trickery was used in the gem package to let it find > > > also .pd_linux-files. But having a plain .pd-linux file in the temporary > > > directory and running dh_shlibdeps doesn't produce anything useful. > > > > You can also check out debian/rules in pd-motex and pd-pmpd. It passes > > the names of the .pd_linux files to dh_shlibdeps. > > > Actually, you're not passing the file names to dh_shlibdeps, but > directly to dpkg-shlibdeps. > According to 4.4.3 of Debian's new maintainer's guide [1] the > recommended way would be to pass customized arguments to the debhelper > tools after " -- ", so that they get passed to the respective dpkg tools > (or whatever the dh_tool is a wrapper for). > > However, this does not seem to work here for some reason. > > $ dpkg-shlibdeps /.pd_linux > > actually creates a reasonable debian/substvars file. > > $ dh_shlibdeps -- /.pd_linux > > which is supposed to do exactly the same (according to the > documentation) does not seem to find a file to check for libraries. > > So, I guess "dh_shlibdeps -- " is not passing _all_ arguments to > dpkg-shlibdeps? My perl skills are too limited to investigate the reason > for this behaviour myself. > > Since the recommended way is not working, I guess it is OK to call > dpkg-shlibdeps directly in the pd-packages (as you, Hans, did in > pd-motex and pd-pmpd)? Or what do you (all) think?\ That sounds very familiar. I think I tried dh_shlibdeps first also, and then went with dpkg-shlibdeps for that reason. .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: pd-zexy compilation improvements
On Sun, 2010-08-29 at 14:44 -0400, Hans-Christoph Steiner wrote: > > > > Also it seems as if dh_shlibdeps looks only for .so-files. I haven't > > figured out what trickery was used in the gem package to let it find > > also .pd_linux-files. But having a plain .pd-linux file in the temporary > > directory and running dh_shlibdeps doesn't produce anything useful. > > You can also check out debian/rules in pd-motex and pd-pmpd. It passes > the names of the .pd_linux files to dh_shlibdeps. Actually, you're not passing the file names to dh_shlibdeps, but directly to dpkg-shlibdeps. According to 4.4.3 of Debian's new maintainer's guide [1] the recommended way would be to pass customized arguments to the debhelper tools after " -- ", so that they get passed to the respective dpkg tools (or whatever the dh_tool is a wrapper for). However, this does not seem to work here for some reason. $ dpkg-shlibdeps /.pd_linux actually creates a reasonable debian/substvars file. $ dh_shlibdeps -- /.pd_linux which is supposed to do exactly the same (according to the documentation) does not seem to find a file to check for libraries. So, I guess "dh_shlibdeps -- " is not passing _all_ arguments to dpkg-shlibdeps? My perl skills are too limited to investigate the reason for this behaviour myself. Since the recommended way is not working, I guess it is OK to call dpkg-shlibdeps directly in the pd-packages (as you, Hans, did in pd-motex and pd-pmpd)? Or what do you (all) think? Roman [1] http://www.debian.org/doc/maint-guide/ch-dreq.en.html#s-customrules ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: pd-zexy compilation improvements
On Sat, 2010-08-28 at 00:18 +0200, Roman Haefeli wrote: > On Fri, 2010-08-27 at 12:11 +0200, IOhannes zmölnig wrote: > > On 08/24/2010 12:55 PM, Jonas Smedegaard wrote: > > > On Mon, Aug 23, 2010 at 09:25:12AM +0200, IOhannes m zmoelnig wrote: > > > > > Hmm. Do we then perhaps need to beware of this for helper tools like > > > lintian and dh_shlibdeps? > > > > > > the other point is of course, whether tools like dh_shlibdeps and > > dh_strip work correctly. > > i can only say from experience, that they do. > > e.g. the binary Gem.pd_linux in the package "gem" is correctly stripped > > and the package depends on all packages that provide libraries the > > binary has been dynamically linked to. > > debian/rules does not extra care of shlibs. > > so it seems to "just work" > > It seems it's not dh_strip who does the stripping. In the case of the > gem package it seems to happen already at compile time. After putting an > unstripped Gem.pd_linux in the temporary directory running dh_strip > won't touch it all. > > Also it seems as if dh_shlibdeps looks only for .so-files. I haven't > figured out what trickery was used in the gem package to let it find > also .pd_linux-files. But having a plain .pd-linux file in the temporary > directory and running dh_shlibdeps doesn't produce anything useful. You can also check out debian/rules in pd-motex and pd-pmpd. It passes the names of the .pd_linux files to dh_shlibdeps. .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: pd-zexy compilation improvements
On Fri, 2010-08-27 at 19:24 -0400, Felipe Sateler wrote: > On 27/08/10 18:18, Roman Haefeli wrote: > > On Fri, 2010-08-27 at 12:11 +0200, IOhannes zmölnig wrote: > >> On 08/24/2010 12:55 PM, Jonas Smedegaard wrote: > >>> On Mon, Aug 23, 2010 at 09:25:12AM +0200, IOhannes m zmoelnig wrote: > >> > >>> Hmm. Do we then perhaps need to beware of this for helper tools like > >>> lintian and dh_shlibdeps? > >>> > > > >> the other point is of course, whether tools like dh_shlibdeps and > >> dh_strip work correctly. > >> i can only say from experience, that they do. > >> e.g. the binary Gem.pd_linux in the package "gem" is correctly stripped > >> and the package depends on all packages that provide libraries the > >> binary has been dynamically linked to. > >> debian/rules does not extra care of shlibs. > >> so it seems to "just work" > > > > It seems it's not dh_strip who does the stripping. In the case of the > > gem package it seems to happen already at compile time. After putting an > > unstripped Gem.pd_linux in the temporary directory running dh_strip > > won't touch it all. > > dh_strip doesn't strip anything it doesn't recognize (and it has no way > of being forced into it). Add comments to bug #468333 to ask for support > for this. Thanks for confirming. > In the meantime, you can call > > strip --remove-section=.comment --remove-section=.note --strip-unneeded > > on each of the pd_linux files. Ok. > > Also it seems as if dh_shlibdeps looks only for .so-files. I haven't > > figured out what trickery was used in the gem package to let it find > > also .pd_linux-files. But having a plain .pd-linux file in the temporary > > directory and running dh_shlibdeps doesn't produce anything useful. > > You can pass additional arguments for dh_shlibdeps to process: > > dh_shlibdeps -- $file1 $file2 Ah, so easy. Thanks for the hint. Roman ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: pd-zexy compilation improvements
On 27/08/10 18:18, Roman Haefeli wrote: > On Fri, 2010-08-27 at 12:11 +0200, IOhannes zmölnig wrote: >> On 08/24/2010 12:55 PM, Jonas Smedegaard wrote: >>> On Mon, Aug 23, 2010 at 09:25:12AM +0200, IOhannes m zmoelnig wrote: >> >>> Hmm. Do we then perhaps need to beware of this for helper tools like >>> lintian and dh_shlibdeps? >>> > >> the other point is of course, whether tools like dh_shlibdeps and >> dh_strip work correctly. >> i can only say from experience, that they do. >> e.g. the binary Gem.pd_linux in the package "gem" is correctly stripped >> and the package depends on all packages that provide libraries the >> binary has been dynamically linked to. >> debian/rules does not extra care of shlibs. >> so it seems to "just work" > > It seems it's not dh_strip who does the stripping. In the case of the > gem package it seems to happen already at compile time. After putting an > unstripped Gem.pd_linux in the temporary directory running dh_strip > won't touch it all. dh_strip doesn't strip anything it doesn't recognize (and it has no way of being forced into it). Add comments to bug #468333 to ask for support for this. In the meantime, you can call strip --remove-section=.comment --remove-section=.note --strip-unneeded on each of the pd_linux files. > > Also it seems as if dh_shlibdeps looks only for .so-files. I haven't > figured out what trickery was used in the gem package to let it find > also .pd_linux-files. But having a plain .pd-linux file in the temporary > directory and running dh_shlibdeps doesn't produce anything useful. You can pass additional arguments for dh_shlibdeps to process: dh_shlibdeps -- $file1 $file2 -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: pd-zexy compilation improvements
On Fri, Aug 27, 2010 at 12:11:16PM +0200, IOhannes zmölnig wrote: On 08/24/2010 12:55 PM, Jonas Smedegaard wrote: On Mon, Aug 23, 2010 at 09:25:12AM +0200, IOhannes m zmoelnig wrote: Hmm. Do we then perhaps need to beware of this for helper tools like lintian and dh_shlibdeps? I actually do not think that dh_shlibdeps has any role here, just mentioning it as an example: For Debian packaging we have a bunch of helper tools used either directly during packaging or during various tests and inspections, which rely on e.g. shared libraries ending in .so and located below /usr/lib. When then unusual things are done, we might want to add hints for such tools to not hide potential problems from them. Or expressed differently: Even if PureData works splendid with its unusual naming, we still might benefit in Debian (and derivatives) from using the classic .so extension if indeed it is technically the same. i think there is no issue here at all. we are talking about "modules" (binaries that can be dlopen()ed). dlopen()ed modules are technically quite the same as shlibs (meaning, the way they are built), but are used in a different way, that makes issues such as installation path and/or rpath irrelevant (at least, as far as i understand it) so from this perspective, we don't have to care about the extension. (i guess this came from my confusing use of "shared library"; sorry for that; anyhow, debian-policy is quite clear that "modules" need not have an .so extension) the other point is of course, whether tools like dh_shlibdeps and dh_strip work correctly. i can only say from experience, that they do. e.g. the binary Gem.pd_linux in the package "gem" is correctly stripped and the package depends on all packages that provide libraries the binary has been dynamically linked to. debian/rules does not extra care of shlibs. so it seems to "just work" i think that changing the default extension of pd-plugins only in Debian, will make things unnecessary complicated, as it would require to patch the module-loader of puredata as well as practically every single build system for externals, only to find ourselves deviant from and incompatible with virtually any other puredata distribution. to sum up, i don't think the gain would outweigh the cost. (esp. since there is currently no real gain, as adhere to the debian-policy and all tools work as expected) Thanks for the long explanation. I am thrilled to be around such knowledgeable folks here! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private 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
Re: pd-zexy compilation improvements
On Fri, 2010-08-27 at 12:11 +0200, IOhannes zmölnig wrote: > On 08/24/2010 12:55 PM, Jonas Smedegaard wrote: > > On Mon, Aug 23, 2010 at 09:25:12AM +0200, IOhannes m zmoelnig wrote: > > > Hmm. Do we then perhaps need to beware of this for helper tools like > > lintian and dh_shlibdeps? > > > the other point is of course, whether tools like dh_shlibdeps and > dh_strip work correctly. > i can only say from experience, that they do. > e.g. the binary Gem.pd_linux in the package "gem" is correctly stripped > and the package depends on all packages that provide libraries the > binary has been dynamically linked to. > debian/rules does not extra care of shlibs. > so it seems to "just work" It seems it's not dh_strip who does the stripping. In the case of the gem package it seems to happen already at compile time. After putting an unstripped Gem.pd_linux in the temporary directory running dh_strip won't touch it all. Also it seems as if dh_shlibdeps looks only for .so-files. I haven't figured out what trickery was used in the gem package to let it find also .pd_linux-files. But having a plain .pd-linux file in the temporary directory and running dh_shlibdeps doesn't produce anything useful. Roman ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: pd-zexy compilation improvements
On 08/24/2010 12:55 PM, Jonas Smedegaard wrote: > On Mon, Aug 23, 2010 at 09:25:12AM +0200, IOhannes m zmoelnig wrote: > Hmm. Do we then perhaps need to beware of this for helper tools like > lintian and dh_shlibdeps? > > I actually do not think that dh_shlibdeps has any role here, just > mentioning it as an example: For Debian packaging we have a bunch of > helper tools used either directly during packaging or during various > tests and inspections, which rely on e.g. shared libraries ending in .so > and located below /usr/lib. When then unusual things are done, we might > want to add hints for such tools to not hide potential problems from them. > > Or expressed differently: Even if PureData works splendid with its > unusual naming, we still might benefit in Debian (and derivatives) from > using the classic .so extension if indeed it is technically the same. i think there is no issue here at all. we are talking about "modules" (binaries that can be dlopen()ed). dlopen()ed modules are technically quite the same as shlibs (meaning, the way they are built), but are used in a different way, that makes issues such as installation path and/or rpath irrelevant (at least, as far as i understand it) so from this perspective, we don't have to care about the extension. (i guess this came from my confusing use of "shared library"; sorry for that; anyhow, debian-policy is quite clear that "modules" need not have an .so extension) the other point is of course, whether tools like dh_shlibdeps and dh_strip work correctly. i can only say from experience, that they do. e.g. the binary Gem.pd_linux in the package "gem" is correctly stripped and the package depends on all packages that provide libraries the binary has been dynamically linked to. debian/rules does not extra care of shlibs. so it seems to "just work" i think that changing the default extension of pd-plugins only in Debian, will make things unnecessary complicated, as it would require to patch the module-loader of puredata as well as practically every single build system for externals, only to find ourselves deviant from and incompatible with virtually any other puredata distribution. to sum up, i don't think the gain would outweigh the cost. (esp. since there is currently no real gain, as adhere to the debian-policy and all tools work as expected) fmgdft IOhannes signature.asc Description: OpenPGP digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: pd-zexy compilation improvements
On Mon, Aug 23, 2010 at 09:25:12AM +0200, IOhannes m zmoelnig wrote: On 2010-08-22 20:06, Jonas Smedegaard wrote: 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). it's certainly in sync with the current puredata package in debian; the relevant patches (using the pd_linux extension for debian/hurd and debian/kFreeBSD) have even made it into upstream of puredata other pkgs usually use ".so" as extension, which Pd for historical reasons does not, and instead uses it's own extension (varying across platforms). Hmm. Do we then perhaps need to beware of this for helper tools like lintian and dh_shlibdeps? I actually do not think that dh_shlibdeps has any role here, just mentioning it as an example: For Debian packaging we have a bunch of helper tools used either directly during packaging or during various tests and inspections, which rely on e.g. shared libraries ending in .so and located below /usr/lib. When then unusual things are done, we might want to add hints for such tools to not hide potential problems from them. Or expressed differently: Even if PureData works splendid with its unusual naming, we still might benefit in Debian (and derivatives) from using the classic .so extension if indeed it is technically the same. One example issue we could be hiding is that of rpath usage: Everything works fine but Debian set higher standards than "works fine for *normal* use" and lintian checks was added at some point to warn if rpath was used in shared libraries. Again, I do not say that rpath in particular is my concern - it is but an example: Could be some other similarly "pedantic" issue raised later, which none of us today know about, but will remain hidden if we use odd naming for a common file type. 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? this sounds a bit ironic, but i miss the smiley, so i guess it's not. It is not: I know Make, Perl, Bash, love regular expressions, and can juggle patches. But cannot do a helloworld in C or C++. It takes more than a smiley to change that :-) NB! Please do not cc me - I am subscribed, and it messes up my MUA. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private 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
Re: pd-zexy compilation improvements
On Mon, Aug 23, 2010 at 10:32:55AM +0200, IOhannes m zmoelnig wrote: On 2010-08-23 09:58, Reinhard Tartler wrote: If they are indeed in non-standard paths such that the dynamic linker doesn't see it without setting LD_LIBRARY_PATH or similar, then you're right. But.. nevertheless, it complies with it... even on amd64? There are some architectures that are pretty picky about position independent code. BTW that's why there is this rule in debian policy in the first place. pd-zexy compiles everything with "-fPIC" an ALL (including amd64) platforms[1]. the discussion arose, because jonas wanted it to be compiled withOUT -fPIC (which is in contradiction to the debian policy afaict) do i get something wrong? No - I had it upside down. Lucky you are upstream, not me, as it seems you actually know what you are talking about ;-) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private 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
Re: pd-zexy compilation improvements
On Mon, Aug 23, 2010 at 10:32:55 (CEST), IOhannes m zmoelnig wrote: > On 2010-08-23 09:58, Reinhard Tartler wrote: > >> If they are indeed in non-standard paths such that the dynamic linker >> doesn't see it without setting LD_LIBRARY_PATH or similar, then you're >> right. But.. >> >>> nevertheless, it complies with it... >> >> even on amd64? There are some architectures that are pretty picky about >> position independent code. BTW that's why there is this rule in debian >> policy in the first place. >> > > pd-zexy compiles everything with "-fPIC" an ALL (including amd64) > platforms[1]. > the discussion arose, because jonas wanted it to be compiled withOUT > -fPIC (which is in contradiction to the debian policy afaict) > > do i get something wrong? no, it was me who got it wrong. Leaving out -fPIC is not a clever idea without really understanding what's going on. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: pd-zexy compilation improvements
On 2010-08-23 09:58, Reinhard Tartler wrote: > If they are indeed in non-standard paths such that the dynamic linker > doesn't see it without setting LD_LIBRARY_PATH or similar, then you're > right. But.. > >> nevertheless, it complies with it... > > even on amd64? There are some architectures that are pretty picky about > position independent code. BTW that's why there is this rule in debian > policy in the first place. > pd-zexy compiles everything with "-fPIC" an ALL (including amd64) platforms[1]. the discussion arose, because jonas wanted it to be compiled withOUT -fPIC (which is in contradiction to the debian policy afaict) do i get something wrong? fgmasdr IOhannes [1] where the compiler accepts the -fPIC flag. smime.p7s Description: S/MIME Cryptographic Signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: pd-zexy compilation improvements
On Mon, Aug 23, 2010 at 09:35:24 (CEST), IOhannes m zmoelnig wrote: > On 2010-08-22 20:06, Jonas Smedegaard wrote: >> >> 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? > > > i thought it was there, but cannot find it anymore :-) (probably it's in > some other lib of mine) > > as things stand now, pd-zexy has no runtime cpu-detection support, so > the best bet is to completely disable the SSE2 code. For now, I agree that would be best. There are some workarounds for that, though. > for future refernce i would like to ask (and i'm aware, that this is not > the perfect place to ask such a question): > > the relevant flags are "-mfpmath=sse -msse" which do 2 things: > - set some macros to allow the user add handcrafted sse-code > - use sse optimization > > now #1 is clearly a problem, if the program is forced to use handwritten > sse code (including sse instructions) if there is no sse unit available. > this can be fixed with runtime checks. > > my question is more about the other possibility: > #2 makes gcc emit sse-instructions; does anybody know whether it also > automatically provides fallbacks for generic 486 instructions? > or is any code compiled with "-mfpmath=sse -msse" known (or likely) to > be incompatible with non-sse cpus? No, gcc doesn't support this (yet [1]). But *if* all code that is using SSE is implemented as shared libraries (i.e., .so files and loaded via ld-linux.so, I didn't check that though) then you could compile and install different flavors of the library, one time with and one time without SSE instructions. The dynamic loader will then at runtime query the kernel for installed harware capabilities and load the "best" flavor on demand. See the libavcodec52 package as an example. [1] You might want to google on 'gcc binutils multiarch' for details; it is a rather new development with an unfortunate naming, since it clashes with debian's "multiarch" project which is related but with different aims. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: pd-zexy compilation improvements
On Mon, Aug 23, 2010 at 09:38:42 (CEST), IOhannes m zmoelnig wrote: > On 2010-08-23 09:25, IOhannes m zmoelnig wrote: >> On 2010-08-22 20:06, Jonas Smedegaard wrote: >> >> anyhow, i had a look at the debian policy, and it says (in chapter 10.2 >> Libraries on todays http://www.debian.org/doc/debian-policy/ch-files.html): >> "If the package is architecture: any, then the shared library >> compilation and linking flags must have -fPIC, or the package shall not >> build on some of the supported architectures". > > reading on, i also noticed: > "Shared object files (often .so files) that are not public libraries, > that is, they are not meant to be linked to by third party executables > (binaries of other packages), should be installed in subdirectories of > the /usr/lib directory. Such files are exempt from the rules that govern > ordinary shared libraries, except that they must not be installed > executable and should be stripped [A common example are the so-called > "plug-ins", internal shared objects that are dynamically loaded by > programs using dlopen(3).]" > > i understand this as the "-fPIC" rule actually doesn't apply at all to > Pd-externals. If they are indeed in non-standard paths such that the dynamic linker doesn't see it without setting LD_LIBRARY_PATH or similar, then you're right. But.. > nevertheless, it complies with it... even on amd64? There are some architectures that are pretty picky about position independent code. BTW that's why there is this rule in debian policy in the first place. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: pd-zexy compilation improvements
On 2010-08-23 09:25, IOhannes m zmoelnig wrote: > On 2010-08-22 20:06, Jonas Smedegaard wrote: > > anyhow, i had a look at the debian policy, and it says (in chapter 10.2 > Libraries on todays http://www.debian.org/doc/debian-policy/ch-files.html): > "If the package is architecture: any, then the shared library > compilation and linking flags must have -fPIC, or the package shall not > build on some of the supported architectures". reading on, i also noticed: "Shared object files (often .so files) that are not public libraries, that is, they are not meant to be linked to by third party executables (binaries of other packages), should be installed in subdirectories of the /usr/lib directory. Such files are exempt from the rules that govern ordinary shared libraries, except that they must not be installed executable and should be stripped [A common example are the so-called "plug-ins", internal shared objects that are dynamically loaded by programs using dlopen(3).]" i understand this as the "-fPIC" rule actually doesn't apply at all to Pd-externals. nevertheless, it complies with it... fbmasdr IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: pd-zexy compilation improvements
On 2010-08-22 20:06, Jonas Smedegaard wrote: > > 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? i thought it was there, but cannot find it anymore :-) (probably it's in some other lib of mine) as things stand now, pd-zexy has no runtime cpu-detection support, so the best bet is to completely disable the SSE2 code. for future refernce i would like to ask (and i'm aware, that this is not the perfect place to ask such a question): the relevant flags are "-mfpmath=sse -msse" which do 2 things: - set some macros to allow the user add handcrafted sse-code - use sse optimization now #1 is clearly a problem, if the program is forced to use handwritten sse code (including sse instructions) if there is no sse unit available. this can be fixed with runtime checks. my question is more about the other possibility: #2 makes gcc emit sse-instructions; does anybody know whether it also automatically provides fallbacks for generic 486 instructions? or is any code compiled with "-mfpmath=sse -msse" known (or likely) to be incompatible with non-sse cpus? fmasdr IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: pd-zexy compilation improvements
On 2010-08-22 20:06, Jonas Smedegaard wrote: > > 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). > it's certainly in sync with the current puredata package in debian; the relevant patches (using the pd_linux extension for debian/hurd and debian/kFreeBSD) have even made it into upstream of puredata other pkgs usually use ".so" as extension, which Pd for historical reasons does not, and instead uses it's own extension (varying across platforms). >> 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 ;-) > somehow i expected this :-) > 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. no problem. > > 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? btw, upstream already uses a autoconf (with loads of m4 hacks...); the intention is to switch to automake as well and get rid of the tweaks... >>> 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? this sounds a bit ironic, but i miss the smiley, so i guess it's not. > > 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". > i can only say that i know that all externals will fail to link on x86_64 if the -fPIC flag is not present. anyhow, i had a look at the debian policy, and it says (in chapter 10.2 Libraries on todays http://www.debian.org/doc/debian-policy/ch-files.html): "If the package is architecture: any, then the shared library compilation and linking flags must have -fPIC, or the package shall not build on some of the supported architectures". this seems to be exactly the opposite of what you suggest, as shared libraries (and modules that are meant to be dlopen()ed _are_ shared libraries) MUST have the "-fPIC" present. i prefer if the build system tests, whether the compiler actually accepts "-fPIC", just in case somebody uses an exotic compiler. fmhsd IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: pd-zexy compilation improvements
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
