ELOG Midas

Fragmented polled events have been implemented in SVN revision 3625.
Fragmentation is a method of breaking down large (>MB) events into smaller
pieces and send them through the shared memory buffers, reassembling them at the
output. In the past this was only possible for periodic events (such as large
histograms read out once every few seconds), but now this is also possible for
polled events.

351

26 Feb 2007

Stefan Ritt

Info

Usage of event channel for improved throughput

Starting from SVN revision 3642, sending events from the front-end has been revised.

Since long time ago, there is a special TCP socket established between any front-end and the mserver which can be used to bypass the midas RPC layer completely and purely send events. There was a #define USE_EVENT_CHANNEL but to my knowledge nobody used it.

While optimizing data throughput for the MEG experiment, I revisited this mechanism and got it finally working. Here are some benchmark tests made with the produce program on two dual-CPU machines running on Gigabit Ethernet:

Using normal RPC socket:

event size    speed [MB/sec] CPU usage front-end  CPU usage server
==================================================================
    40          3            22                   100                
  1000         44            25                   100
100000        101            14                    50

Using new event socket:

event size    speed [MB/sec] CPU usage front-end  CPU usage server
==================================================================
    40         12            100                   34                
  1000         99            58                    59
100000        101            14                    43

As can be seen, the CPU load on the server drops significantly for smaller events since the processing time per event is reduced. If the transfer was limited by the server, the throughput goes up significantly. For large events the bottleneck on the server side is the memcpy of events, so no big improvement is visible. The saved CPU time however can be used to analyze more events for example.

The event socket is now enabled by default in the front-end by setting

rpc_mode = 1

in mfe.c and should be checked carefully in various experiments. There is a small chance that events get stuck in the buffer cache on the server side at the end of the run, in which case they would show up as the first events of the next run. I know that this problem happened in some experiment before, but that must have been unrelated to the rpc_mode. So please check again and report any problem with the new rpc_mode.

RFC- support for writing to removable hard disk storage

In the MEG experiment, we simply installed 100TB of RAID disks and don't need to change anything Wink

But seriously, you are right that such a system might be beneficial. I propose to extend the current logger code to switch disks. In the current tr_start() funciton in mlogger, the code checks for "subdir_format" to create separate subdirectories like once per week. One could extend this code in the following way:

- Add an array of strings and name it "Path", such as

/dev/sda1/datadir/
/dev/sdb1/datadir/

- On each stop of the run, check if the current disk has enough space for one more run. Take either the "Byte limit" of that channel, or the actual size of the last run and multiply it by two or so. If the disk is "almost full", switch to the next array element in "Path". Append the file name, such as "/dev/sda1/datadir/run1234.mid" and put this into "Current filename" as a feedback for the user. Now write to the new disk/file.

- Add as string like "Execute on switch", which gets called after you switched to the next disk. This shell script can then handle the un-mounting of the full disk, notify the user etc. This is similar to the "/Programs/Execute on start run" in the ODB, but it gets only called if you switch the disk.

RFC- history system improvements

I agree to what you propose. I'm pretty sure you are right in getting a significant improvement in readout speed
of the history system. So far there was no big request for improving the history system, since the performance in
the experiments I was involved in was good. In MEG for example, we have ~20MB of history data per day, and all
plots even going back some months can be made in a couple of seconds. Have a look for example at

http://midas.psi.ch/megon00/HS/PCS/Pressures.gif?hscale=1843200&hoffset=-5068800

This plot stretches over two weeks and involves ~500 MB of history data, and is prepared in a couple of seconds.
The key question here is how big the disk cache of the OS is. The above plot does not read all 500 MB, but skips
many data points in order to obtain ~1000 data points (one per pixel) for the requested period. To find these
data points, it reads and scans the history index files (yymmdd.idx), which are only a few percent of the
yymmdd.hst data files. The index file contains only the time stamp, the event id and the location of the event in
the *.hst file. Scanning the index file is as efficient as scanning a history file with a single variable. Now
comes the access of the history file. For ~1000 data points, 1000 locations have to be read. This requires
reading in the FAT table for the history file and accessing the sector clusters containing the data. In worst
case one has to read 1000 clusters. With a cluster size of 2kB this will be 2MB of data, something which can be
read very quickly. On the MEG system I observe that the first history plot takes about 5 seconds, while all
consecutive plots take about 1 second. This indicates that the FAT information is cached by the OS. This depends
of course as you indicated correctly on how much memory is available for disk caching, how many processes are
running etc. and will finally determine how fast your history access will be.

