Hi,
From www.gtk.org, this link following doesn't work : http://tfdec1.fys.kuleuven.ac.be/~michael/fpc-linux/gtk/gtk.html

Anyone could know another usable link ?

Thanks,
Q.

http://www.freepascal.org/packages/gtk.html

Michael.

Where would you find GDBPAS? What is the address of the FTP site?

Mark Diener

we've tried several times to get this link fixed on www.gtk.org, but until now (since over 1 year!) all mails to their webmaster have been ignored...

- Sebastian

Where would you find GDBPAS? What is the address of the FTP site?

Afaik, it is packaged with the release, except for the FreeBSD beta?

Marco van de Voort ( or )

Marco and others:

The only "release" I have is the fpc-1.0.2-src.tar.gz.

What is use is the rpm-1.0.2-i386.rpm for redhat.

The GDBPAS does not appear anywhere in those archives.

So can you help me out a little and tell me a specific ftp site, a specific archive, and a specific
filename to look at so I can finally be successful in obtaining GDBPAS.

Please translate "Afaik"

Thanks so much:

Mark Diener

Where would you find GDBPAS? What is the address of the FTP site?

I don't think that we already distribute a Linux version of gdbpas. It is included in the Dos and win32 distributions though. You should be able to build your ownb copy of gdbpas under Linux by using the libgdb.a in the contrib directory of the ftp site. You can easily get to it using the link at the bottom of the download page on the website.

I don't know exactly how to build gdbpas using that lib though, but Pierre certainly does.

Jonas

??? When you build libgdb you get gdbpas too? And afaik gdbpas can be statically linked, as opposed to apps containing libgdb???

Pierre, could you comment on this?

What is GDBPAS? Does it replace or patch GDB 5.0?

gdbpas is a replacement for gdb. It's simply gdb with support for Pascal syntax.

Somebody mentioned GDBINT? What does this do? I found a GDBINT in my source tarball.

gdbint is a unit which provides an interface to libgdb.a. It should be possible to create some kind of gdbpas using this unit and libgdba.

Jonas

[Charset iso-8859-15 unsupported, filtering to ASCII...]

No, on 4.x. Afaik, patches for 5.x are not ready yet, or maybe not necessary. (the support would go into GDB in time)

Somebody mentioned GDBINT? What does this do? I found a GDBINT in my source tarball.

GDBINT is only the pascal interface to libgdb.a

Hello FPC developers:

So far, I have been unsuccessful at obtaining GDBPAS.

I was able to obtain libgdb.a from freepascal.org, but there is no information
related to GDBPAS in there.

Somebody please provide an absolute URL location for GDBPAS and I will be grateful.

Answers such as those given below are appreciated, but I am not successful by
any means with the information given below.

What is GDBPAS? Does it replace or patch GDB 5.0?

Somebody mentioned GDBINT? What does this do? I found a GDBINT in my source tarball.

This is not a pressing issue, but one I would like to resolve over the next couple of day.

Mark Diener

I know that I didn't give a reference. Before the last msg I quick checked all links if they contain a static gdbpas. They didn't. Since Stack (my online accounts) contain custom Linux versions (based on older distributions like Debian 2.0 and before), they probably wouldn't work on your place.

I tunnel into my mountain of CDR's tonight, if I can find oneon my "old linux installation" backup-CD

Marco van de Voort ( or )

Marco:

This message is for you.

You have helped in every way except for the following:

Please provide an absolute reference to an FTP site, a subdirectory, an archive, and a file name
to obtain GDBPAS.

Your answers were helpful in understanding GDBINT and LIBGDB.A.

I am still TOTALLY in the dark on how to get GDBPAS.

Remember, an ABSOLUTE reference to a physical point in space for GDBPAS is needed, not a casual or loose reference.

Thanks,

Mark Diener

Marco van de Voort wrote

Thanks for the attention.

I hope my request was not out of line. It was just getting weird to be talking about GDBPAS so much and never having a chance to get my hands on it.

Mark

FPC developers:

Here is a brain teaser.

Let us say we have two environments:

1) Normal BASH shell with prompt in TTY1 - The TERM environment variable will be set to linux
2) KDE Destktop - The TERM environment variable will be set to xterm

Under the non-x window environment, how do we fork() / execlp( ) another process so that the new child process
will use a different Ttty console to output its writeln( ) information to.

Under KDE, I can execute a fork() with execlp( ) and the command line will be as follows 'konsole -e /bin/application arg1'

The net effect of this is that the parent process continues in its own console window and the child process will execute
in a separte console window. The input/output of each process is now separate to each window.

