GIMP

message unavailable

In article <aa8486$ohp$1=oi2x686WOMlBDgjK7y7TUQ@public.gmane.org> you wrote:

I have no failed modules on compiling, since I wrote stubs(not
implementation) for getdomainname(), setdomainname() which is required, but
I can’t get it running.
Version that available from site won’t run on XFree on my box.
And one more question - How did you get shared libraries (libgtk,libglib) on
QNX??

Sergey

You can download the glib/gtk binary that is compiled against XFree
from http://www.sourceforge.net/projects/openqnx

once you get the file, you can install it
cd /
tar zxvf gtk.glib-1.2.10-binary-qnx6.tar.gz

this will create /opt/openqnx directory with all files.
You will need to add /opt/openqnx/bin to your PATH and /opt/openqnx/lib
to your LD_LIBRARY_PATH

Good luck.

Frank

You should post your question to the openqnx mailing list instead
of us individually:
http://lists.sourceforge.net/lists/listinfo/openqnx-developer

almost all packages on openqnx project site are in tar format, which
means you can simply:
su
cd -
tar zxvf file.tar.gz
to install it.

once you’ve installed openssh, you can run /openssh-setup to setup
the openssh server and run /usr/sbin/sshd to start the server.
you might want to add /usr/sbin/sshd in your /etc/rc.d/rc.local
if you want to start it automatically after reboot.

if you only want to use ssh as client, you can ignore the above
paragraph.

Frank

On Fri, 8 Nov 2002, Filipe Brandenburger wrote:

Hello,

I have a question about the project openqnx, so I’m sending you guys this
mail. I hope you don’t mind…

I’m starting with QNX, and as my basic requirements, I need a SSH client in
my installation. I downloaded the OpenSSH binary tar.gz from the openqnx
project, but I don’t know exactly what to do with it. Should I just
untar(gz) it in my root filesystem? Should I run something after unpacking
it? Or should I use the QNX Software Installer or the like?

Thanks a lot!

Filipe

Frank Liu <liug=wJsaexb6DEQ3G7qi5jAxu4dd74u8MsAO@public.gmane.org> schrieb am 08.11.02 18:36:13:

You should post your question to the openqnx mailing list instead
of us individually:
http://lists.sourceforge.net/lists/listinfo/openqnx-developer

almost all packages on openqnx project site are in tar format, which
means you can simply:
su
cd -
tar zxvf file.tar.gz

You can also use the newest version of ‘workspace’ … it has a very nice
graphical interface for tar.gz archives.

http://pages.infinit.net/micbel

Armin


\


Die vCard - Ihr neues Kennzeichen - bei WEB.DE FreeMail!
http://freemail.web.de/features/?mc=021156

Are you talking about vnc or the real X server?

“no display”? any errors?

btw, you may want to recompile xearth with the new xfree and see
if it helps.

Frank

On Thu, 5 Jun 2003 alain.bonnefoy=uWxFhhn2E0U@public.gmane.org wrote:

Hi Franck,

I’m completely lost in xfree, I have the impression that every release figure
out a new design with different files in different locations.
I tried to start xearth yesterday, I could see the display with a lower color
depth (maybe 4), I don’t know why because options are the same as my xfree336
config and xdpyinfo says that the x server depth is 16, same as my xfree336
also.
Today, xearth runs without any error but I get no display ?!?, I don’t know
where to find the relevant infos to discover why xearth doesn’t display anything
or where does it display something.

any idea?
Thanks,
Alain.






Frank Liu <liug=> wJsaexb6DEQ3G7qi5jAxu4dd74u8MsAO@public.gmane.org> > le 04/06/2003 19:32:41

Pour : openqnx-developer=> 5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
cc : (ccc : Alain BONNEFOY/Valence)

Objet : Re: [Openqnx-developer] extension “RENDER” missing





VNC’s X server is quite old and lacks some of the newer
X extensions such as the Xrender. If you run XFree on
the console directly (which is most of us doing), you
will get a full X server and won’t have those warnings.

“any” x application is probably a big statement > :slight_smile:
you will only get this warning if the x application uses
those newer extensions. “xcalc”, for example, doesn’t
use xrender feature, while “xclock” does.

With more and more X applications starting to take
advantage of those newer X protocol extensions, you will
probably see more of those warnings in VNC X server.