So if you implement your proposed new scheme, please consider the following:

- Scanning a single variable file is about the same as scanning the current index file. You save however the
access to the data file. If you plot several variables together, you have to access several "single variable
files", so your access time scales with the number of variables. In the current system, it's likely that
different variables from the same event are located in the same cluster. So you have to read the history file
once for each variable, but after the first variable the sectors of interest are very likely cached by the OS. So
I would estimate that the break-even point is about 2-3 variables. I mean if you read more that three variables,
your proposed method might get slower than the current one. This is of course not the case if there are very many
events in the history file. In that case the index file might be much bigger, since it gets a new entry if *any*
variable in an event changes. If all index file together are bigger than you disk cache, the system will become
slow (and I guess that's what you see). In MEG, the index file is about 1MB per day, so a few weeks fit easily
into the disk cache.

- In order not to get too much data, the history system needs fine tuning. Each slow control system class driver
as an "update threshold", which is used to determine if a variable has "changed". For some noisy channels, it
might be worth to set the threshold at 3 sigma of the noise level (RMS). This can reduce your history data
dramatically. For some equipment, you even might consider to define a minimum update period. This is done via
"/Equipment/<name>/Common/Log history". If that variable is set to 10, the time between two consecutive history
records is at least 10 seconds. For some temperatures for example it might make sense to set this even to one
minute or so, depending on how fast your temperatures change.

- If you implement a per-variable history, you probably have to use the per-event hot link in the ODB. Otherwise
you would exceed the number of hot links MAX_OPEN_RECORDS which is currently 256. If you then get a hot link
update, you have to check manually which variable(s) have changed in log_history() in mlogger.c

- Before you actually go and implement the full system, I would write some small test code to "simulate" the new
scheme. Write some dummy files with the full data you expect in the ALPHA experiment and see what the improvement
is under realistic conditions. Only if you see a big improvement it's worth to implement the full code. Test this
on various machine to get a better overview. Maybe it's worth testing different file systems and cluster sizes as
well.

- If there is an improvement, I'm more than happy to replace the current history code in midas. It might however
not be clean to have a heterogeneous history system, where some files are in the old format and some in the new.
It might be better to write a little conversion routine which converts the old format into the new one, even
omitting records where single variables did not change. This conversion could be even put into the standard
mlogger code and is executed automatically if the logger is started first and finds some old data files.

Even if the speed improvement is not so big, one will certainly win a lot on disk file size (like if only one
variable out of 100 changes). This will probably make it worth to implement anyhow.

RFC- support for writing to removable hard disk storage

We stopped using tapes at Los Alamos a while ago.  The model we use is:

write data with mlogger to a local RAID system.  This is NFS mounted read only on teh analysis machines, and
becomes the working copy for most tasks.  Copy data to external hardrives.  We have been using USB.  The USB
system is sometime a little flaky (lnux 2.4.21-7, so we have a computer dedicated to this task.  The USB driver
can be reloaded, or if the user is not so knowledgeable, the copmuter can be rebooted.  users on this computer
have sudo privs, so they can format hard drives.  The disks are inserted into boxes while in use, and stored on
a shelf for data archival, so we don't have a lot of enclosures.

I use the automounter to mount and unmount the drives.  With a 10 second timeout, the user needs only to wait a
few seconds before unplugging the disk.  (cat /proc/mounts allows them to check if they want.) dmesg allows
them to find the drive letter.  This works for any device which appears later as a SCSI disk.  The automounter
manages /mnt/usb for vfat formatted devices, and /mnt/usbl for ext3 formatted devices (preferred for data
archiving).

autofs config files are:

/etc/auto.usb

# This is an automounter map and it has the following format
# key [ -mount-options-separated-by-comma ] location
# Details may be found in the autofs(5) manpage
 
*       -fstype=auto,nosuid,nodev,umask=0000,noatime    :/dev/&

/etc/auto.usbl

# This is an automounter map and it has the following format
# key [ -mount-options-separated-by-comma ] location
# Details may be found in the autofs(5) manpage
 
*       -fstype=auto,nosuid,nodev       :/dev/&

/etc/auto.master contains

/mnt/usb                /etc/auto.usb  --timeout=10
/mnt/usbl               /etc/auto.usbl --timeout=10


John.

> At triumf, we are developing a system to use removable hard drives to store data collected by midas 
> daq stations. The basic idea is to replace storage on 300 GB DLT tapes with storage on removable 
> esata, usb2 or firewire 750 GB hard drives.
> 
> To minimize culture shock, we stay as close as possible to the "tape" paradigm. Two removable disks 
> are used in tandem. Data is written to the first removable disk until it is full. Then midas automatically 
> switches to the second disk and asks the operator to replace the full disk with a blank disk. Similar to 
> handling tapes, the operator takes the full disk and stores it on the shelf (offline); takes a blank disk 
> and connects it to the computer. To read data from one of the disks, the operator takes the disk from 
> the shelf and connects it to the daq computer or to some other computer equipped with a compatible 
> removable storage bay. The full data disks are mounted read-only to prevent accidental data 
> modifications.
> 
> Two pieces of software are needed to implement this system:
> 
> 1) midas support for switching to alternate output disks as they become full. Data could be written to 
> the removable disk directly by the mlogger (no extra data copy on local disks) or by the lazylogger 
> (mlogger writes the data to the local disk, then the lazylogger copies it to the removable disk). Writing 
> directly to the removable disk is more efficient as it avoids the one extra data copy operation by the 
> lazylogger.
> 
> 2) a user interface utility for mounting and dismounting removable disks. Handling of removable disks 
> cannot be fully automatic: before unplugging a removable disk, the user has to inform the system; after 
> connecting a removable disk, the user has to tell the system to mount it read-only (for existing data), 
> read-write (to add more data) or to initialize a blank disk (fdisk+mkfs). (Also, some SATA interfaces do 
> not implement automatic hot-plug: they have to be manually told "please look for new disks").
> 
> We are presently evaluating various internal SATA hot-plug enclosures. We evaluated external eSATA 
> and USB2 enclosures and decided not to use them: while the performance is adequate, presence of 
> extra bulky components (eSATA and USB cables, non-standardized power bricks) and the extra cost of 
> eSATA and USB hard drive enclosures makes them unattractive.
> 
> I am open to suggestions and comments. I am most interested in hearing which data path (mlogger or 
> the lazylogger) would be most useful for other users.
> 
> K.O.