Under non-xwindows environments, .i.e. normal bash shell, How do we fork() / exec( ) a process so that it will be assigned a different TTY or some other means of having a separate console for each process.

What this also means that the login process for a given TTY is skipped or avoided so the processes that are started from
the runlevel 3 inittab file can spawn processes that will take over a given console.

This is different that just logging into a bunch of different consoles and running each process on a given console. This is where the code is assigning processes to consoles.

Any help would be appreciated.

Mark Diener

under bash, one would type:

command args >/dev/ttyX 2>&1 </dev/ttyX &

or under csh

command args >& /dev/ttyX </dev/ttyX

(replace X with the terminal number)

The /dev/ files need the correct permissions, of course.

under FPC you would do the following;
  fork
  if pid=0 then
     // Child
    begin
    // Same effect as below may be gotten with dup2() !!
    Close(input);
    Close(output);
    Close(stderr);
    Assign(Input,'/dev/ttyx');
    Assign(output,'/dev/ttyx');
    Assign(stderr,'/dev/ttyz');
    Reset(input);
    Rewrite(output);
    Rewrite(stderr);
    Execlp('command','args')
    end
  else
    begin
    // Parent
    end;

You'd better do that, yes.

I hope the above helps.

Michael.

Does anyone know where the best reference for Signals is?

man signal ? :-)

Does anyone know where the best reference for Signals is?

Inside linux.pp, there are a variety of signals defined that I can hook using sigaction( )

SIGHUP - Hangup
SIGINT - ???
SIGQUIT - A request to terminate ?
SIGILL - ???
SIGTRAP - Trap What
SIGABRT - A request to terminate ?
//SIGIOT
SIGBUS - Something with
SIGFPE - Floating point error occurred
SIGKILL - Cannot be trapped by signal handler - process if terminated SIGUSR1
SIGSEGV - When memory access violation occurs
SIGUSR2
SIGPIPE - Something about reading from a pipe
SIGALRM - An alarm time period has elapsed
SIGTERM - A request to terminate process?
SIGSTKFLT
SIGCHLD - Raised when child process is terminated SIGCONT - Continue from a trapped state (debugger) SIGSTOP - Cannot be trapped by signal handler
SIGTSTP
SIGTTIN - TTY has some information
SIGTTOU - TTY output ?
SIGURG - More Bandwidth available
SIGXCPU - Cpu Timeslice exhausted
SIGXFSZ
SIGVTALRM
SIGPROF
SIGWINCH
SIGIO
SIGPOLL
SIGPWR - When power is shutting down.
What is lacking anywhere on the net is any information about the conditions that must exist before a given signal
is issued to an application.

In the case of SIGSEGV and SIGFPE, there is no information on how to produce the core dump information
for debugging purposes as well as internal processing that I want to do during the handling of the signal.

The signals I am interested are those that relate to problem situations where the process should
be actively terminating itself as soon as possible. SIGABRT, SIGTERM, and SIGQUIT come to mind as signals
that should be considered indications of informing the process to terminate gracefully and immediately.

Which signal is sent to indicate that REBOOT or SHUTDOWN is imminent or occurring?

What function uses SigInfoRec ? It is in linux.pp, but I cannot find its use anywhere.

Mark Diener

Please ignore my earlier posting on signals.

I have found an explanation of many signals at the following web address:

http://step.polymtl.ca/~ldd/syscalls/syscalls_99.html

Notice on the web page it refers to
"terminates" and "stops" in parentheses.
What do you think that means?

Are there signal handlers that actually freeze the process and how do we override this
behavior if it is true. Every process should keep executing regardless of signal handled.

What is still unclear is how to have a signal handle perform internal processing
and still allow for system default core dumping and process termination.

The core dump is helpful for debugging purposes.

Any help appreciated,

Mark

Man signal is completely devoid of intelligence on the actual flow of events related to signals.

It is missing a lot of information.

I am trying to get a feeling of the complete subsystem so that I can make decision on how to react to signals and what the impact of them are.

Mark

I will add this list to the documentation, as it may be useful.

Notice on the web page it refers to "terminates" and "stops" in parentheses. What do you think that means?

It refers to the behaviour if the signal is not caught. i.e. if the signal SIGHUP is not caught, the program will be terminated.

The KILL signal will terminate the process. There is no way to stop this, as this signal cannot be caught.

The STOP signal will freeze the process till it gets a 'CONTINUE' signal. This cannot be stopped either, AFAIK.

All other signals can be caught and should be caught if they can appear in your program.

What is still unclear is how to have a signal handle perform internal processing and still allow for system default core dumping and process termination.

