C compile error on redhat AS 2.6.9-27:syntax error zone_lock


#1

Hello,
I compiled successfully a week ago. My harddrive gave up and I had to reload from scratch (OS to tools). Before compiling I updated everything via up2date.

Compiling this time results in the errors protocolled below.

The code itself looks totally clean to me:
zaptel.c:

... 382 383 #ifdef DEFINE_RWLOCK 384 static DEFINE_RWLOCK(zone_lock); 385 static DEFINE_RWLOCK(chan_lock); 386 #else 387 static rwlock_t zone_lock = RW_LOCK_UNLOCKED; 388 static rwlock_t chan_lock = RW_LOCK_UNLOCKED; 389 #endif ...

protocol of the make:

[root@guentis zaptel-1.2.2]# make
ZAPTELVERSION="" build_tools/make_version_h > version.h.tmp
if cmp -s version.h.tmp version.h ; then echo; else \
        mv version.h.tmp version.h ; \
fi

rm -f version.h.tmp
/lib/modules/2.6.9-27.EL/build
make -C /lib/modules/2.6.9-27.EL/build SUBDIRS=/usr/src/zaptel-1.2.2 modules
make[1]: Entering directory `/usr/src/kernels/2.6.9-27.EL-i686'
  CC [M]  /usr/src/zaptel-1.2.2/zaptel.o
/usr/src/zaptel-1.2.2/zaptel.c:384: error: syntax error before "zone_lock"
/usr/src/zaptel-1.2.2/zaptel.c:384: warning: type defaults to `int' in declaration of `zone_lock'
/usr/src/zaptel-1.2.2/zaptel.c:384: error: incompatible types in initialization
/usr/src/zaptel-1.2.2/zaptel.c:384: error: initializer element is not constant
/usr/src/zaptel-1.2.2/zaptel.c:384: warning: data definition has no type or storage class
/usr/src/zaptel-1.2.2/zaptel.c:385: error: syntax error before "chan_lock"
/usr/src/zaptel-1.2.2/zaptel.c:385: warning: type defaults to `int' in declaration of `chan_lock'
/usr/src/zaptel-1.2.2/zaptel.c:385: error: incompatible types in initialization
/usr/src/zaptel-1.2.2/zaptel.c:385: error: initializer element is not constant
/usr/src/zaptel-1.2.2/zaptel.c:385: warning: data definition has no type or storage class
/usr/src/zaptel-1.2.2/zaptel.c:188: warning: 'fcstab' defined but not used
make[2]: *** [/usr/src/zaptel-1.2.2/zaptel.o] Error 1
make[1]: *** [_module_/usr/src/zaptel-1.2.2] Error 2
make[1]: Leaving directory `/usr/src/kernels/2.6.9-27.EL-i686'
make: *** [linux26] Error 2

I don’t want to reinstall and compile using older kernel sources before updating. Also, others may not have the chance to go back to an older version.

Thank you in advance for your help
guenter strubinsky


#2

It compiles fine when I set the kernel sources back to “2.6.9-5.EL” !!!


#3

Any Updates - can’t update CentOS / AAH 2.7 to latest kernel - rebuilding zaptel drivers gives the following errors. (downgrading to old kernel get the driver to work again)

Do we need to wait for a new Zaptel release?

/lib/modules/2.6.9-34.EL/build
make -C /lib/modules/2.6.9-34.EL/build SUBDIRS=/usr/src/zaptel modules
make[1]: Entering directory /usr/src/kernels/2.6.9-34.EL-i686' CC [M] /usr/src/zaptel/zaptel.o /usr/src/zaptel/zaptel.c:372: error: syntax error before "zone_lock" /usr/src/zaptel/zaptel.c:372: warning: type defaults toint’ in declaration of zone_lock' /usr/src/zaptel/zaptel.c:372: error: incompatible types in initialization /usr/src/zaptel/zaptel.c:372: error: initializer element is not constant /usr/src/zaptel/zaptel.c:372: warning: data definition has no type or storage class /usr/src/zaptel/zaptel.c:373: error: syntax error before "chan_lock" /usr/src/zaptel/zaptel.c:373: warning: type defaults toint’ in declaration of chan_lock' /usr/src/zaptel/zaptel.c:373: error: incompatible types in initialization /usr/src/zaptel/zaptel.c:373: error: initializer element is not constant /usr/src/zaptel/zaptel.c:373: warning: data definition has no type or storage class /usr/src/zaptel/zaptel.c:176: warning: 'fcstab' defined but not used make[2]: *** [/usr/src/zaptel/zaptel.o] Error 1 make[1]: *** [_module_/usr/src/zaptel] Error 2 make[1]: Leaving directory/usr/src/kernels/2.6.9-34.EL-i686’
make: *** [linux26] Error 2
[root@pbx2 zaptel]# uname -r
2.6.9-34.EL


#4

See: bugzilla.redhat.com/bugzilla/sh … ?id=180568


#5

I made the 1-line change to spinlock.h and all is well. I work in software business, and am (to put it mildly) astonished that someone was able to submit a change that doesn’t even compile! Ouch…


#6

See also: bugs.digium.com/view.php?id=6425

P.S. I am in the software business too and I made sometimes changes that were too little and too trivial to recompile. I was wrong too since especially a missed underscore or one at the wrong position get the compiler the hickups.

You can honestly say (no fingers crossing behind your back, mister) that you ever never made a trivial change and did not bother to test it since it was soooo trivial?


#7

You misunderstood my point. I was NOT blaming the engineer (I have certainly made my share of fat finger mistakes.) I’m blaming the release management procedures and policies at Redhat.


#8

Linux is far too rich and too complicated (6 CD’s at the moment) to regression test every single component AND have the next release out within a year or so.

That’s the beauty of open source software. You as well as I as well as everybody can find the bug/typo in the source code, while with ‘the other OS’ you need to wait a few days until the next update appears which replaces sucky-old errors with shiny-new errors. There is no way to find AND fix (for everybody to enjoy) issues in Micro$ofts software.

Besides that also results in a status advances under your geek-friends if you do :laughing: :smiling_imp: :blush:


#9

I can’t even begin to say how strongly disagree with this. Dude, we’re NOT talking about a complete regression test of all functionality. I understand that. I’m talking about doing something like:

‘make compile’

or somesuch (at the top level). You have a tree where files are checked-in. When the entire tree has compiled successfully, you roll the check-in tree to the publically visible one. This is basic software release engineering.


#10

You are a republican, right?

Well, let’s visit lesson “C” 101:

#includes are used to let others profit from and reuse definitions in many different programs that you (the author of the #include) created. They may be interfaces to software objects you created or some semi- or real-standard data-structures. Programs written by several to many authors everywhere (hence Open Source) use this, your include.

In the open source community it also means that those includes are used from authors you don’t even know that they are using it.

In this very case the asterisk/asterisk@home authors utilized that #include defined by someone @ redHat.

Although * is Open Source too, they are NOT in any way related to redHat, Suse, CentOS or even Windows (yes, there is a windows version out under CygWin’s auspices), etc. If someone at redHat makes a change at redHat sources/includes they DO NOT KNOW who else on this planet sucks that very include in. There is no worldwide XRef about includes!

Your statement would be 110% correct if that include was one written by the Asterisk team and I would have myself brought the tar if you brought the feathers to tar-and-feather the authors since your approach is perfect. But The include is from redhat and the Source is from Asterisk.

That’s how I imagine it went:

  • You release (as asterisk) your code after successfull compilation.
  • A few days/weeks/months later redHat releases a new include which lets your (asterisk) source break. The redhat guys don’t know, don’t care (for a good reason) not about you including their include
  • You (asterisk) don’t know, don’t care that and when redHat released those changes since you and them are different software entities.

Voila, you have a situation like this.

I wrote code myself that was broken when the software component I used had changed. Sontimes it even compiled correctly.

Hence the old saying: If it ain’t broken don’t change it.

Rereading my above statements: I apologize if I sounded patronizing, but that’s how it is. There are situations, where it’s nobodys fault and it still does not work. In any case, we found a solution and everything is well and dandy by changing one line of code. Consider it a sub-sub-release and you were smart enough to find the respective fix here and now. The next redHat subrelease (I believe it was released last night) will compile nicely and the quality of our software stays at a high (possibly as a result of other bugfixes and improvements even higher) level of performance and quality as a result of the involvement of the Open Source Community. That’s the way I love it !

… and you?

  • because Open Source is more stable, more reliable and best of all with no hidden backdoors
    or
  • because it’s $$free$$ ?

In the first case you saw the Open Source mechanisms at best at work, in the second case: ask for your money back.


#11

My political inclinations are none of your business (nor are they relevant.) And, again, this has ZERO to do with digium or some subtle misbehavior that wasn’t caught by regression testing. Redhat is NOT some fly-by-night one-man shop where they can’t do basic smoke testing on a snapshot before releasing it. This was an elementary typo that would have broken any software component that included it (and yes, your response was pretty patronizing.) This is what basic software build regression tests are all about - I have used several packages (open source, no less), where the authors have cron jobs that do a test build nightly - if it doesn’t pass, it doesn’t get released. Notwithstanding any of that, typos are one thing, but not even bothering to check whether your changes compile or not before submitting them is pretty bad. And (not to beat a dead horse), this is why any shop that isn’t a 1-man outfit has no excuse for doing basic build regression testing.


#12

good day sir/maam! I am John joseph del Prado from the small island of the philippines. I am presently taking network administration and on my second year. Net-ad is two year vocational course being offered in our school. i am on graduating this march. one of the requirements of a being able to graduate is to xubmit a thesis, and i am very interested in taking asterisk as my thesis project. as you well know the Philippines is a third world country and technologyon support on this part of asia is very little, but inspite of this i still want to pursue my asterisk project. I will be very grateful if you can provide me with free step step by step tutorial books, pdf or whatsover references i that can help my thesis. I have already installed fedora core 3 in my desktop computer but it is having problem with my modem. my modem driver support only 2.4 kernels and FC 3 has 2.6 kernels. maybe i can reformat my hard disk and switch to Red Hat 8 and hopefully it can detect my modem and finally install asterisk, then probably i can start my thesis. so please help me with my problem and do send me an asterisk tutorial. Thank you and MABUHAY! (long live).


#13

This does not exactly qualify as a response to the issue on this thread.

Please START a new one since nobody other than dswartz and strubinsky is even marginally interested in this conversation as it has deteriorated on both sides coming from the solution of a problem to, well you see…

As a side: I do suggest that you start with asterisk@home which saves you quite a bit of hassle plus adds some cool tools and features (fax for example).

See: asteriskathome.sourceforge.net/

Some wikis that may help are

voip-info.org/wiki-Asterisk
voip-info.org/wiki/view/Aste … dbook+Wiki

I know of two excellent books:

I advise you still to start a new thread since others may and will offer more and more extensive information.

regards
günter strubinsky