ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
To link libraries, you add -l<libraryname> to your comand line. Library name is the name of a library that is usually in the form lib<libraryname>.so (or .a). So in your case, try using -lsrgp. You may also have to include -static to link static libraries (which is what a .a is), but I don't remember for sure.
That's probably because srgp relies on additional libraries. Without seeing exact errors, we can't tell you what additional libraries you need to link, but one trick you can use to find out is to use grep.
For instance, say it is complaining about an undefined reference to xxxxxxx.
Type the following to see if there is a .so file in /usr/lib that has that function.
grep "xxxxxxx" /usr/lib/*.so
(Note: This sometimes find files that rely on that function as well, so it doesn't necessarily mean that the function is exported from all the .so files it finds...)
Now, assuming it found a reference xxxxxxx in libyyyyy.so, you could then try adding -lyyyyy.
Edit: You may also have to look in other library directories such as /usr/X11R6/lib. If you find a library you need in any directory that is not part of the standard library search path, you can add it to the search path by adding -L/path/to/library to your command line. Using my previous example, if you found that /usr/X11R6/lib/libyyyyy.so had what you needed you would add:
i run command grep and i found some libraries like
i linked just one of them for example libplot and i didnt get errors but when i run it with ./a.out i got
SRGP:Color table too full to share
A solution is to have the SRGP application request
0 planes in the 4th parameter to SRGP_begin.
For now, the application will have its own
color table rather than try to share.
SRGP FATAL ERROR:
X SERVER ERROR:
(examining the core will be usefull only if using X in synchronous mode):
Badmatch (invalid parameter attributes)
I AM ABOUT TO INVENTIONALLY CRASH SO YOU CAN LOOK
AT THE ACTIVATION STACK USING A DEBUGGER
If your application is an SRGP application ,please remember:
if the error message above says
that you sent a bad argument to a certain function,
you should run your program with tracing ON in order
to see exactly what you sent
If you already had tracing enabled,remember to look in
'SRGPlogfile' for the tracing messages
It says this about that fourth parameter of SRGP_begin:
The fourth parameter is meaningful only on a display supporting color. It specifies how many planes of the color table should be reserved for SRGP's use; i.e., it places an upper bound on the number of colors that may be displayed simultaneously in the SRGP window. (The upper bound is colors, where is the number of planes.) The fourth parameter is ignored when the program is run on a bilevel display.
If the program is being run on a color display, and you send the special value "0" as the fourth parameter, SRGP will take over the entire color table, giving your application color support as rich as the hardware can offer. (After initializing SRGP, you can inquire the "canvas depth" to determine how many planes are available.) The disadvantage: it will be impossible for the user to simultaneously see the SRGP window's proper coloring and the other clients' windows' proper coloring. Thus, you should request "0" planes only when your application truly needs full control of the color table.
Are you running this from X? I might try passing 0 there to see what happens. Passing 1 sounds like you are requesting only 1 color. It does say it ignores it on a "bilevel display," but I'm not exactly sure what it means by that. I don't think I've ever heard that term used before, but my guess would be it means some sort of GUI system like X11...
I'm exiting stage left for now. The main points that I found (posted in csst0136's other thread) are:
1. srgp.tar.Z extracts nicely into its own subdirectory. You don't need to copy anything into other
places (and certainly not into /usr/lib).
2. You can build the examples with the syntax:
make PROG=xxx (e.g. "make PROG=testpaint", from the "SRGP_DISTRIB/examples" subdirectory)
3. Before you do this, however, you must rebuild "libsrgp.a" (it does not appear to be a Linux/ELF archive)
4. You must add "-I../include", "-L../lib" (both in the sample Makefile) and "-L/usr/X11R6/lib" (SRGP pre-dates X11R6).
5. After you do all this, you can successfully build an SRGP app under Linux/X11R6.
I was not, however, able to successfully run it. For starters, it defaults to some assumptions about colormaps which don't appear to be true for contemporary X11 servers. Changing the 4th parameter from "3" to "0" didn't help. It's unclear what - if any - further problems csst0136 might run into if he were to debug the colormap problem.
'Hope that helps ... at least a little!
Any recommendations on a good API for "Learning Graphics 101 under Linux"? My top vote would be for Java (which has very good 2D and 3D APIs), but I'm very curious about SDL.
Good findings, paulsm. I'm not at home right now so I can't mess with this srgp API at all myself.
Personally, I like OpenGL since most of the graphics I do is 3D based. (You can do 2D stuff too in the form of textured quads, but if you're looking for a typical 2D API it's probably not what you want.) With OpenGL, however, you still need a windowing API of some sort as it leaves window creation/events/etc. up to someone else. SDL is pretty good for creating a simple OpenGL window, but you can use pretty much any windowing API if you know what you are doing.
thanx a lot for helping me you already help me a lot especially to paulsm4 and deiussum
the problem has solved to run the examples.i just change the depth color from 16 bit to 8 bit from YAST.SRGP runs only for 8 bit.But the strange thing is that when i run the program it opens
a new window which is the place where i draw what the program does but everything becomes black.I can see just the bounds of the windows,the minimize and close button at top right of the window and the mouse cursor with white color.If i click out of the window then all becomes with color(very fine) but when i click into the window again it becomes all black again and what i draw is with white color.
I suspect the problem with the "weird colors" is a combination of:
1. The library assumes an excessively low color resolution (you had to go into YaST2 and set the X server to 8-bit/256 color mode?)
... and ..
2. The library is using private (instead of shared) colors.
Again, this was all common practice 10 years ago ... but technology has changed.
I'm afraid I don't have time to go poking around SRGP myself to see if I can make it a little more "Linux-circa-2005-friendly". You're certainly welcome to try; I'd definitely encourage to you to post any questions to LQ.
I couldn't find any good, short web articles on Xlib colormaps that didn't have a lot of extraneous stuff but, if you're feeling ambitious, here are some links that'll tell you everything you need to know ... and then some!