Making package(s) for x86 instead of 686

Question

I have a need to build a custom version of a couple of Arch packages for use on a special purpose Live CD - these packages are NOT for installing or running on my regular Arch distro itself.
The ONLY thing I want to customize for each package is to change it from  being able to run *exclusively* on i686 to just being *optimized* for i686 (but able to run on older processors such as i586). i586 is as far back as I need to go actually.
The way I've tried this is to:
1. copy the standard Arch abs directory for the package in question over to another location (in /var/abs/local).
2. edit /etc/makepkg.conf so that the "export CFLAGS" and "export CXXFLAGS" lines specify "optimized for 686" instead of "exclusively 686"
3. build the package with makepkg.
The build works fine, but looking at the results, the binaries in the custom package seem to be identical to the binaries in the standard package (same size etc.). I would expect to see some difference, and I don't have a way to test the custom package's binaries at the moment.
Question: Is the above all I need to do for this purpose, or is there a better, more correct way to do this.? IOW, have I missed something?
Thanks,
Tom

Answer 1

Snowman wrote:Instead of comparing the binairies size, do a diff on them. From what I can see, you seem to be using the correct method.
Yes, the binaries were all exactly the same, byte for byte.
But.....when I tried a couple of other packages doing it the same way, I got results more like I expected -  some of the binaries were clearly different etc., and I could also see the CFLAGS parameters from makepkg.conf getting picked up by the makefiles in the package's source directory.
The first package (where I saw no differences) was udev, and it looks like its Makefile just ignores those exported values from /etc/makepkg.conf. In fact the man page for makepkg warns that this can happen with some packages...
I guess I could edit the makefile manually, or maybe it just doesn't matter in that case. Not sure, but testing should tell the story. Anyway, thanks for the response.
Tom