[Slackbuilds-users] gcc flags for Slackware64 packages and SlackBuilds
rworkman at slackbuilds.org
Tue Oct 6 04:41:57 UTC 2009
On Mon, 5 Oct 2009 20:04:16 -0300
Niels Horn <niels.horn at gmail.com> wrote:
> Hi to all,
> I know the standard flags we put in SlackBuilds for Slackware 32-bits
> & 64-bits versions, but I have seen some "./configure" scripts
> including extra flags for the compiler like "-m64" or "-march=k8 /
> -mtune=k8" and even "-mtune=core2".
> The results work fine on my machine (with a Core2 processor), but
> should we avoid these in SlackBuilds or in pre-built packages?
> I browsed the gcc documentation but it did not give me a very clear
> For instance, if I use -m64 (thus changing the length of (int)), can
> this cause problems when using libraries not compiled with this flag?
> Or is "k8" completely compatible with "core2" and the other way
> Clarifications are welcome...
I'm not sure I can clarify anything on this subject, but here's a
I'd prefer not to see any "special" optimizations in our build
scripts (i.e. in the SLKCFLAGS="blah" lines) - that one's easy.
For apps that auto-add such flags, well, there's not an easy
answer. If they're easy to remove (e.g. running make like this:
make OPTS="$SLKCFLAGS" or make CFLAGS="$SLKCFLAGS"
then sure, let's do that so long as everything works fine that
way. In may cases, it won't, at least not without some creative
massaging. As an example, quite a few Makefiles have something
like this in them near the top:
Ideally, everyone would either hardcode the app-specific flags
in a separate variable and let packagers have CFLAGS, or else
declare no opt settings at all in CFLAGS and then provide an
OPT or OPTS variable for packagers to use. Of course, in an
ideal world, it wouldn't be an issue, would it? ;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: not available
More information about the SlackBuilds-users