btw, “xdpyinfo -ext all” should show you which extensions
are supported, which are not, for your X server.
try it on a true X server and within VNC’s X server,
or on a MS Windows x server (Exceed or ReflectionX),
you will see the differences…

Frank

On Wed, 4 Jun 2003 alain.bonnefoy=> uWxFhhn2E0U@public.gmane.org > wrote:

Hi,
Any x application display that message on installation xfree-4.3.1.
I saw on the web that lot of people complain about that message, Isaw that
could
be about graphic card capabilities, fonts, etc…
I use X11 through xvnc3.3.7 I never saw that message on my previous
installation
qnx 6.1, xfree 4.2 xvnc 3.3.3.

Any idea?

thanks,





\

This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you’ve never dreamed of, try TotalView 6 free at > www.etnus.com> .


openqnx-developer mailing list
openqnx-developer=> 5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/openqnx-developer



\

This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you’ve never dreamed of, try TotalView 6 free at > www.etnus.com> .


openqnx-developer mailing list
openqnx-developer=> 5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/openqnx-developer





\


This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you’ve never dreamed of, try TotalView 6 free at www.etnus.com.

Hi all,

Thanks to X.Tang for his valuable information.

I am using vp_attach() and vp_detach() only once in our code & providing
proper FD to vp_attach() (even tried vp_attach with -1 option) and nowhere
closing that FD.

And I am not doing any fork() in my code.

I am creating a thread in our code and using VPI library functions across
the thread. ( I found, none of the VPI library functions are thread safe.
Will this be the problem?)

But I feel, once when I was doing a stress test on VPI using a program
(without thread), I got he same error (vp_freepkt: Bad file descriptor.) If
I get that program I will let u all know.

BTW, what is this vp_freepkt() function? Can I get any implementation
document of the VPI?

Thanks
Jith.

----- Original Message -----
From: Xiaodan Tang <xtang-mMf908IxFcw@public.gmane.org>
To: Prajith <prajith-U1VcRrJwn5T8CqgTAz400NBPR1lH4CV8@public.gmane.org>; Frank Liu <gfrankliu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Sent: Tuesday, October 05, 2004 11:42 PM
Subject: RE: [Openqnx-developer] Getting an error display, vp_freepkt: Bad
file descriptor.


When you call vp_mfree(), it will then call vp_freepkt(), this end up
to Sendmx(v->sock, …), which is a message send to Tcpip.

The EBADF seems indicating the v->sock is not right. The
v->sock is comming from vp_attach(). If you pass in one,
then it will dup() it; if you pass in -1, it will create one use
socket() call.

I don’t know why that socket fd would be bad, but things
to think about is, are you vp_attach()/detach() a lot?
Did you fork()'d your process after attach()? If you passed
in a fd in vp_attach(), did you accidently closed it?

-xtang

-----Original Message-----
From: > openqnx-developer-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
[mailto:> openqnx-developer-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> ] On
Behalf Of Prajith
Sent: Tuesday, October 05, 2004 8:57 AM
To: Frank Liu
Cc: OpenQNX
Subject: Re: [Openqnx-developer] Getting an error display,
vp_freepkt: Bad file descriptor.

Hi all.

Our Bandwidth Manager is showing around 20 times the error message
“vp_freepkt: Bad file descriptor.” while transfering a 5MB
file at a bandwidth regulation of 1Mbits/sec, irespective of
the available no.of file descripters/process.(even I have
tied with Proc32 -f 16 10240 20480, then too I got around 20
error messages.).

We have implemented a queueing discipline (CBQ) in the
application space, where we are getting network packets using
the VPI (Virtual Packet
Interface) as a IP FILTER. These queueing disciplines keeps
the netwoks packets for a while and send them back in a
random order(not in the sequeuece in which packets are
received). Will this make any problem in VPI (keeping packets
for a while in memory and send them back in a random order)?
Or is there any way to configure the Virtual Packet Interface?

Please give us some solution/suggestion/comments.

Thanks in advance
Jith.


----- Original Message -----
From: Frank Liu <> gfrankliu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
To: Prajith <> prajith-U1VcRrJwn5T8CqgTAz400NBPR1lH4CV8@public.gmane.org
Sent: Friday, October 01, 2004 10:54 PM
Subject: Re: [Openqnx-developer] Getting an error display,
vp_freepkt: Bad file descriptor.


