Home Forum Developers General discussions Some compiling conventions

JRPassphrase Registration Control

In order to register on this site, you must first submit the passphrase below.

TODO list for each hardware target can be found as sticky topic in the corresponding forum


Chewi
useravatar
User Info

Some compiling conventions

Some of the packages are being built with flags that are redundant or even detrimental. I've patched these out, tested it, and I'll push the changes with Dimitar's permission. Assuming this is okay, I'd like to enforce some conventions for the future.


  • Never use -mfdpic. It is enabled automatically by the bfin-linux-uclibc toolchain and it makes no sense for the bfin-uclinux toolchain.

  • Don't define __BLACKFIN__. Use __BFIN__ in your code instead as it is automatically defined by the compiler.

  • Don't add libraries to LDFLAGS when using autotools. These should be added to LIBS, if at all. See next point.

  • Don't add libraries to LIBS either unless the package fails to build because of unresolved symbols. This is unlikely to happen as autotools should link the libraries by itself. Needlessly adding libraries will create additional dependencies, for example, the asterisk binary will fail to start if libspeex is missing even though only the codec_speex module actually requires it.


Administrator has disabled public posting
admin
useravatar
User Info

Re: Some compiling conventions

Hi James,

Feel free to suggest Switchfin clean-up related with the items you have mentioned.

Cheers smile
Dimitar


Administrator has disabled public posting
Chewi
useravatar
User Info

Re: Some compiling conventions

I'm not sure whether you meant that you still want to see the patch before I commit it. I've added a few more things to the list anyway.


  • When using autotools, be explicit about which features you do and do not want. If you don't specify, autotools will enable features based on which headers/libraries it detects, even if you didn't ask for them. Conversely, if you do request a feature and it doesn't find the needed headers/libraries then it will usually abort with an error, which is better than just continuing the build anyway.

  • Put -I include options in CPPFLAGS, not CFLAGS or CXXFLAGS, unless the Makefile doesn't use CPPFLAGS. Almost all autotools-based packages use CPPFLAGS. This will fix these warnings, which you have no doubt seen.

    configure: WARNING: foo.h: accepted by the compiler, rejected by the preprocessor!
    configure: WARNING: foo.h: proceeding with the compiler's result

  • When using autotools, set CPPFLAGS CFLAGS, CXXFLAGS, and LDFLAGS when running configure, not when running make, and certainly not both. The flags are saved so it doesn't matter if you run make in a fresh environment.


Regarding the second point, Asterisk is a special case. It does use autoconf but not automake and hence the Makefiles don't use CPPFLAGS. However, you still want to set it to avoid the configure warnings. Until now, we have set ASTCFLAGS and ASTLDFLAGS when running make. This is unnecessary because CFLAGS and LDFLAGS are passed through from configure. But since CPPFLAGS is not used, you still need to pass this through manually. The following does the trick.

Code:

Before:

OPTIMIZE="-O4" ASTCFLAGS="$(ASTERISK_CFLAGS)" ASTLDFLAGS="$(ASTERISK_LDFLAGS)" $(MAKE1) -C $(ASTERISK_DIR) NOISY_BUILD=1 GNU_LD=0

After:
OPTIMIZE="-O4" ASTCFLAGS="$(ASTERISK_CPPFLAGS)" $(MAKE1) -C $(ASTERISK_DIR) NOISY_BUILD=1 GNU_LD=0

Although the points I've mentioned affect almost every package, I've only applied the __BLACKFIN__ and -mfdpic changes across the board so far. The rest have only been applied to Asterisk because it is arguably the most important package. I'll continue my clean up in the near future, along with the raft of other improvements I have planned. smile

Dimitar, here is the patch. Please let me know if it's good to go.

What I'd actually like to do in the long run is globally define CPPFLAGS and LDFLAGS so that the uClinux-dist paths are always present. It makes sense since these are required by nearly every single package and most (if not all?) of these packages don't need anything else to be added to these variables.

All these changes draw on my years of experience as a Gentoo user, where almost all the packages are built from source in a tightly controlled yet flexible manner. It does make a very good base for other distros (it's the base for Chrome OS!) so I keep having to put off the temptation to start a new embedded VoIP distro with it. wink I like Switchfin's minimalism though. Stripping Gentoo down to that level would probably be more work.


Administrator has disabled public posting
Chewi
useravatar
User Info

Re: Some compiling conventions

While pushing the SpanDSP update, I accidentally pushed these changes as well. I didn't hear any complaints though so I guess that's okay!


Administrator has disabled public posting

Board Info

Board Stats:   Total Users: 2587  Total Topics: 299  Total Polls: 1  Total Posts: 1727  Dormant
User Info:   Newest User :  user2553   Members Online: 0   Guests Online: 141
Online  There are no members online
Topic
New
Locked
Topic
New
Locked
Sticky
Active
New/Active
Sticky
Active
New/Active
New/Closed
New Sticky
Closed/Active
New/Locked
New Sticky
Locked/Active
Active/Sticky
Sticky/Locked
Sticky Active Locked
Active/Sticky
Sticky/Locked
Sticky/Active/Locked