RFC- history system improvements

While running the ALPHA experiment at CERN, we stressed and broke the MIDAS history system. We
generated about 0.5 GB of history data per day, and this killed the performance of the history plot
system in mhttpd - we had to wait for *minutes* to look at any plots of any variables.

One way to address this problem could be by changing the way ALPHA slow controls data is collected.

Another way to address this problem could be by improving the midas history system by removing
some of the existing limitations and inefficiencies, enabling it to handle the ever increasing data
volumes we keep throwing at it.

I feel the second approach (improving midas) is more useful in general and it appears that big
improvements can be made by small modifications of existing code. No rewrites of midas are required.
Read on.

Issue 1: in the mlogger, history is recorded with fairly coarse granularity.

For an equipment, if any varible changes, *all* variables for that equipment are written into the history
file.

Historically, this worked fairly well for experiments with low data rates (a few history changes per
minute) and with variables equally distributed between different equipments. But even for a modest
sized experiment like TRIUMF-E614-TWIST, recording many variables when only one has changed has
been a visible inefficiency. Current experiments wish to record more history data more frequently, but
even with latest and greatest hardware, in the case of ALPHA, this inefficiency has become a
performance killer.

One could solve this problem by refactoring the data (one variable per equipment/one equipment per
variable). I find this approach inelegant and contrary to the "midas way" (whatever that is).

An alternative would be to change the mlogger to record history with per-variable granularity. When
one variable changes, only that variable is recorded. Preliminary examination of the existing code
indicates that history writing in the mlogger is already structured in a way that makes it easy to
implement, while the history reading code does not seem to need any changes at all.

Issue 2: all history data is recorded into a single file.

Again, this has worked well historically. In fact, until not so long ago, it was the only sane way to record
history data because operating systems could not efficiently write data into multiple files at the same
time. Insifficient data buffering, suboptimal storage allocation strategies - all leading to bad
performance. Latest Linux kernels have largely resolved all such issues.

