Grx

grx@gnu.de

559 discussions

Re: grx on Mac OS X
by Schindler Karl-Michael 06 Nov '12

06 Nov '12

Hi Maurice >> There are the additional issues when enabling tiff, png and jpeg. >> They are not readily available, but need to be installed in --prefix such as /usr/local, /opt or /sw >> Therefore, the include and lib paths need to be passed to the compiler and the linker. > > In other systems, it is supposed that these softwares are first installed in a known system directory, i.e. > > /usr or /usr/local in linux > c:\mingw in mingw > c:\djgpp in djgpp > > In that case .h and library files are found by the system and your following changes are not needed to compile grx. On Mac OS X, Apple's stuff is in /usr, which should be used by others. Therefore, most standalone installers of unixoid software install their stuff into /usr/local. Package managers (MacPorts, Fink, Homebrew, ...) use /opt, /sw, .... Since there is no Apple version of libtiff, libjpeg in /usr, they must be installed by the user manually or using a package manager and it is at least tricky to know, where it is installed. gcc and ld usually have no clue about /usr/local, /opt, even if package managers are installed. In simple cases they use configure --prefix=...., which then results in passing CFLAGS=-I$PREFIX/include and LDFLAGS=-L$PREFIX/lib to gcc/ld. > notice that $(includedir) is the path where .h files of grx are to be installed, not the one where other .h files are to be found (and similarly for libraries) To the best of my knowladge, this is the default use of --prefix: install the new library and .h files exactly there, where to search for depending .h files and libraries. At least that is the policy of the package managers, i know. If a particular install directory is needed, an explicit INSTALLDIR is used. > Doing your changes enables to compile and install grx, but you will not be able to use them in user's programs if you do not make them visible by the system. The usual way to do this is to install them in system directories like above. I would assume that "make install" is exactly doing that? > I had one case in which this way was not convenient, an old mingw > snip > This way all is available both when compiling grx and in user's programs I do not think, we need all of this. > Do you see an objection to follow this in Mac OS X. As I said you need > something like this to compile user's programs. In the end i would setup a package description for fink, which will make it easy for others to use grxlib in their program, but I have the impression, that we still talking about slightly different things. I attach the log of the build run, which fails because of -soname. > I can include explanations in the readme files. no need yet. >> diff -r '-x*.*o' ../grx249 2/src/makefile.x11 ./src/makefile.x11 >> >>> $(CC) $(LDOPT) -shared -lX11 -L/usr/X11/lib -o $(GRX20SHna) $(LO) $(LIBS) > > This is not the content of makefile.osx, with the .dylib stuff. Have you tried it ? You are right. This part was from a previous try. I needed to apply the patch again to unmodified! sources. See the attached log files. Michael.

2 1

Re: grx on Mac OS X
by Schindler Karl-Michael 05 Nov '12

05 Nov '12

Hi Maurice I tried your patch and i found this small glitch in test/speedtst.c There is one more "#endif" missing after "#include <values.h>" There are the additional issues when enabling tiff, png and jpeg. They are not readily available, but need to be installed in --prefix such as /usr/local, /opt or /sw Therefore, the include and lib paths need to be passed to the compiler and the linker. diff -r '-x*.*o' ../grx249 2/src/makefile.x11 ./src/makefile.x11 14c14 < INCDIR= -I. -I./include -I../include $(X11INCS) --- > INCDIR= -I. -I./include -I../include $(X11INCS) -I$(includedir) 39a40,55 > ifeq ($(HAVE_LIBTIFF),y) > ADDON_LIBS += -ltiff > endif > > ifeq ($(HAVE_LIBJPEG),y) > ADDON_LIBS += -ljpeg > endif > > ifeq ($(HAVE_LIBPNG),y) > ADDON_LIBS += -lpng > endif > > ifeq ($(NEED_ZLIB),y) > ADDON_LIBS += -lz > endif > 93a110,111 > LIBS= $(GRX20X) $(ADDON_LIBS) $(X11LIBS) -lm > 146c164 < $(CC) $(LDOPT) -shared -Wl,-soname,$(notdir $(GRX20SHli)) -o $(GRX20SHna) $(LO) --- > $(CC) $(LDOPT) -shared -lX11 -L/usr/X11/lib -o $(GRX20SHna) $(LO) $(LIBS)

2 1

GRX2.4.9 patch file
by A L 01 Nov '12

01 Nov '12

Hi, I guess this list has been abandoned (no activity since the last release at all), still wanted to share my patch that 1. Further fixes bitblt race for 8bpp graphics on Windows during window init phase (first repaint event sent/processed too fast), locking the DC (and leaving the window white, not always but intermittently across multiple app starts); 2. Fixes LIBBCC.H decls for C++ (posted earlier); 3. Replaces an outdated header <values.h> in speedtst.c; 4. Adds processing of Shift-Tab on Windows, a very popular choice of a key for moving backwards on controls (lbgrx provided it undistinguishable from a regular Tab as returned by GrKeyRead()); 5. And finally, removes optimization (-O2) in debug builds (which otherwise clobbers the source code line sequencing and makes it very difficult to use in a debugger). Hope this helps, AL

4 6

grx on Mac OS X
by Schindler Karl-Michael 25 Oct '12

25 Oct '12

Hi folks I had a try to build grx on Mac OS X and after a number tricks it seems to work based on X11. If someone is interested in this, i would like to get in contact. Michael Schindler

2 1

Obsoleted header used in test/speedtest.c
by A L 15 Oct '12

15 Oct '12

