Re: Version of GCC to use?, posted by Stefan Ritt on Mon May 9 21:17:29 2005
|
> Ok, now I see the issue - the tar extract created the mxml directory in the root (not
> under the created directory elog-2.5.9). Is there a reason why these includes are not
> placed in the src dir like the regex.h/.c include?
Yes. I use these files in several other projects as well, and want to maintain only a
single copy. So I have
elogd-x.x.x/
elogd-x.x.x/src/
....
mxml/
mxml/strlcpy.h
mxml/strlcpy.c
mxml/mxml.c
mxml/mxml.c
...
other-project-x.x.x/
other-project-x.x.x/
So both elogd and "other-project" can use strlcpy.c and mxml.c. If I would copy it to
elogd-x.x.x/src and fix a bug there, "other-project" would use a separate copy and not
profit from the bug fix. So I would have to mainain verious copies of the same file, which
make things complicated. I compile everything also under windows, so I cannot use soft
links. If there is a better way of how to do it, please let me know. |
Re: Version of GCC to use?, posted by Stefan Ritt on Mon May 9 21:22:46 2005
|
[ritt@pc5082 /tmp]$ tar -xzvf elog-2.5.9-2.tar.gz
elog-2.5.9/
elog-2.5.9/doc/
elog-2.5.9/doc/adminguide.html
...
mxml/
mxml/mxml.c
mxml/strlcpy.c
mxml/mxml.h
mxml/strlcpy.h
[ritt@pc5082 /tmp]$ cd elog-2.5.9
[ritt@pc5082 elog-2.5.9]$ make
gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -o elog src/elog.c
gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -c -o regex.o src/regex.c
... skipping warnings ...
gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -c -o mxml.o ../mxml/mxml.c
gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -c -o strlcpy.o ../mxml/strlcpy.c
gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -I../mxml -o elogd src/elogd.c regex.o
mxml.o strlcpy.o
gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -o elconv src/elconv.c
[ritt@pc5082 elog-2.5.9]$
--------------
No undefined functions here. I guess you have an old Makefile? Just use the complete tar
package from the last version. |
Re: Version of GCC to use?, posted by Steve Jones on Mon May 9 23:30:11 2005
|
> [ritt@pc5082 /tmp]$ tar -xzvf elog-2.5.9-2.tar.gz
> elog-2.5.9/
> elog-2.5.9/doc/
> elog-2.5.9/doc/adminguide.html
> ...
> mxml/
> mxml/mxml.c
> mxml/strlcpy.c
> mxml/mxml.h
> mxml/strlcpy.h
> [ritt@pc5082 /tmp]$ cd elog-2.5.9
> [ritt@pc5082 elog-2.5.9]$ make
> gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -o elog src/elog.c
> gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -c -o regex.o src/regex.c
> ... skipping warnings ...
> gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -c -o mxml.o ../mxml/mxml.c
> gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -c -o strlcpy.o ../mxml/strlcpy.c
> gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -I../mxml -o elogd src/elogd.c regex.o
> mxml.o strlcpy.o
> gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -o elconv src/elconv.c
> [ritt@pc5082 elog-2.5.9]$
>
> --------------
> No undefined functions here. I guess you have an old Makefile? Just use the complete tar
> package from the last version.
Ok, now I have it. Old Makefile because I had to perform some deletions to make "make" work
right under Solaris. Basically, I took out the ifdef structures - "make" was blowing up on
these. Everything now compiles perfectly -- don't change anything. Thanks for that last pointer.
Steve |
Logbook locking issue, posted by Steve Jones on Tue May 17 21:38:36 2005
|
Stefan, any ideas on this problem?
Quote: | Our eLog is set to create logbook entry locks and after 30minutes prevent one from re-editing an entry, thus forcing a REPLY to be created.
SCENARIO: When an *attempt* is made to edit a logbook after the 30minute timer, one gets the message that EDITING is prevented and to use the browser "Back" button.
PROBLEM: The display now shows that particular entry to be locked, even though the attempt to edit was blocked. It appears that the lock flag is set prior to the "Edit" attempt being blocked and thus the lock flag is never "unset". |
|
reverse sort option does not work for quick filter, posted by Heiko Scheit on Wed May 18 14:12:02 2005
|
The 'reverse sort' option does not work for quick filter searches. In the
URL there is always written 'reverse=0'. For normal 'Find' it works OK. |
elog crashes when admin tries to register new users, posted by Heiko Scheit on Wed May 18 14:18:07 2005
|
When pasting the URL for the registration of new users (with 'Self register = 3') elog
crashes with segmentation fault. I don't have the time currently to give you more
debuging information but maybe you can have a look the same. It crashes after
the user is registered. The Email is sent, too. |
Re: Logbook locking issue, posted by Steve Jones on Wed Jun 1 16:14:22 2005
|
Steve Jones wrote: | Stefan, any ideas on this problem?
Quote: | Our eLog is set to create logbook entry locks and after 30minutes prevent one from re-editing an entry, thus forcing a REPLY to be created.
SCENARIO: When an *attempt* is made to edit a logbook after the 30minute timer, one gets the message that EDITING is prevented and to use the browser "Back" button.
PROBLEM: The display now shows that particular entry to be locked, even though the attempt to edit was blocked. It appears that the lock flag is set prior to the "Edit" attempt being blocked and thus the lock flag is never "unset". |
|
Hmmm, I don't seem to be seeing any responses - is email being generated? |
Re: Logbook locking issue, posted by Stefan Ritt on Wed Jun 1 16:33:54 2005
|
Sorry about my unusual slow response, but I'm pretty busy these days. I hope I will be able to address this problem in a two weeks from now.
Steve Jones wrote: | Stefan, any ideas on this problem?
Quote: | Our eLog is set to create logbook entry locks and after 30minutes prevent one from re-editing an entry, thus forcing a REPLY to be created.
SCENARIO: When an *attempt* is made to edit a logbook after the 30minute timer, one gets the message that EDITING is prevented and to use the browser "Back" button.
PROBLEM: The display now shows that particular entry to be locked, even though the attempt to edit was blocked. It appears that the lock flag is set prior to the "Edit" attempt being blocked and thus the lock flag is never "unset". |
|
|