The present problem arises when recording large amounts of history data (say 100 variables) and then
making a history plot of 1 variable. Because data for the one variable of interest is spread across the
whole file, effectively, the whole file has to be read into memory, data for 1 variable collected and data
for the other 99 variables skipped.

In this case, a speed up by a factor of 100 could be obtained by recording (say) one variable per history
file. (Yes, the history code does use "lseek", but the seek granularity of modern disks is very coarse and
in my tests, reading the whole file (streaming) is almost faster than seeking through it).

One has to be very careful when looking at these numbers and running benchmarks. Modern computers
with fast disks and large RAM performs very well no matter how history data is stored and organized.
Performance problems surface only under the load when running the production system, when the
disks are busy recording the main data stream and all RAM is consumed by user applications doing
data analysis.

The obvious solution to this problem is to record each variable into a separate data file. This will
require modifications to the history writing code in the mlogger and to the history reading code in
mhttpd, mhist & co.

An extra challenge in this tast is to minimize changes to the existing code and to keep compatibility
with the existing data files - new code should be able to read existing data files.

I propose to organize data into subdirectores:
history/equipmentNNN/variableVVV/YYMMDD.hst

This scheme does two good things for the history plotting in mhttpd:

1) note that mhttpd always plots one variable at a time, and the variables are addressed by equipment
(int) and variable name (string) (plus the array index). In the proposed scheme, the code would know
exactly which history file to open to get the data, no scanning of directories or seeking inside the
history file.

2) when setting up mhttpd history plots, the code can easily see what equipment and variables exist
and *ever existed*. The present code only examines the latest history file and cannot see variables that
have been deleted (or not yet written into the existing file). For example, one cannot see variables that
existed in the 2005 history but were removed (or renamed) in 2006. (Yes, it can be done by an expert
using mhist to examine the 2005 history files and odbedit to manually setup the history plots).

Over the next few weeks, I will proceed with implementing these two improvements: (1) mlogger write
history with per-variable granularity; (2) history file split into one-file-per-variable. If my initial
assessment is correct and the changes indeed are small, contained, non-intrusive and compatible with
existing history files, I will submit them for inclusion into mainline midas.

K.O.

RFC- support for writing to removable hard disk storage

At triumf, we are developing a system to use removable hard drives to store data collected by midas
daq stations. The basic idea is to replace storage on 300 GB DLT tapes with storage on removable
esata, usb2 or firewire 750 GB hard drives.

To minimize culture shock, we stay as close as possible to the "tape" paradigm. Two removable disks
are used in tandem. Data is written to the first removable disk until it is full. Then midas automatically
switches to the second disk and asks the operator to replace the full disk with a blank disk. Similar to
handling tapes, the operator takes the full disk and stores it on the shelf (offline); takes a blank disk
and connects it to the computer. To read data from one of the disks, the operator takes the disk from
the shelf and connects it to the daq computer or to some other computer equipped with a compatible
removable storage bay. The full data disks are mounted read-only to prevent accidental data
modifications.

Two pieces of software are needed to implement this system:

1) midas support for switching to alternate output disks as they become full. Data could be written to
the removable disk directly by the mlogger (no extra data copy on local disks) or by the lazylogger
(mlogger writes the data to the local disk, then the lazylogger copies it to the removable disk). Writing
directly to the removable disk is more efficient as it avoids the one extra data copy operation by the
lazylogger.

2) a user interface utility for mounting and dismounting removable disks. Handling of removable disks
cannot be fully automatic: before unplugging a removable disk, the user has to inform the system; after
connecting a removable disk, the user has to tell the system to mount it read-only (for existing data),
read-write (to add more data) or to initialize a blank disk (fdisk+mkfs). (Also, some SATA interfaces do
not implement automatic hot-plug: they have to be manually told "please look for new disks").

We are presently evaluating various internal SATA hot-plug enclosures. We evaluated external eSATA
and USB2 enclosures and decided not to use them: while the performance is adequate, presence of
extra bulky components (eSATA and USB cables, non-standardized power bricks) and the extra cost of
eSATA and USB hard drive enclosures makes them unattractive.

I am open to suggestions and comments. I am most interested in hearing which data path (mlogger or
the lazylogger) would be most useful for other users.

K.O.

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.

Latest FC5 Compilation attempt

On February 13, 2007, gcc 4.1.2 was released.
I checked this version, and it compiles midas successfully,