Maybe you ran out of file descriptors, and possibly other resources.
Try to increase that (make a new boot image).

Frank


----- Original Message -----
From: Prajith <> prajith-U1VcRrJwn5T8CqgTAz400NBPR1lH4CV8@public.gmane.org
Date: Fri, 1 Oct 2004 20:54:55 +0530
Subject: [Openqnx-developer] Getting an error display, vp_freepkt:
Bad file descriptor.
To: > openqnx-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org


Hello all,

We have developed a bandwidth regulating software in
QNX4.25(In application space). We are getting the network
packets into the application space using the Virtual Packet
Interface(VPI) and regulating them and send it back using the
same VPI.

It’s working fine with moderate network traffic. But in the
case of heavy traffic, it’s working but displays the
following error message continuously.

vp_freepkt: Bad file descriptor.

If anybody have any idea about this, please let me know.

Thanks in advance
Jith.
«·´·.(*·.¸(·.¸ ¸.·´)¸.·).·´·» «..........Prajith P.K..............» «·´·.(¸.·(¸.·´ ·.¸)*·.¸).·´·»
GlobalEdge Software Ltd.
Bangalore 560003
Cell : 9886171652



\

This SF.net email is sponsored by: IT Product Guide on
ITManagersJournal Use IT products in your business? Tell us
what you think of them. Give us Your Opinions, Get Free
ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl


openqnx-developer mailing list
openqnx-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/openqnx-developer


This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Hi X.Tang,

Thanks a lot for your detailed explanation about VPI. I respect and
appreciate these efforts.

In our code, as per the present design, we can’t avoid using the VPI
across the threads. Because, in our code one thread is getting the packet
from the Tcpip and putting it into the Queues, and the other thread is
getting the packet from the Queues and send it back to the Tcpip. We will
have to think over it for a solution.

About that test program, Hum!!.. I couldn’t find it yet!!..

Thanks a lot to all.
Regards
Jith.


----- Original Message -----
From: Xiaodan Tang <xiaodan.tang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: <prajith-U1VcRrJwn5T8CqgTAz400NBPR1lH4CV8@public.gmane.org>; Frank Liu <gfrankliu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Sent: Friday, October 08, 2004 9:09 PM
Subject: RE: [Openqnx-developer] Getting an error display, vp_freepkt: Bad
file descriptor.


-----Original Message-----
From: Prajith [mailto:> prajith-U1VcRrJwn5T8CqgTAz400NBPR1lH4CV8@public.gmane.org> ]
Subject: Re: [Openqnx-developer] Getting an error display,
vp_freepkt: Bad file descriptor.

And I am not doing any fork() in my code.

I am creating a thread in our code and using VPI library
functions across the thread. ( I found, none of the VPI
library functions are thread safe. Will this be the problem?)

Hm…

This is QNX4 right? So a “thread” is basically another vfork()
isn’t it? (the new “thread” is just another process).

Do you really HAVE TO create a “thread”? Can you make
it so that you only use one thread using VPI functions?
Something like:

int main() {
crate_new_thread();
vp_attach();

}

Make sure attach to VPI AFTER create thread, and the
new thread never call VPI function?

But I feel, once when I was doing a stress test on VPI
using a program (without thread), I got he same error
(vp_freepkt: Bad file descriptor.) If I get that program
I will let u all know.

That is also an interesting test to prove/denial our guess.

BTW, what is this vp_freepkt() function? Can I get any
implementation document of the VPI?

I don’t think there is an “implementation document” ever
publiced, but let me explain the basic ideas behind VPI.

\

  1. The stack (Tcpip) allocate all it’s buffers/clusters from a
    shared memory pool.

  2. A VPI program will find out the pool, and map it into
    local virtual space.

  3. The Tcpip Stack and the VPI program have “queues”
    in shared memroy, so they can exchange mbufs.
    VPI program use vp_getpkt()/vp_putpkt() to get/put
    mbufs on the queues.

  4. The memory pool can only be operated by Tcpip.

So if a VPI program calling vp_mget*() try to get some
memory, it actually turns into a Message send to
Tcpip, saying “I want this much mbuf…”.

When a VPI program calling vp_mfree() to free some
mbufs, this also turns into a Message send to Tcpip,
saying “these mbufs I can return to you…”

