ELOG Midas

Back Midas Rome Roody Rootana

Midas DAQ System, Page 97 of 150

Not logged in

Find | Login | Help

Full | Summary | Threaded | Hide attachments

2994 Entries

Goto page Previous 1, 2, 3 ... 96, 97, 98 ... 148, 149, 150 Next

ID	Date	Author	Topic	Subject
335	02 Feb 2007	Exaos Lee	Bug Report	Compiling failed with SVN3562 under Ubuntu 6.10
I tried to solve the problem by adding a ";". It was wrong. In fact, the macro "_syscall0(..)" doesn't need the ";". I searched and found that somebody said "the overall _syscall$magicnumber will disappear". I don't mind whether the "_syscall" disappear or not. I just want to compile the code and do my job. I deleted the additional ";" and recompiled. The error output is as the attachment [elog:335/1].
Attachment 1: err.log
cc -c -g -O2 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_MYSQL -DHAVE_ROOT -pthread -I/opt/root/current/include -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/system.o src/system.c src/system.c:958: error: expected declaration specifiers or ‘...’ before ‘gettid’ src/system.c:961: warning: return type defaults to ‘int’ src/system.c: In function ‘_syscall0’: src/system.c:978: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:1019: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:1050: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:1165: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:1380: error: storage class specified for parameter ‘_daemon_flag’ src/system.c:1400: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:1462: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:1495: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:1532: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:1621: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:1695: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:1731: error: storage class specified for parameter ‘skip_mutex_handle’ src/system.c:1731: error: parameter ‘skip_mutex_handle’ is initialized src/system.c:1760: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:1915: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:2024: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:2110: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:2181: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:2248: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:2277: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:2341: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:2379: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:2393: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:2413: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:2484: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:2546: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:2644: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:2751: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:2807: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:2871: error: storage class specified for parameter ‘SUSPEND_STRUCT’ src/system.c:2873: error: expected declaration specifiers before ‘SUSPEND_STRUCT’ src/system.c:2896: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:3002: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:3072: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:3132: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:3187: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:3235: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:3493: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:3547: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:3606: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:3682: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:3775: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:3901: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:4080: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:4167: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:4210: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:4297: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:4356: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:4430: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:4497: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:4558: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:4615: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:4667: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:4723: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:4779: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:4826: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:4887: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:4980: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:5049: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:5069: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:5093: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:5171: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:5222: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:5258: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:5313: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:5379: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:5645: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:5668: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:5707: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:5769: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:5853: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token src/system.c:5883: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token In file included from /usr/include/math.h:71, from src/system.c:5897: /usr/include/bits/mathcalls.h:55: error: storage class specified for parameter ‘acos’ /usr/include/bits/mathcalls.h:55: error: storage class specified for parameter ‘__acos’ /usr/include/bits/mathcalls.h:57: error: storage class specified for parameter ‘asin’ /usr/include/bits/mathcalls.h:57: error: storage class specified for parameter ‘__asin’ /usr/include/bits/mathcalls.h:59: error: storage class specified for parameter ‘atan’ /usr/include/bits/mathcalls.h:59: error: storage class specified for parameter ‘__atan’ /usr/include/bits/mathcalls.h:61: error: storage class specified for parameter ‘atan2’ /usr/include/bits/mathcalls.h:61: error: storage class specified for parameter ‘__atan2’ /usr/include/bits/mathcalls.h:64: error: storage class specified for parameter ‘cos’ /usr/include/bits/mathcalls.h:64: error: storage class specified for parameter ‘__cos’ /usr/include/bits/mathcalls.h:66: error: storage class specified for parameter ‘sin’ /usr/include/bits/mathcalls.h:66: error: storage class specified for parameter ‘__sin’ /usr/include/bits/mathcalls.h:68: error: storage class specified for parameter ‘tan’ /usr/include/bits/mathcalls.h:68: error: storage class specified for parameter ‘__tan’ /usr/include/bits/mathcalls.h:73: error: storage class specified for parameter ‘cosh’ /usr/include/bits/mathcalls.h:73: error: storage class specified for parameter ‘__cosh’ /usr/include/bits/mathcalls.h:75: error: storage class specified for parameter ‘sinh’ /usr/include/bits/mathcalls.h:75: error: storage class specified for parameter ‘__sinh’ /usr/include/bits/mathcalls.h:77: error: storage class specified for parameter ‘tanh’ /usr/include/bits/mathcalls.h:77: error: storage class specified for parameter ‘__tanh’ /usr/include/bits/mathcalls.h:89: error: storage class specified for parameter ‘acosh’ /usr/include/bits/mathcalls.h:89: error: storage class specified for parameter ‘__acosh’ /usr/include/bits/mathcalls.h:91: error: storage class specified for parameter ‘asinh’ /usr/include/bits/mathcalls.h:91: error: storage class specified for parameter ‘__asinh’ /usr/include/bits/mathcalls.h:93: error: storage class specified for parameter ‘atanh’ /usr/include/bits/mathcalls.h:93: error: storage class specified for parameter ‘__atanh’ /usr/include/bits/mathcalls.h:101: error: storage class specified for parameter ‘exp’ /usr/include/bits/mathcalls.h:101: error: storage class specified for parameter ‘__exp’ /usr/include/bits/mathcalls.h:104: error: storage class specified for parameter ‘frexp’ /usr/include/bits/mathcalls.h:104: error: storage class specified for parameter ‘__frexp’ /usr/include/bits/mathcalls.h:107: error: storage class specified for parameter ‘ldexp’ /usr/include/bits/mathcalls.h:107: error: storage class specified for parameter ‘__ldexp’ /usr/include/bits/mathcalls.h:110: error: storage class specified for parameter ‘log’ /usr/include/bits/mathcalls.h:110: error: storage class specified for parameter ‘__log’ /usr/include/bits/mathcalls.h:113: error: storage class specified for parameter ‘log10’ /usr/include/bits/mathcalls.h:113: error: storage class specified for parameter ‘__log10’ /usr/include/bits/mathcalls.h:116: error: storage class specified for parameter ‘modf’ /usr/include/bits/mathcalls.h:116: error: storage class specified for parameter ‘__modf’ /usr/include/bits/mathcalls.h:129: error: storage class specified for parameter ‘expm1’ /usr/include/bits/mathcalls.h:129: error: storage class specified for parameter ‘__expm1’ /usr/include/bits/mathcalls.h:132: error: storage class specified for parameter ‘log1p’ /usr/include/bits/mathcalls.h:132: error: storage class specified for parameter ‘__log1p’ /usr/include/bits/mathcalls.h:135: error: storage class specified for parameter ‘logb’ /usr/include/bits/mathcalls.h:135: error: storage class specified for parameter ‘__logb’ /usr/include/bits/mathcalls.h:154: error: storage class specified for parameter ‘pow’ /usr/include/bits/mathcalls.h:154: error: storage class specified for parameter ‘__pow’ /usr/include/bits/mathcalls.h:157: error: storage class specified for parameter ‘sqrt’ /usr/include/bits/mathcalls.h:157: error: storage class specified for parameter ‘__sqrt’ /usr/include/bits/mathcalls.h:163: error: storage class specified for parameter ‘hypot’ /usr/include/bits/mathcalls.h:163: error: storage class specified for parameter ‘__hypot’ /usr/include/bits/mathcalls.h:170: error: storage class specified for parameter ‘cbrt’ /usr/include/bits/mathcalls.h:170: error: storage class specified for parameter ‘__cbrt’ /usr/include/bits/mathcalls.h:179: error: storage class specified for parameter ‘ceil’ /usr/include/bits/mathcalls.h:179: error: storage class specified for parameter ‘__ceil’ /usr/include/bits/mathcalls.h:182: error: storage class specified for parameter ‘fabs’ /usr/include/bits/mathcalls.h:182: error: storage class specified for parameter ‘__fabs’ /usr/include/bits/mathcalls.h:185: error: storage class specified for parameter ‘floor’ /usr/include/bits/mathcalls.h:185: error: storage class specified for parameter ‘__floor’ /usr/include/bits/mathcalls.h:188: error: storage class specified for parameter ‘fmod’ /usr/include/bits/mathcalls.h:188: error: storage class specified for parameter ‘__fmod’ /usr/include/bits/mathcalls.h:193: error: storage class specified for parameter ‘__isinf’ /usr/include/bits/mathcalls.h:196: error: storage class specified for parameter ‘__finite’ /usr/include/bits/mathcalls.h:202: error: storage class specified for parameter ‘isinf’ /usr/include/bits/mathcalls.h:205: error: storage class specified for parameter ‘finite’ /usr/include/bits/mathcalls.h:208: error: storage class specified for parameter ‘drem’ /usr/include/bits/mathcalls.h:208: error: storage class specified for parameter ‘__drem’ /usr/include/bits/mathcalls.h:212: error: storage class specified for parameter ‘significand’ /usr/include/bits/mathcalls.h:212: error: storage class specified for parameter ‘__significand’ /usr/include/bits/mathcalls.h:218: error: storage class specified for parameter ‘copysign’ /usr/include/bits/mathcalls.h:218: error: storage class specified for parameter ‘__copysign’ /usr/include/bits/mathcalls.h:231: error: storage class specified for parameter ‘__isnan’ /usr/include/bits/mathcalls.h:235: error: storage class specified for parameter ‘isnan’ /usr/include/bits/mathcalls.h:238: error: storage class specified for parameter ‘j0’ /usr/include/bits/mathcalls.h:238: error: storage class specified for parameter ‘__j0’ /usr/include/bits/mathcalls.h:239: error: storage class specified for parameter ‘j1’ /usr/include/bits/mathcalls.h:239: error: storage class specified for parameter ‘__j1’ /usr/include/bits/mathcalls.h:240: error: storage class specified for parameter ‘jn’ /usr/include/bits/mathcalls.h:240: error: storage class specified for parameter ‘__jn’ /usr/include/bits/mathcalls.h:241: error: storage class specified for parameter ‘y0’ /usr/include/bits/mathcalls.h:241: error: storage class specified for parameter ‘__y0’ /usr/include/bits/mathcalls.h:242: error: storage class specified for parameter ‘y1’ /usr/include/bits/mathcalls.h:242: error: storage class specified for parameter ‘__y1’ /usr/include/bits/mathcalls.h:243: error: storage class specified for parameter ‘yn’ /usr/include/bits/mathcalls.h:243: error: storage class specified for parameter ‘__yn’ /usr/include/bits/mathcalls.h:250: error: storage class specified for parameter ‘erf’ /usr/include/bits/mathcalls.h:250: error: storage class specified for parameter ‘__erf’ /usr/include/bits/mathcalls.h:251: error: storage class specified for parameter ‘erfc’ /usr/include/bits/mathcalls.h:251: error: storage class specified for parameter ‘__erfc’ /usr/include/bits/mathcalls.h:252: error: storage class specified for parameter ‘lgamma’ /usr/include/bits/mathcalls.h:252: error: storage class specified for parameter ‘__lgamma’ /usr/include/bits/mathcalls.h:265: error: storage class specified for parameter ‘gamma’ /usr/include/bits/mathcalls.h:265: error: storage class specified for parameter ‘__gamma’ /usr/include/bits/mathcalls.h:272: error: storage class specified for parameter ‘lgamma_r’ /usr/include/bits/mathcalls.h:272: error: storage class specified for parameter ‘__lgamma_r’ /usr/include/bits/mathcalls.h:280: error: storage class specified for parameter ‘rint’ /usr/include/bits/mathcalls.h:280: error: storage class specified for parameter ‘__rint’ /usr/include/bits/mathcalls.h:283: error: storage class specified for parameter ‘nextafter’ /usr/include/bits/mathcalls.h:283: error: storage class specified for parameter ‘__nextafter’ /usr/include/bits/mathcalls.h:289: error: storage class specified for parameter ‘remainder’ /usr/include/bits/mathcalls.h:289: error: storage class specified for parameter ‘__remainder’ /usr/include/bits/mathcalls.h:293: error: storage class specified for parameter ‘scalbn’ /usr/include/bits/mathcalls.h:293: error: storage class specified for parameter ‘__scalbn’ /usr/include/bits/mathcalls.h:297: error: storage class specified for parameter ‘ilogb’ /usr/include/bits/mathcalls.h:297: error: storage class specified for parameter ‘__ilogb’ /usr/include/bits/mathcalls.h:364: error: storage class specified for parameter ‘scalb’ /usr/include/bits/mathcalls.h:364: error: storage class specified for parameter ‘__scalb’ In file included from /usr/include/math.h:94, from src/system.c:5897: /usr/include/bits/mathcalls.h:55: error: storage class specified for parameter ‘acosf’ /usr/include/bits/mathcalls.h:55: error: storage class specified for parameter ‘__acosf’ /usr/include/bits/mathcalls.h:57: error: storage class specified for parameter ‘asinf’ /usr/include/bits/mathcalls.h:57: error: storage class specified for parameter ‘__asinf’ /usr/include/bits/mathcalls.h:59: error: storage class specified for parameter ‘atanf’ /usr/include/bits/mathcalls.h:59: error: storage class specified for parameter ‘__atanf’ /usr/include/bits/mathcalls.h:61: error: storage class specified for parameter ‘atan2f’ /usr/include/bits/mathcalls.h:61: error: storage class specified for parameter ‘__atan2f’ /usr/include/bits/mathcalls.h:64: error: storage class specified for parameter ‘cosf’ /usr/include/bits/mathcalls.h:64: error: storage class specified for parameter ‘__cosf’ /usr/include/bits/mathcalls.h:66: error: storage class specified for parameter ‘sinf’ /usr/include/bits/mathcalls.h:66: error: storage class specified for parameter ‘__sinf’ /usr/include/bits/mathcalls.h:68: error: storage class specified for parameter ‘tanf’ /usr/include/bits/mathcalls.h:68: error: storage class specified for parameter ‘__tanf’ /usr/include/bits/mathcalls.h:73: error: storage class specified for parameter ‘coshf’ /usr/include/bits/mathcalls.h:73: error: storage class specified for parameter ‘__coshf’ /usr/include/bits/mathcalls.h:75: error: storage class specified for parameter ‘sinhf’ /usr/include/bits/mathcalls.h:75: error: storage class specified for parameter ‘__sinhf’ /usr/include/bits/mathcalls.h:77: error: storage class specified for parameter ‘tanhf’ /usr/include/bits/mathcalls.h:77: error: storage class specified for parameter ‘__tanhf’ /usr/include/bits/mathcalls.h:89: error: storage class specified for parameter ‘acoshf’ /usr/include/bits/mathcalls.h:89: error: storage class specified for parameter ‘__acoshf’ /usr/include/bits/mathcalls.h:91: error: storage class specified for parameter ‘asinhf’ /usr/include/bits/mathcalls.h:91: error: storage class specified for parameter ‘__asinhf’ /usr/include/bits/mathcalls.h:93: error: storage class specified for parameter ‘atanhf’ /usr/include/bits/mathcalls.h:93: error: storage class specified for parameter ‘__atanhf’ /usr/include/bits/mathcalls.h:101: error: storage class specified for parameter ‘expf’ /usr/include/bits/mathcalls.h:101: error: storage class specified for parameter ‘__expf’ /usr/include/bits/mathcalls.h:104: error: storage class specified for parameter ‘frexpf’ /usr/include/bits/mathcalls.h:104: error: storage class specified for parameter ‘__frexpf’ /usr/include/bits/mathcalls.h:107: error: storage class specified for parameter ‘ldexpf’ /usr/include/bits/mathcalls.h:107: error: storage class specified for parameter ‘__ldexpf’ /usr/include/bits/mathcalls.h:110: error: storage class specified for parameter ‘logf’ /usr/include/bits/mathcalls.h:110: error: storage class specified for parameter ‘__logf’ /usr/include/bits/mathcalls.h:113: error: storage class specified for parameter ‘log10f’ /usr/include/bits/mathcalls.h:113: error: storage class specified for parameter ‘__log10f’ /usr/include/bits/mathcalls.h:116: error: storage class specified for parameter ‘modff’ /usr/include/bits/mathcalls.h:116: error: storage class specified for parameter ‘__modff’ /usr/include/bits/mathcalls.h:129: error: storage class specified for parameter ‘expm1f’ /usr/include/bits/mathcalls.h:129: error: storage class specified for parameter ‘__expm1f’ /usr/include/bits/mathcalls.h:132: error: storage class specified for parameter ‘log1pf’ /usr/include/bits/mathcalls.h:132: error: storage class specified for parameter ‘__log1pf’ /usr/include/bits/mathcalls.h:135: error: storage class specified for parameter ‘logbf’ /usr/include/bits/mathcalls.h:135: error: storage class specified for parameter ‘__logbf’ /usr/include/bits/mathcalls.h:154: error: storage class specified for parameter ‘powf’ /usr/include/bits/mathcalls.h:154: error: storage class specified for parameter ‘__powf’ /usr/include/bits/mathcalls.h:157: error: storage class specified for parameter ‘sqrtf’ /usr/include/bits/mathcalls.h:157: error: storage class specified for parameter ‘__sqrtf’ /usr/include/bits/mathcalls.h:163: error: storage class specified for parameter ‘hypotf’ /usr/include/bits/mathcalls.h:163: error: storage class specified for parameter ‘__hypotf’ /usr/include/bits/mathcalls.h:170: error: storage class specified for parameter ‘cbrtf’ /usr/include/bits/mathcalls.h:170: error: storage class specified for parameter ‘__cbrtf’ /usr/include/bits/mathcalls.h:179: error: storage class specified for parameter ‘ceilf’ /usr/include/bits/mathcalls.h:179: error: storage class specified for parameter ‘__ceilf’ /usr/include/bits/mathcalls.h:182: error: storage class specified for parameter ‘fabsf’ /usr/include/bits/mathcalls.h:182: error: storage class specified for parameter ‘__fabsf’ /usr/include/bits/mathcalls.h:185: error: storage class specified for parameter ‘floorf’ /usr/include/bits/mathcalls.h:185: error: storage class specified for parameter ‘__floorf’ /usr/include/bits/mathcalls.h:188: error: storage class specified for parameter ‘fmodf’ /usr/include/bits/mathcalls.h:188: error: storage class specified for parameter ‘__fmodf’ /usr/include/bits/mathcalls.h:193: error: storage class specified for parameter ‘__isinff’ /usr/include/bits/mathcalls.h:196: error: storage class specified for parameter ‘__finitef’ /usr/include/bits/mathcalls.h:202: error: storage class specified for parameter ‘isinff’ /usr/include/bits/mathcalls.h:205: error: storage class specified for parameter ‘finitef’ /usr/include/bits/mathcalls.h:208: error: storage class specified for parameter ‘dremf’ /usr/include/bits/mathcalls.h:208: error: storage class specified for parameter ‘__dremf’ /usr/include/bits/mathcalls.h:212: error: storage class specified for parameter ‘significandf’ /usr/include/bits/mathcalls.h:212: error: storage class specified for parameter ‘__significandf’ /usr/include/bits/mathcalls.h:218: error: storage class specified for parameter ‘copysignf’ /usr/include/bits/mathcalls.h:218: error: storage class specified for parameter ‘__copysignf’ /usr/include/bits/mathcalls.h:231: error: storage class specified for parameter ‘__isnanf’ /usr/include/bits/mathcalls.h:235: error: storage class specified for parameter ‘isnanf’ /usr/include/bits/mathcalls.h:238: error: storage class specified for parameter ‘j0f’ /usr/include/bits/mathcalls.h:238: error: storage class specified for parameter ‘__j0f’ /usr/include/bits/mathcalls.h:239: error: storage class specified for parameter ‘j1f’ /usr/include/bits/mathcalls.h:239: error: storage class specified for parameter ‘__j1f’ /usr/include/bits/mathcalls.h:240: error: storage class specified for parameter ‘jnf’ /usr/include/bits/mathcalls.h:240: error: storage class specified for parameter ‘__jnf’ /usr/include/bits/mathcalls.h:241: error: storage class specified for parameter ‘y0f’ /usr/include/bits/mathcalls.h:241: error: storage class specified for parameter ‘__y0f’ /usr/include/bits/mathcalls.h:242: error: storage class specified for parameter ‘y1f’ /usr/include/bits/mathcalls.h:242: error: storage class specified for parameter ‘__y1f’ /usr/include/bits/mathcalls.h:243: error: storage class specified for parameter ‘ynf’ /usr/include/bits/mathcalls.h:243: error: storage class specified for parameter ‘__ynf’ /usr/include/bits/mathcalls.h:250: error: storage class specified for parameter ‘erff’ /usr/include/bits/mathcalls.h:250: error: storage class specified for parameter ‘__erff’ /usr/include/bits/mathcalls.h:251: error: storage class specified for parameter ‘erfcf’ /usr/include/bits/mathcalls.h:251: error: storage class specified for parameter ‘__erfcf’ /usr/include/bits/mathcalls.h:252: error: storage class specified for parameter ‘lgammaf’ /usr/include/bits/mathcalls.h:252: error: storage class specified for parameter ‘__lgammaf’ /usr/include/bits/mathcalls.h:265: error: storage class specified for parameter ‘gammaf’ /usr/include/bits/mathcalls.h:265: error: storage class specified for parameter ‘__gammaf’ /usr/include/bits/mathcalls.h:272: error: storage class specified for parameter ‘lgammaf_r’ /usr/include/bits/mathcalls.h:272: error: storage class specified for parameter ‘__lgammaf_r’ /usr/include/bits/mathcalls.h:280: error: storage class specified for parameter ‘rintf’ /usr/include/bits/mathcalls.h:280: error: storage class specified for parameter ‘__rintf’ /usr/include/bits/mathcalls.h:283: error: storage class specified for parameter ‘nextafterf’ /usr/include/bits/mathcalls.h:283: error: storage class specified for parameter ‘__nextafterf’ /usr/include/bits/mathcalls.h:289: error: storage class specified for parameter ‘remainderf’ /usr/include/bits/mathcalls.h:289: error: storage class specified for parameter ‘__remainderf’ /usr/include/bits/mathcalls.h:293: error: storage class specified for parameter ‘scalbnf’ /usr/include/bits/mathcalls.h:293: error: storage class specified for parameter ‘__scalbnf’ /usr/include/bits/mathcalls.h:297: error: storage class specified for parameter ‘ilogbf’ /usr/include/bits/mathcalls.h:297: error: storage class specified for parameter ‘__ilogbf’ /usr/include/bits/mathcalls.h:364: error: storage class specified for parameter ‘scalbf’ /usr/include/bits/mathcalls.h:364: error: storage class specified for parameter ‘__scalbf’ In file included from /usr/include/math.h:141, from src/system.c:5897: /usr/include/bits/mathcalls.h:55: error: storage class specified for parameter ‘acosl’ /usr/include/bits/mathcalls.h:55: error: storage class specified for parameter ‘__acosl’ /usr/include/bits/mathcalls.h:57: error: storage class specified for parameter ‘asinl’ /usr/include/bits/mathcalls.h:57: error: storage class specified for parameter ‘__asinl’ /usr/include/bits/mathcalls.h:59: error: storage class specified for parameter ‘atanl’ /usr/include/bits/mathcalls.h:59: error: storage class specified for parameter ‘__atanl’ ... 133 more lines ...
337	05 Feb 2007	Fedor Ignatov	Bug Report	segmentation violation of analyzer on a x86_64
Hello, When I connect to analyzer on a x86_64 processor(with Roody), a analyzer break with segmentation violation in the root_server_thread function. Same code are working fine on a 32bit processor. As I found the problem are in exchanging of pointers between analyzer and client. Before to send a pointer, it is saved a pointer in int (size=4, instead of 8) at this place: Index: src/mana.c =================================================================== --- src/mana.c (revision 3498) +++ src/mana.c (working copy) @@ -5386,7 +5386,7 @@ //write pointer message->Reset(kMESS_ANY); - int p = (POINTER_T) obj; + POINTER_T p = (POINTER_T) obj; message << p; sock->Send(message); Sincerely Yours, Fedor Ignatov
338	05 Feb 2007	Konstantin Olchanski	Bug Report	wrong version in include/midas.h?
The present .../include/midas.h contains [alpha@laddvme06 ~/online]$ grep 1.9.5 /home/alpha/packages/midas/include/* /home/alpha/packages/midas/include/midas.h:#define MIDAS_VERSION "1.9.5" All MIDAS utilities (odbedit ver) presently report version 1.9.5, even for svn trunk, and this may confuse people as to what version of midas they are using, and may complicate reporting of bugs. Perhaps the trunk version should say something like "svn-22233344" (the svn revision number)? The present "1.9.5" is wrong... K.O.
339	06 Feb 2007	Stefan Ritt	Bug Report	wrong version in include/midas.h?
> The present .../include/midas.h contains > [alpha@laddvme06 ~/online]$ grep 1.9.5 /home/alpha/packages/midas/include/* > /home/alpha/packages/midas/include/midas.h:#define MIDAS_VERSION "1.9.5" > > All MIDAS utilities (odbedit ver) presently report version 1.9.5, even for svn > trunk, and this may confuse people as to what version of midas they are using, > and may complicate reporting of bugs. > > Perhaps the trunk version should say something like "svn-22233344" (the svn > revision number)? The present "1.9.5" is wrong... Fully agree. I added a svn_revision string into midas.h, which gets reported now by "odbedit ver". Unfortunately this reflects only changes in midas.c. If one changes odb.c for example, the svn revision in midas.c does not get modified by the SVN system. In addition I changed the present version 1.9.5 to 2.0.0. I made the tar and zip files. After some internal testing, it will be announced officially in a few days.
341	06 Feb 2007	Stefan Ritt	Bug Report	segmentation violation of analyzer on a x86_64
> Hello, > > When I connect to analyzer on a x86_64 processor(with Roody), > a analyzer break with segmentation violation in the root_server_thread function. > Same code are working fine on a 32bit processor. > As I found the problem are in exchanging of pointers between analyzer and client. > Before to send a pointer, it is saved a pointer in int (size=4, instead of 8) at > this place: > Index: src/mana.c > =================================================================== > --- src/mana.c (revision 3498) > +++ src/mana.c (working copy) > @@ -5386,7 +5386,7 @@ > > //write pointer > message->Reset(kMESS_ANY); > - int p = (POINTER_T) obj; > + POINTER_T p = (POINTER_T) obj; > message << p; > sock->Send(message); > > > Sincerely Yours, > Fedor Ignatov Do I understand you right? With your patch it works even on 64 bit, right? Or do you mean there is still a segmentation violation? Anyhow I committed your patch since the "int" is clearly incorrect. - Stefan
342	06 Feb 2007	Fedor Ignatov	Bug Report	segmentation violation of analyzer on a x86_64
Yes right, Problem of a segmentation violation is solved with this patch. Now it works fine on x86_64. Fedor > Do I understand you right? With your patch it works even on 64 bit, right? Or do you > mean there is still a segmentation violation? Anyhow I committed your patch since the > "int" is clearly incorrect. > > - Stefan
345	17 Feb 2007	Konstantin Olchanski	Bug Report	segmentation violation of analyzer on a x86_64
> Yes right, Problem of a segmentation violation is solved with this patch. Now it works > fine on x86_64. Right. I confirm this. I have this exact same fix in my stand-alone copy of the midas histogram server, and should commit it to MIDAS CVS as well. K.O.
377	22 May 2007	Randolf Pohl	Bug Report	analyzer_init called by odb_load
Hi, I wonder why mana.c:odb_load() calls analyzer_init(). This way analyzer_init is called TWICE or more times: first from mana.c:mana_init(), for each invocation of the analyzer, and second from mana.c:odb_load(), for each run to be analyzed Isn't this a bug? It can mess up several things (like mallocs) if you don't take the necessary precautions. Other module_init functions are correctly called only once, before all runs are analyzed. I have the feeling, that odb_load should NOT call analyzer_init. Or am I wrong (probably, but please explain to me)? Do I have to live with it and make sure that my beautiful global initialization in analyzer_init is only done once? :-) Cheers, Randolf And here is the annotated log using the ROOT example experiment (several modules changed/added to print their respective names) :~/midas/examples/root> ./analyzer -e exa_root -i run%05d.mid -r 1 3 analyzer_init <-- ok Root server listening on port 9090... adc_calib_init <-- ok adc_summing_init <-- ok scaler_init <-- ok Running analyzer offline. Stop with "!" Set run number 1 in ODB Load ODB from run 1... analyzer_init <-- not ok, or is it? OK run00001.mid:777 events, 0.00s Set run number 2 in ODB Load ODB from run 2... analyzer_init <-- not ok, or is it? OK run00002.mid:7227 events, 0.03s Set run number 3 in ODB Load ODB from run 3... analyzer_init <-- not ok, or is it? OK run00003.mid:13866 events, 0.06s adc_calib_exit adc_summing_exit scaler_exit analyzer_exit
378	22 May 2007	Stefan Ritt	Bug Report	analyzer_init called by odb_load
The reason to call analyzer_init in odb_load is the following: Assume you run the analyzer offline, analyzing many files in series. Then assume that you have /Experiment/Run Parameters, which is actively used by the analyzer (like beam settings etc.). In this case you do a db_open_record() to map /Experiment/Run Parameters to the exp_param C structure. For this mapping to work, the ODB structure and the C structure have to be exactly the same. Now assume that you changed your run parameters over time, like you added some comment later. Now you want to analyzer several runs, some before and some after the modification. Both sets have a different structure in /Experiment/Run Parameters, which is a problem, since the compiled analyzer can only have a single C structure. My "poor" solution was to call analyzer_init after each loading of the ODB from the *.mid file. The db_create_record() call matches the C structure to the ODB structure by modifying the ODB structure if necessary. So if you added one parameter later, this (modified) structure gets loaded by odb_load, but then it gets adjusted in analyzer_init(). I understand now that this case might not happen so often, and you are more bothered by the fact that analyzer_init gets called several time. There must however be a hook for offline analysis that the user code can correct the ODB structure. So I propose to add a flag to analyzer_init, such as INT analyzer_init(BOOL bFirst) { } If bFirst equals TRUE, the function got called from mana_init(), if FALSE, it got called from odb_load. Then you can put code like INT analyzer_init(BOOL bFirst) { if (bFirst) { p = malloc() ... } } If you agree, I will modify the code and commit the change. - Stefan
379	22 May 2007	Randolf Pohl	Bug Report	analyzer_init called by odb_load
Thanks for the quick reply, Stefan. Please don't change anything in the code unless you find it really important. I guess changing the analyzer_init prototype will break a lot of code out there? In fact, I think I do understand this behavior now. And even without your suggested fix there is a simple workaround: I add a static variable to my analyzer_init.cxx file, and do something similar to your bFirst fix. In conclusion, commit your fix if it does not harm others. Postpone this commit to a future new version of midas which breaks a lot of things anyway... A last question, for me to understand: Why not call db_open_record in ana_begin_of_run then? Cheers, Randolf
380	22 May 2007	Stefan Ritt	Bug Report	analyzer_init called by odb_load
> Thanks for the quick reply, Stefan. > > Please don't change anything in the code unless you find it really important. I guess > changing the analyzer_init prototype will break a lot of code out there? > > In fact, I think I do understand this behavior now. > And even without your suggested fix there is a simple workaround: I add a static > variable to my analyzer_init.cxx file, and do something similar to your bFirst fix. > > In conclusion, commit your fix if it does not harm others. Postpone this commit to a > future new version of midas which breaks a lot of things anyway... > > A last question, for me to understand: Why not call db_open_record in > ana_begin_of_run then? I fully agree with you that db_open_record would better go into ana_begin_of_run (and analyzer_init not being called in odb_load), and I fully agree with you that changing the code would break many experiments. ;-) So I guess we leave it as it is right now as you suggested.
401	20 Aug 2007	Konstantin Olchanski	Bug Report	how to handle end of run?
I am having problems with handling the end-of-run situation in my midas frontend. I have a device that continuously sends data (over USB) and I read this data in my "read_event" function. Everything is good until the end-of-run, at which time this happens: 0) mfe.c calls my read_event() to read the data (loop until the end-of-run transition) 1) mfe.c calls my end_of_run() 2) here, I tell the device "please stop sending data" 3) all seems good, but wait!!! 4) there is all this data generated between step 0 and step 2 still sitting inside the device and it has nowhere to go: the run is ended, the output file is closed, my read_event() will never be called ever again (well, until the next run). It seems to me mfe.c needs to have one more function, something like "pre_end_of_run()" that works like this: 0) mfe.c calls my read_event() to read the data (loop until the end-of-run transition) 1) mfe.c calls pre_end_of_run(), here I tell the device to stop sending data 2) mfe.c calls read_event() for the very last time, to give me the opportunity to read and send away any data I still may have. 3) mfe.c calls the end_of_run(). The run is truely finished. Any thoughts? K.O.
405	03 Sep 2007	Stefan Ritt	Bug Report	how to handle end of run?
> I am having problems with handling the end-of-run situation in my midas > frontend. I have a device that continuously sends data (over USB) and I read > this data in my "read_event" function. > > Everything is good until the end-of-run, at which time this happens: > 0) mfe.c calls my read_event() to read the data (loop until the end-of-run > transition) > 1) mfe.c calls my end_of_run() > 2) here, I tell the device "please stop sending data" > 3) all seems good, but wait!!! > 4) there is all this data generated between step 0 and step 2 still sitting > inside the device and it has nowhere to go: the run is ended, the output file is > closed, my read_event() will never be called ever again (well, until the next run). > > It seems to me mfe.c needs to have one more function, something like > "pre_end_of_run()" that works like this: > 0) mfe.c calls my read_event() to read the data (loop until the end-of-run > transition) > 1) mfe.c calls pre_end_of_run(), here I tell the device to stop sending data > 2) mfe.c calls read_event() for the very last time, to give me the opportunity > to read and send away any data I still may have. > 3) mfe.c calls the end_of_run(). The run is truely finished. > > Any thoughts? You can achieve the desired functionality without changing mfe.c: 0) mfe.c calls read_event 1) mfe.c calls end_of_run. Your end_of_run tells the device to stop data and flushes the remaining data. At this point you have to re-make actually a part of the mfe.c functionality, but basically you need a bm_compose_event() and a bm_send_event(), so just a few lines of code. If you want to have the final event number right in your equipment, you also need to update eq->events_sent accordingly. Given the fact that 99% of the experiments do not need this functionality, I propose that we keep mfe.c and you add the few lines of code into your user part of the specific frontend. Stefan
408	08 Oct 2007	Carl Metelko	Bug Report	Error in data format- ending blocks on 32bit boundary x86_64
Hi, I found that midas banks can be given an extra 32 bits of zeros when trying to keep to 32bit boundary on my x86_64. This can be fixed by changing (in midas.h) #define ALIGN8(x) (((x)+7) & ~7) to #define ALIGN8(x) (((x)+3) & ~3) Is there any bad consequences doing this?
409	08 Oct 2007	Stefan Ritt	Bug Report	Error in data format- ending blocks on 32bit boundary x86_64
> Hi, > I found that midas banks can be given an extra 32 bits of zeros when > trying to keep to 32bit boundary on my x86_64. > > This can be fixed by changing (in midas.h) > #define ALIGN8(x) (((x)+7) & ~7) > to > #define ALIGN8(x) (((x)+3) & ~3) > > Is there any bad consequences doing this? Yes. ALIGN8 means 'align to 8-byte boundary' (64-bit), and if you change that, you break the code at various locations. Furthermore, 8-byte aligned access is faster on x86_64 than 4-byte aligned access, so you will get a performance penalty. If course if you have very many small banks, the zero padding can cause some overhead, but in that case you could combine some data into a single bank.
410	11 Oct 2007	Stefan Ritt	Bug Report	_syscall0 not available on gcc 4.1.1
Dear Stephan, I am writting on behalf of the LiBeRACE collaboration at Berkeley/Livermore. We are trying to use midas (2.0.0) for our acquisition system. However we had some difficulties to compile it on LINUX Fedora Core 6 with gcc 4.1.1 I tried to trace back the problem and I found that _syscall0 in system.c is actually an obsolete call (since gcc 4.x apparently). Playing with assembly language being behond my competence, I would like to know if you ever came across this situation recently and if you have any suggestion(s). With my best regards Julien GIBELIN ------------------------------------------------------ GIBELIN Julien Lawrence Berkeley National Laboratory Nuclear Science Division One Cyclotron Rd. MS 88R0192 BERKELEY, CA 94720-8101 Tel: +1 (510) 495-2695 Fax: +1 (510) 486-7983 ------------------------------------------------------
411	11 Oct 2007	Stefan Ritt	Bug Report	_syscall0 not available on gcc 4.1.1
> Dear Stephan, > > I am writting on behalf of the LiBeRACE collaboration > at Berkeley/Livermore. > > We are trying to use midas (2.0.0) for our acquisition system. > However we had some difficulties to compile it on LINUX Fedora > Core 6 with gcc 4.1.1 > I tried to trace back the problem and I found that _syscall0 in > system.c is actually an obsolete call (since gcc 4.x apparently). > Playing with assembly language being behond my competence, I would > like to know if you ever came across this situation recently and > if you have any suggestion(s). The '_syscall0' function call was replaced by 'syscall' in SVN revision 3583. I would recommend that you switch to the current SVN version (see http://ladd00.triumf.ca/~daqweb/doc/midas/html/quickstart.html on how to obtain the SVN version). If the problem still persists, please let us know. - Stefan
433	18 Feb 2008	Konstantin Olchanski	Bug Report	mhttpd safari 3.0.4 redirect problem
I now encountered a new problem with mhttpd - I connect using the Safari 3.0.4 browser, go to the "Programs" page, press the button "Start feplc" (or any other "start" button) and instead of starting this program, I get an error in the browser, funny entries in ODB in "/Programs", corrupted ODB and a spew of messages in the midas log file about the mess. ODB has to be reloaded from backup to recover. Investigation shows that the culprit is odd bahaviour of the "redirect()" function: /* start command / if (getparam("Start")) { /* for NT: close reply socket before starting subprocess */ - redirect2("?cmd=programs"); + redirect2("/?cmd=programs"); The version without "/" makes Safari explode - it appends the "?cmd..." stuff to the existing URL, which already has the "?cmd..." tags, making a mess. Firefox accepts either version. ODB corruption happens here: sprintf(str, "/Programs/%s/Start command", name); - db_get_value(hDB, 0, str, command, &size, TID_STRING, TRUE); + db_get_value(hDB, 0, str, command, &size, TID_STRING, FALSE); if (command[0]) { ss_system(command); It looks like db_get_value() would corrupt ODB if given funny "str". When Safari explodes, funny strings are generated. The simple fix is to replace "TRUE" with "FALSE", then at least db_get_value() does not try to make bogus entries in ODB. The "Stop" command has the same problem, but does not currupt ODB - there is no db_get_value() in that code path. I am reporting this "fresh" as I made one of our daq systems work again. I did not investigate the history of changes to this "redirect" command (perhaps it was broken in the recent reorganisation of midas urls?), what versions of Safari work or not. K.O.
434	18 Feb 2008	Konstantin Olchanski	Bug Report	potential memory corruption in odb,c:extract_key()
It looks like ODB function extract_key() will overwrite the array pointed to by "key_name" if given an odb path with very long names (as seems to happen when redirection explodes in the Safari web browser, via db_get_value(TRUE) via mhttpd "start program" button). All callers of this function seem to provide 256 byte strings, so the problem would not show up in normal use - only when abnormal odb paths are being parsed. Proposed solution is to add a "length" argument to this function. (Actually ODB path elements should be restricted to NAME_LENGTH (32 bytes), right?). K.O.
435	18 Feb 2008	Exaos Lee	Bug Report	Great! But I failed to run it. :(
I encountered the error message as the following: Traceback (most recent call last): File "runtest.py", line 42, in <module> import midas File "/opt/MIDAS.PSI/Resources/PyMIDAS/pymidas/midas/__init__.py", line 140, in <module> cmidas = ctypes.cdll.LoadLibrary('libmidas.so') File "/usr/lib/python2.5/site-packages/PIL/__init__.py", line 431, in LoadLibrary File "/usr/lib/python2.5/site-packages/PIL/__init__.py", line 348, in __init__ OSError: /opt/MIDAS.PSI/Versions/Current/lib/libmidas.so: undefined symbol: cam16i_rq Compiling the MIDAS library using NEED_SHLIB=1 causes the same "undefined reference" error. But it can be fixed by adding "-shared" to CFLAGS in the Makefile. Though the libmidas.so can be successfully created, the above error is still there. Can anybody help me? Environment: Platform: Ubuntu Linux 7.10 with gcc 4.1 MIDAS version: 2.0.0, svn-4106 Python version: 2.5.1

Goto page Previous 1, 2, 3 ... 96, 97, 98 ... 148, 149, 150 Next

ELOG V3.1.4-2e1708b5