By default, the signal handler is uninstalled when it is called. You can
1) Not reinstall it in the handler.
2) send the same signal again to yourself.
(both steps must be done)

then you'll get the default behaviour. This should only be done for signals that can generate a core dump.

Michael.

md wrote

I guess you are in Belgium somewhere. Maybe Brussels?

About 25 Km. east of Brussels, to be exact.

This signal stuff is excellent white paper material.

Indeed.

No, you can, and most signal handlers do this as the first thing, to be able to trap the error if it should occur again.

To continue default behavior, I must raise( ) the signal again and default core dumping and terminating will take place.

yes. Only you should use sigraise(), not raise()

Only for the stop signal must I raise an SIGCONT signal.

If you want to continue execution, yes.

Correct.

Please confirm these statements.

Request fulfilled, I hope...

Michael.

I guess you are in Belgium somewhere. Maybe Brussels?

This signal stuff is excellent white paper material.

Some "mysteries of signals" lifted.
From your response, I am assuming that I cannot reinstall the handler while inside the handler.

To continue default behavior, I must raise( ) the signal again and default core dumping
and terminating will take place.

Only for the stop signal must I raise an SIGCONT signal. From what I conclude, I can handle the signal then Raise it again and the default processing
would take place. If I do not raise it again, the default processing will not take place.

Please confirm these statements.

Mark Diener

Thank you sir.

Your information is very helpful.

A follow up question:

Michael,

What I am saying is that I do not have a clear idea on how to get rid of those login prompts in non-logged in consoles. For example, when Linux is first started,
there is a login prompt in TTY1. If you login, you can immediately then press ALT-F2 and go to TTY2.

There will be another login prompt there as well.

Lets suppose that from the first console TTY1, a process was started that
spawned another process that was directed to TTY2 for stdin/stdout/stderr. I imagine
that you would have the output from the login process and the output from the spawned process both
competing for the console.

How would you prevent the login process from executing so that the TTy2 is available for stdin/output from the spawned
process without having any requirement of login or such.

Mark Diener

How would you prevent the login process from executing so that the TTy2 is available for stdin/output from the spawned process without having any requirement of login or such.

1. The other processes aren't really executing (as in eating up processor time and memory). They are blocked for input, and as such passed by the scheduler.

2. Simply don't start them in your login scripts. (getty commands).

Marco van de Voort ( or )

Request satisfied completely.

Thanks a bunch,

Mark

Michael:

I am still trying to get a grip on signals:

There are three classes of signals as I know them to be:

Fatal Signals involving core dump

Mild Signals requesting application supported shutdown

Who cares Signals - Ignore them, they do not apply

The fatal signals include:

SIGSEGV, SIGFPE, SIGILL, and SIGTRAP.

The mild signals include:

SIGINT
SIGQUIT
SIGABRT
SIGBUS
SIGSEGV
SIGTERM
SIGPWR

Who cares signals include:

SIGHUP
SIGUSR1
SIGUSR2
SIGPIPE
SIGALRM
SIGSTKFLT
SIGCHLD
SIGCONT
SIGTSTP
SIGTTIN
SIGTTOU
SIGURG
SIGXCPU
SIGXFSZ
SIGVTALRM
SIGPROF
SIGWINCH
SIGIO

The Fatal signals I just don't even handle.
The Mild signals I install a handler for them, but I do not raise the signal again after handling the signal.

I am assuming the behavior of the system after the handler not raising( ) another signal
is to proceed as normal.

Or should I try to do shutdown activities within the context of the signal handler?

Again, it is the implementation in handling these signals without causing exception violations is the key.

What happens to the executing context of the process when a signal is raised. Does that process go idle in the kernel while he handler executes?

Your response appreciated.

Mark Diener

Why ? The SIGSEGV can be caught.

The Mild signals I install a handler for them, but I do not raise the signal again after handling the signal.

Seems OK.

I am assuming the behavior of the system after the handler not raising( ) another signal is to proceed as normal.

Yes, I suppose so.

Or should I try to do shutdown activities within the context of the signal handler?

This depends; the SIGTERM is usually sent to a program telling it that it should stop operations. you should then really shut down the program in a gentle way.

Again, it is the implementation in handling these signals without causing exception violations is the key.

Yes; you must of course be careful.

What happens to the executing context of the process when a signal is raised. Does that process go idle in the kernel while he handler executes?

No; the 'executing context' is the signal handler at that time; when the handler returns, operation is resumed as normal, I think.

Michael.

This problem is under linux OS.

Maybe someone has an insight on a problem that I am having trying to get a shared library created by Free Pascal to be callable in code by GNU C.