GCC 3                    - OK
GCC 4.0                  - OK
GCC 4.1.0 and 4.1.1      - Bad
GCC 4.1.2                - OK
GCC 4.2                  - This is not released. Development version of GCC 4.2 is OK

svn and "make indent" trashed my svn checkout tree...

Fuming, fuming, fuming.

The combination of "make indent" and "svn update" completely trashed my work copy of midas. Half of 
the files now show as status "M", half as status "C" ("in conflict"), even those I never edited myself (e.g. 
mscb firmware files).

I think what happened as that once I ran "make indent", the indent program did things to the source 
files (changed indentation, added spaces in "foo(a,b,c); --> foo(a, b, c);" etc, so now svn thinks that I 
edited the files and they are in conflict with later modifications.

I suggest that nobody ever ever ever should use "make indent", and if they do, they should better 
commit their "changes" made by indent very quickly, before their midas tree is trashed by the next "svn 
update".

And if they commit the changes made by "make indent", beware that "make indent" is not idempotent, 
running it multiple times, it keeps changing files (keeps moving some dox comments around).

Also beware of entering a tug-of-war with Stefan - at least on my machines, my "make indent" seems 
to produce different output from his.

Still fuming, even after some venting...
K.O.

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

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

Problem solved by Re-define _syscall0(...)

Exaos Lee wrote:

Maybe it's not the perfect way, but it works. Smile

I changed it to:

#ifdef OS_UNIX

   return syscall(SYS_gettid);

#endif                          /* OS_UNIX */
[/code1]

without any #define.

Does this work for you?

- Stefan

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.

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.

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

Problem solved by Re-define _syscall0(...)

OK, I searched and found that my kernel doesn't support "_syscall0" any more. So I patched the system.c as the following (from line 954):


#if defined(OS_DARWIN)
// blank
#elif defined(OS_LINUX)

#include <sys/syscall.h>
#include <unistd.h>
#undef _syscall0
#define _syscall0(type, name) \
  type name(void) \
  {\
    return syscall(__NR_##name); \
  }

_syscall0(pid_t,gettid)
#endif

My kernel version:

exaos@memes midas>$ uname -a
Linux memes 2.6.17-10-generic #2 SMP Tue Dec 5 22:28:26 UTC 2006 i686 GNU/Linux

Maybe it's not the perfect way, but it works. Smile

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 ...

Compiling failed with SVN3562 under Ubuntu 6.10

The error log is as the following:

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:958: warning: data definition has no type or storage class
src/system.c:958: warning: type defaults to �int� in declaration of �_syscall0�
src/system.c: In function �ss_gettid�:
src/system.c:1005: warning: implicit declaration of function �gettid�
src/system.c: In function �ss_suspend_init_ipc�:
src/system.c:2948: warning: pointer targets in passing argument 3 of �getsockname� differ in signedness
src/system.c: In function �ss_suspend�:
src/system.c:3414: warning: pointer targets in passing argument 6 of �recvfrom� differ in signedness
src/system.c:3441: warning: pointer targets in passing argument 6 of �recvfrom� differ in signedness
make: *** [linux/lib/system.o] &#38169;&#35823; 1

The error might be here:

void ss_force_single_thread()
{
   _single_thread = TRUE;
}

#if defined(OS_DARWIN)
// blank
#elif defined(OS_LINUX)
_syscall0(pid_t,gettid);
#endif

INT ss_gettid(void)

I have no idea about the usage of _syscall0(...).

Large files under Windows XP

Hello,

We have problems analyzing large files under Windows XP. For small file sizes,
everything is ok. We have events of 2.8 MB each, and we can read ~30 events per
second. But if the file gets larger than typically 600-800 MB, then access
becomes very slow, about 1 event per second. This is not the case under Linux,
where it stays at 30 Hz (~90 MB/sec). 

Looking at the low level file access, it is obvious that this has nothing to do
with midas, this problem can be reproduced with a simple program reading chunks
of 3MB from a 1GB file. The Windows XP file system is NTFS, default formatting.
Does anyone else have observed a similar problem or maybe even have some
suggestions? Unfortunately many people here want to analyze midas data under
Windows...

Stefan Ritt

Goto page Previous 1, 2, 3 ... 118, 119, 120 ... 134, 135, 136 Next

ELOG V3.1.4-2e1708b5