JFYI: Compiling libgrx under the latest Cygwin (1.7.16-1) produces the following error: gcc -c -O2 -fno-strict-aliasing -Wall -I../include speedtst.c -o speedtst.o speedtst.c:32:20: fatal error: values.h: No such file or directory compilation terminated. makefile.w32:81: recipe for target `speedtst.o' failed make[1]: *** [speedtst.o] Error 1 Replacing <values.h> with <limits.h> (at test/speedtest.c:32) solves the problem. Cheers, AL

1 0

LIBBCC.H header bugfix for C++
by A L 11 Oct '12

11 Oct '12

Original message bounced, reposted. Date: Thu, 11 Oct 2012 19:46:53 -0400 Subject: LIBBCC.H header bugfix for C++ Hi, The following patch would correct a few "undefined" symbols if libbcc.h is used in a C++ program. Specifically, if a macro is cancelled for a BGI call (like, line() called as a regular function) or a special-case, macro-less call (e.g. getfillsettings()) is made, they will not be found by the linker (because seen as C++ calls, per the original header, thus mangled), without any warnings at the compilation stage. sample.cpp: #include <grx20.h> #include <libbcc.h> #undef line // avoid macro interference int main(void) { line(1,2,3,4); // real function call now arc(1,2,3,4,5); // arc() has no macro defined, so real call here as well return 0; } gcc -Wall -o sample sample.cpp -lgrx20 -lgdi32 sample.o:sample.cpp:(.text+0x2e): undefined reference to `line(int, int, int, int)' sample.o:sample.cpp:(.text+0x5a): undefined reference to `arc(int, int, int, int, int)' *** libbcc.h.orig 2007-03-08 16:21:40.000000000 -0500 --- libbcc.h 2012-10-11 19:07:57.297854900 -0400 *************** void __gr_set_BGI_mode_whc(int *gd, int *** 494,503 **** int __gr_get_BGI_mode_pages(void); void __gr_set_BGI_mode_pages(int p); - #ifdef __cplusplus - } - #endif - /* ----------------------------------------------------------------- */ /* --- API functions with macro equivalents --- */ /* --- (for inlining) --- */ --- 494,499 ---- *************** int getactivepage(void); *** 551,556 **** --- 547,556 ---- void setvisualpage(int p); int getvisualpage(void); + #ifdef __cplusplus + } + #endif + /* ----------------------------------------------------------------- */ #define restorecrtmode() __gr_restorecrtmode() #define getgraphmode() (__gr_INIT ? __gr_Mode : (__gr_Result=grNoInitGraph)) --- Cheers, AL

1 0

question about using make for GRX
by David Melik 04 Jul '12

04 Jul '12

I am wondering if the Makefile for GRX supports, or will support, DESTDIR. I tried to create a SlackBuild, but had problems, I think because there was no DESTDIR. I prefer fully Free Software and want to switch to Kongoni or maybe Parabola one day, but if I make a SlackBuild it of course could be used for those distributions. --David _____________________________________________________________ Find out what's HIP! Visit Hip Planet for news, shopping, forums, chatrooms, free personal and classified ads and much more! Get FREE E-MAIL! at HipPlanet now! It's all waiting for you, at http://www.hipplanet.com

4 3

How to use "mouse wheel" in GRX
by jhliu 08 Dec '11

08 Dec '11

Dear Sir, Thanks for GRX provides lot of powerful and useful mouse event handling functions, But it seems to does not support using of the “mouse wheel”. Is there any alternate method to enable the mouse wheel in GRX ? Thanks in advanced. Regards, JH

2 3

Re: GRX, gpc version 20060325, based on gcc-3.4.4 demo programs for problem
by Maurice Lombardi 21 Nov '11

21 Nov '11

Le 19/11/2011 21:43, T.D. Telford a écrit : > Hello, > > The patch worked fine on the demo programs, and on the chess program > that I am converting. > > A question on a different subject: The chess program reads the chess > piece images by using GetImage, where the images were created under > turbo pascal. I get a segment violation when I try to read these images > on gpc/grx. I suspect that the header information for the image created > by turbo pascal is not compatible with the grx image header information. > > Do you know how these turbo pascal images could be read? No. I have only the sources of the BP RTL, but apparently they do not contain sources of the BGI system. May be somebody reading this list ? Maurice -- Maurice Lombardi Laboratoire Interdisciplinaire de Physique, (ex Spectrometrie Physique) Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

3 4

Re: GRX, gpc version 20060325, based on gcc-3.4.4 demo programs for problem
by Maurice Lombardi 19 Nov '11

19 Nov '11

Le 17/11/2011 20:40, T.D. Telford a écrit : > Thank you for the reply. I have attached 2 programs. > > The first, diagonal.pas, draws a line diagonal, but it is not completely > drawn. If you uncomment the code to draw the second diagonal, then the > first diagonal is completely drawn, while the second one is not complete. > > The second program, circle.pas, draws a filled circle. Then getImage and > putImage are used to draw a second filled circle. The second circle is > not displayed. If you uncomment the code to draw the third filled > circle, then the second circle is displayed, but not the third. > > I have had the same problem with writing text to the graphics window. > The last part of the text is not displayed. If I write some additional > text (in the background color), then all of the original text is displayed. > > I am using grx 2.4.8 on a linux fedora 15 x86_64 system, gpc version > 20060325, based on gcc-3.4.4 (which I compiled). > Please apply to grx 2.4.8 the attached patch which defines a GrFlush procedure and recompile grx. It solves the problem for your two demo programs in x11 if you add GrFlush just before the final readln. Try on your other programs. For other systems the function is defined to keep compatibility, but dummy, because I have found that your demo programs do not need it. Maurice -- Maurice Lombardi Laboratoire Interdisciplinaire de Physique, (ex Spectrometrie Physique) Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

1 0

← Newer
1
2
3
4
5
6
7
...
56
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

Grx