If libraries do not work under Free Pascal, then I would like to link in the object file that is created by the PPC386 compiler.

I am using FPC1.0.2. It indicates in the help text of the compiler that the -CD switch is not supported. The -CS option is not recognized by PPC386.

Imagine compiling the following test.pp file:

library test;

uses funcunit ; (all functions inside unit are cdecl declarations)

exports

testfunc1, testfunc2 ;
end.

*********************

Now compile the unit into a library: ppc386 -CD -g -P -Sd -Op2 test.pp

This creates a libtest.so file that is statically linked.

I do not believe it is a library with position independent code.

*********************

Now, I could use gcc -ltest to link this into a GNU C compiled program, but upon calling the external function
in the library, I get an exception thrown and the process is ended.

Any ideas on getting pascal code linked into C programs? Either using .so shared library or linking .o file directly.

Thanks,

Mark Diener

It's not possible yet as the unit initialization isn't supported by C.

md wrote

Free pascal community: Peter Vreman responded that there is a problem getting pascal compiled code to be used by code compiled by GNU C.

This is correct.

Please confirm that any code compiled under pascal is not usable by code in GNU C.

This is not entirely true.

No ability to link object file? test.o

Possible.

No ability to create shared library? libtest.so

Createable, but not always usable.
it is _NOT_ usable in following circumstances:
- Use of the heap in a library.
(can be remedied by using the CMem() unit, which uses the C heap manager)
- Units with initialization code.
- Writing to standard input/output.

A library that does not use any of the above is possible.

e.g. someone made a library containing UDF's for the Interbase SQL server in a shared library, for string functions. it works without problems.

No ability to create static library? libtest.a

Same applies here.

The problem is that the unit initialization is not carried out by C libraries. We are working on this; a solution is known, but must be implemented and tested.

Michael.

The linking isn't the problem. The problem is the proper initialization of the run time library.

Free pascal community:

Peter Vreman responded that there is a problem getting pascal compiled code to be used
by code compiled by GNU C.

Please confirm that any code compiled under pascal is not usable by code in GNU C.

No ability to link object file? test.o
No ability to create shared library? libtest.so
No ability to create static library? libtest.a

Any response highly appreciated.

Mark Diener

Florian and Michael:

Thank you for the answer.

I will handle the stdin/output problem by passing those FILE* into the library and assigning them.

The library uses the stack, not the heap. Except for IPC calls, but that
should be outside the scope of the heap manager.

It is very productive to be able to write code in pascal and then link into c programs. This way
I do not have to re-implement the code in C, thus duplicating my creation and maintenance of code.

Mark Diener

None of these bugs requires immediate attention, they all seem to have current workarounds.

A couple of bugs I have noticed with Linux FPC 1.0.2:

function testme : integer ;  Seems to corrupt the stack whereas
function testme( randomarg : integer) : integer ; does not.

It seems functions without arguments mess up the stack pretty good. Syscalls( ) start returning weird values
inside of testme and life is generally miserable afterwards.

*****************************************************

Creating a shared library requires the shared library memory manager be swapped out with the C library manager. And it
works very well.

But swapping out the library manager within the pascal process itself causes many access violations/exceptions to throw during process exit/termination.

****************************************************

Thanks to all the free pascal contributors,

Mark Diener

There is a mild bug in the compiler. Linux. Delphi Mode. 1.0.2

Compiling functions expecting pointer to structure

type
TMESS = record
one : integer ;
two : integer ;
end;
PMESS = ^TMESS ;
function whatever(arg1 : integer; arg2 : PMESS)  : integer ;

Compile a program which calls function whatever.

var
 testarg : PMESS ;
begin
RESULT := whatever(3,testarg) ;
end;

Compiler will throw an error:

94: Incompatible type for arg no 2, Got PMESS, expected PMESS.

To fix the problem, use this code:

RESULT := whatever(3,PMESS(testarg)) ;

Will compile fine.

Thanks,

Mark Diener

Earlier, I reported a compiler bug with respect to invalid typing of function arguments. It appears
that the cause of this problem was due to uses clauses that referred to units that contained function definitions
that were comflicting in name and arguments with the intended function.

Please remove this bug report from the list.

It works fine as I can currently see.

Mark Diener

For those contemplating doing shared libraries in FPC,

a very nice feature is that the GDB debugger will step into calls of the shared library
as if the library were just compiled natively into the application.

Microsoft makes this a bit more difficult, but under LINUX, very easy. Thus,
there is no need to a test build of the library around so that you can test the code inside it.

Just build the library and debug it on the fly.

Again, VERY NICE feature...

Mark Diener