Of cause to minimize the message passing, the VPI
program keep arround some free mbufs/mclusters
and recycle them. Only if there is no more free mbufs
locally during vp_mget*(), or there is too much free
mbufs during vp_mfree(), then a message passing
happened.

The internal function “vp_freepkt()” is the one to free
mbufs back to Tcpip when vp_mfree() find there is
too much free bufs locally.

Hope this can give you some view of the VPI library.

Regards,

-xtang


This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

On Mon, 11 Oct 2004 10:07:02 +0530, Prajith <prajith-U1VcRrJwn5T8CqgTAz400NBPR1lH4CV8@public.gmane.org> wrote:

Hi X.Tang,

Thanks a lot for your detailed explanation about VPI. I respect and
appreciate these efforts.

In our code, as per the present design, we can’t avoid using the VPI
across the threads. Because, in our code one thread is getting the packet
from the Tcpip and putting it into the Queues, and the other thread is
getting the packet from the Queues and send it back to the Tcpip. We will
have to think over it for a solution.

QNX4 does not support real posix thread, that’s why a lot of QNX4 library
doesn’t really handle exclusive access.

In your satuation, either you have to add a semaphore and let both your
thread lock it before calling VPI function, or create another Queue to let
your working thread return packets back. Something like this:

VPI thread (vp_getpkt()) → queue for packets to process → work thread

|
VPI thread (vp_putpkt()) → queue for packets to return ← work thread

Thus you can avoid the lock and have the VPI thread always do VPI calls.

-xtang

----- Original Message -----
From: Xiaodan Tang <> xiaodan.tang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
To: <> prajith-U1VcRrJwn5T8CqgTAz400NBPR1lH4CV8@public.gmane.org> >; Frank Liu <> gfrankliu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Sent: Friday, October 08, 2004 9:09 PM
Subject: RE: [Openqnx-developer] Getting an error display, vp_freepkt: Bad
file descriptor.




-----Original Message-----
From: Prajith [mailto:> prajith-U1VcRrJwn5T8CqgTAz400NBPR1lH4CV8@public.gmane.org> ]
Subject: Re: [Openqnx-developer] Getting an error display,
vp_freepkt: Bad file descriptor.

And I am not doing any fork() in my code.

I am creating a thread in our code and using VPI library
functions across the thread. ( I found, none of the VPI
library functions are thread safe. Will this be the problem?)

Hm…

This is QNX4 right? So a “thread” is basically another vfork()
isn’t it? (the new “thread” is just another process).

Do you really HAVE TO create a “thread”? Can you make
it so that you only use one thread using VPI functions?
Something like:

int main() {
crate_new_thread();
vp_attach();

}

Make sure attach to VPI AFTER create thread, and the
new thread never call VPI function?

But I feel, once when I was doing a stress test on VPI
using a program (without thread), I got he same error
(vp_freepkt: Bad file descriptor.) If I get that program
I will let u all know.

That is also an interesting test to prove/denial our guess.

BTW, what is this vp_freepkt() function? Can I get any
implementation document of the VPI?

I don’t think there is an “implementation document” ever
publiced, but let me explain the basic ideas behind VPI.

\

  1. The stack (Tcpip) allocate all it’s buffers/clusters from a
    shared memory pool.

  2. A VPI program will find out the pool, and map it into
    local virtual space.

  3. The Tcpip Stack and the VPI program have “queues”
    in shared memroy, so they can exchange mbufs.
    VPI program use vp_getpkt()/vp_putpkt() to get/put
    mbufs on the queues.

  4. The memory pool can only be operated by Tcpip.

So if a VPI program calling vp_mget*() try to get some
memory, it actually turns into a Message send to
Tcpip, saying “I want this much mbuf…”.

When a VPI program calling vp_mfree() to free some
mbufs, this also turns into a Message send to Tcpip,
saying “these mbufs I can return to you…”

Of cause to minimize the message passing, the VPI
program keep arround some free mbufs/mclusters
and recycle them. Only if there is no more free mbufs
locally during vp_mget*(), or there is too much free
mbufs during vp_mfree(), then a message passing
happened.

The internal function “vp_freepkt()” is the one to free
mbufs back to Tcpip when vp_mfree() find there is
too much free bufs locally.

Hope this can give you some view of the VPI library.

Regards,

-xtang
\


This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl