hi
i was going through the files on disk4 and while reading the line build script for mpg321, i found this line:
CFLAGS="-O2 -march=i486 -mcpu=i686" ./configure --prefix=/usr i486-slackware-linux

is there a functional difference between i486 and i686 in the march flag? after reading about checkinstall, i've been using it and it has a section on architecture. it was i386, i've changed it to i686 in the conf. shouldn't that make a difference when compiling?

wrt the code above, how is the configure script running? i mean, it starts with a variable assignment. unless it's understood (by the shell) that the assignment has ended and ./configure --... is the next line/command. in which case, how does it differentiate between diff commands in the same lines and their arguments?

Multiple arguments with configure are usually done with the escape character \

Example: Type

./configure --enable-blah \
and then enter.... you will get a > on the next line, and you can enter the next argument.

As for the different architectures, my understanding is that it will only make a difference if the program is written with use of the extended functions of the i586 or i686 arch. It may also affect gcc, but of that I'm not certain.

slight

i'm aware of that. my question was directed towards that line of the shell script. and that it starts with a variable assignment-ish thing. line 26 of 'mpg321.SlackBuild' in /source/ap of slack9.1 disc4

Yes there is a difference. The '-march=' flag tells the compiler to build specifically for that CPU architecture, making it unusable for earlier CPU architectures. The allowable flags for the gcc-3.2.x are:

• i386
  i486
  i586
  i686
  pentium
  pentium-mmx
  pentiumpro
  pentium2
  pentium3
  pentium4
  k6
  k6-2
  k6-3
  athlon
  athlon-tbird
  athlon-4
  athlon-xp
  athlon-mp

There is a way to optimize the code when compiling for a specific CPU arch yet making it usable for earlier architectures by using the '-mcpu=' flag, instead. It uses the same CPU types listed above, but allows you to build packages for earlier CPU types while optimizing it mostly for the type specified by the '-mcpu=' flag. Specifying these flags can make a noticable difference in the speed of the binary.

When using the '-march=' flag you can specify an architecture that is earlier than the one you are currently using, due to backward compatibility of the CPU. You cannot use a binary built for a later arch type than what you currently are running without issues.

Both flags, '-march=' and 'mcpu=', can be used at the same time to optimize for a certain CPU arch, while making it compatible for earlier architectures. For example, I use '-march=i586' and '-mcpu=athlon' when building my packages. This means the binaries in the package are optimized for the AMD Athlon processor (since I currently have an Athlon 900), yet it will still run fine on any Pentium/AMD machine, but not any pre-Pentium machine. (First generation Pentium chips are i586 chips, such as P75 or P100.)

Using several commands on the same line requires the use of a semi-colon ( ; ) to separate the commands. It doesn't matter if you have spaces before or after the semi-colon as the shell interpreter will ignore any white spaces (blank spaces, tabs, etc.). So the following examples are the same: You get the idea.

When defining a vaiable on the command line, that variable will be valid for a long as that shell is running. If you exit the shell and then start a new one, the variable data will be gone. Defining a variable doesn't count as a command on the command line, so there is no need to use a semi-colon after it if followed by other commands on the same line. But in order to not confuse it with a command's option, it is written before any commands on the same line. This also makes the variable available for the command being used, since it makes no sense to define the variable after issuing a command.

To make the data available for all shell sessions, you need to use the 'export' command, such as: Now you can open and close any number of shells and the variable $CFLAGS will still carry those values until the next reboot. To make it available between reboots without having to type the 'export' command by hand, you can put the command in your startup script, such as ~/.bashrc, or to make it available to everyone place the command in /etc/profile.

When using the 'export' command on the same line with other commands, you will need to separate the commands with the semi-colon. Using your line above, if 'export' was used in defining the variable you would need to write it like this: Arguments (options) always follow the command given, with each option usually separated by a space. For your line above, only two options, or arguments, are given: --prefix=/usr and i486-slackware-linux.

Here's a couple of links to follow, which may help make things clearer.

• Intel 386 and AMD x86-64 Options
  Safe flags to use for gentoo-1.4
  Index of all GCC options

The first links lists the availabe flags used by GCC for the Intel x86 (and compatible) architecture. The second is recommended variables for compiling in Gentoo, but are usable for other distros as well. The variables are used by the 'make' command, if they are valid, and not empty, variables. The last link lists all the options currently supported by GCC.

NOTE: In the Gentoo link, 'CHOST' is the target machine being compiled on and is equivalent to the second './configure' option, i486-slackware-linux.

Hope that helps


---------------------------------------------------------
EDIT: Made some edits to clarify things a bit more.

excellent post. very informative.

accoriding to the first link:
-march=cpu-type
Generate instructions for the machine type cpu-type. The choices for cpu-type are the same as for -mcpu. Moreover, specifying -march=cpu-type implies -mcpu=cpu-type .

so are u sure ur '-march=i586' and '-mcpu=athlon' options are redundant? don't they imply '-march=i586' and '-mcpu=i586'? though i've seen code using the method/values u mentioned.

using the /etc/profile option. do all/most app's make scripts check to see if these variables exist? i noticed that the kernel makefile doesn't check to see if these exist. i'd have to modify the Makefile myself.

btw, my initial question was still sorta unanswered. the actual line in that file is there's no ;. so how does that line evaluate?

ty
abs

If you use only the '-march=' flag, then the other is also implied and the binary will also be optimized for that CPU arch, as well as being compatible for the specified arch............by specifying both, you can make the binary optimized for a newer arch, while retaining compatibility for an older arch.....................For instance, the Slackware packages will have "i486" in the name, but they are usually optimized for for the i686 cpu (not all packages are, tho') so while they will run on the i486 arch, they will really shine on the i686 arch.............

No, not all source packages will honor those environment variables............A lot of them do, but QT, I know, will only optimize for the i486 arch, no matter what variable you try to pass it (unless you edit the makefiles by hand)...........They're more for standardization and convention, but are not requrements for compiling (the evnironment variables, that is)...........

I thought I did answer it above: "... Defining a variable doesn't count as a command on the command line, so there is no need to use a semi-colon after it if followed by other commands on the same line. But in order to not confuse it with a command's option, it is written before any commands on the same line. This also makes the variable available for the command being used, since it makes no sense to define the variable after issuing a command..."

That CFLAGS variable doesn't do anything except define an environment variable, which can be used by other commands later on in the same session, it's not a command so no semi-colon is necessary.........In this case, it's sort of like passing an option indirectly..........

HTH

ah yes, u did answer the question :P i didn't get that when i read it first.
the kernel makefile is this way too. it assigns CPPFLAGS and then CLAGS is that and '-Wall , etc.' i'm sure the reasons are good. though. checking if .config and or make config/menuconfig have some options.

abs