Grx

grx@gnu.de

559 discussions

addition of a Mac OS X / X11 target to GRX
by Schindler Karl-Michael 24 Nov '12

24 Nov '12

Dear Maurice > Date: Wed, 21 Nov 2012 19:28:34 +0100 > From: Maurice Lombardi <Maurice.Lombardi(a)ujf-grenoble.fr> > Subject: Re: addition of a Mac OS X / X11 target to GRX > To: grx(a)gnu.de > Message-ID: <50AD1D52.5070804(a)ujf-grenoble.fr> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > By the way, if symlinks to it are added as I explained in my last > message is it necessary to give all names inside the dylib for this to > work ? Adriaan already answered that. The comma after "-install_name" needs to be a blank in macosx.diff: - $(CC) $(LDOPT) -dynamiclib -install_name,$(libdir)/$(notdir $(GRX20SHna)) -headerpad_max_install_names -o $(GRX20SHna) $(LO) $(ADDON_LIBS) $(X11LIBS) + $(CC) $(LDOPT) -dynamiclib -install_name $(libdir)/$(notdir $(GRX20SHna)) -headerpad_max_install_names -o $(GRX20SHna) $(LO) $(ADDON_LIBS) $(X11LIBS) As such the install_name is what most expect and is fine. In case fink reviewers want a change, I will deal with this within the package description. I also tried the fat options. In general, they work. However, when I did -arch ppc, 2 small glitches showed up: 1) src/include/grx20.h, line 112: there is one unmatched ")" at the end of the line: -#if defined(unix) || defined(__unix) || defined(__unix__) || defined(_AIX) || (defined(__APPLE__) && defined(__MACH__)) ) +#if defined(unix) || defined(__unix) || defined(__unix__) || defined(_AIX) || (defined(__APPLE__) && defined(__MACH__)) 2) src/fonts/fdv_raw.c: error: fhdr has no member length. I think it is a leftover from earlier and therefore I simply deleted line 53: - _GR_swap32u(&fhdr.length); -arch ppc64 compiled, but there is an error during link, because of missing libraries. If I recall correctly, it is not supported on 10.6 and i would have to try on 10.5. I am not sure, whether it is worth to put more work into this. I started to have a look at the pascal headers and examples using freepascal. I needed some additional defines in grx.pas for fpc, but it is not too bad. I think no extra version for fpc is needed and a first version is ready. Right now, I am at the examples. With a small mod, the first example compiled, but I think it did not work 100%. I need more tests on this. I noticed that some examples use the gpc unit. I have to check for a replacement. A common issue in several examples is the use of binary numbers. fpc does not have the same way as gpc. My first fix is this: {$ifdef fpc} c := GrAllocColor(c and %11100000,(c and %11100) shl 3, (c and %11) shl 6); {$else} c := GrAllocColor(c and 2#11100000,(c and 2#11100) shl 3, (c and 2#11) shl 6); {$endif} It would be nice, if gpc could handle % for binary numbers. Maybe the makefile for the examples needs an extension for examples that work with gpc only. Michael

4 3

Re: addition of a Mac OS X / X11 target to GRX
by Schindler Karl-Michael 21 Nov '12

21 Nov '12

> From: Maurice Lombardi <Maurice.Lombardi(a)ujf-grenoble.fr> > Subject: Re: Grx Digest, Vol 8, Issue 12 > To: grx(a)gnu.de > Message-ID: <50A6BF3B.2060107(a)ujf-grenoble.fr> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Le 16/11/2012 19:59, Schindler Karl-Michael a ?crit : >> >> This is the point, where package manager like fink, macports or homebrew >> come into play and provide an infrastructure for the installation of open >> source software and also deal with version conflicts as good as possible. >> They are similar to apt-get and yum on linux. >> In fink the way to avoid version conflicts is to "live" in a directory separate >> from /usr/local. The default is /sw. In most packages, which are build with >> "./configure; make; sudo make install" this can simply be achieved by >> setting --prefix=/sw, but if need be the build scripts can be extended. > > OK, so I have uploaded to the "more things" directory a new macosx.diff, > which contains in addition > > 1) -I and -L instructions rooted to $(prefix) to locate the addon > directories > 2) provisions in makedefs.grx and in the configure script to build "fat" > binaries. If I correctly understood, it is only necessary to provide > multiple -arch instructions to Apple gcc to make that. > > Maurice For fink I do not really need options for fat binaries, but others might welcome them. When validating the fink package, the install_name of the dylib was incorrect. In order to fix it, I had to do one more replacement in makefile.osx: -dylib_install_name,$(notdir $(GRX20SHna)) -install_name ${libdir}/libgrx20X-$(GRX_VERSION).dylib Another point is that new versions (1.4 or 1.5) of libpng cannot be used, because png_check_sig is referenced from querypng and readpng in png2ctx.c. A quick google on the topic revealed this page: http://bugs.sun.com/view_bug.do?bug_id=6959123 They reference this patch http://cr.openjdk.java.net/~andrew/libpng/webrev.01/src/share/native/sun/aw… In analogy to it, this should be a patch for src/gformats/png2ctx.c: - if( ! png_check_sig( buf,8 ) ) return -1; + if(png_sig_cmp( buf,0,8 ) ) return -1; I tried it and compile and link work, but i haven't done an actual test of this modification. Also, there is no need for an immediate update and a new version of grx, because for the time being i can include this patch in the fink package. So far, the package looks good enough to present it to others for further review. Michael.

3 4

addition of a Mac OS X / X11 target to GRX
by Schindler Karl-Michael 21 Nov '12

21 Nov '12

> Date: Fri, 16 Nov 2012 23:33:31 +0100 > From: Maurice Lombardi <Maurice.Lombardi(a)ujf-grenoble.fr> > Subject: Re: Grx Digest, Vol 8, Issue 12 > To: grx(a)gnu.de > Message-ID: <50A6BF3B.2060107(a)ujf-grenoble.fr> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > 2) provisions in makedefs.grx and in the configure script to build "fat" > binaries. If I correctly understood, it is only necessary to provide > multiple -arch instructions to Apple gcc to make that. > > Maurice Feedback from fink reviewers: Depending on changes of the API of grx, the version in the install_name is probably to specific. If the API will not break, i would be better to make it libgrx20X-2.dylib. The complete patch would then be: -install_name ${libdir}/libgrx20X-2.dylib In case you plan for an API change with version 2.5.*, it should be 2.4. All the rest has been received well. Michael.

2 1

Re: Grx Digest, Vol 8, Issue 12
by Schindler Karl-Michael 16 Nov '12

16 Nov '12

> Date: Fri, 16 Nov 2012 08:47:25 +0100 > From: Maurice Lombardi <Maurice.Lombardi(a)ujf-grenoble.fr> > Subject: Re: addition of a Mac OS X / X11 target to GRX > To: grx(a)gnu.de > Message-ID: <50A5EF8D.1070505(a)ujf-grenoble.fr> > Content-Type: text/plain; charset=ISO-8859-15; format=flowed > > Le 15/11/2012 22:02, Adriaan van Os a ?crit : >> Maurice Lombardi wrote: >>> Le 15/11/2012 10:05, Adriaan van Os a ?crit : >>>> Maurice Lombardi wrote: >> >>> So, to be sure I understand: >>> GIMP-2.6.12-SnowLeopard-Lion.dmg >>> the last which uses X11, contains >>> 2.hfs/GIMP 2.6.12 SnowLeopard Lion/Gimp.app/Contents/Resources/lib >>> which contains the libjpeg.dylib libpng.dylib and libtiff.dylib we >>> need as addons in grx. >>> Where the content of this /lib will go when installed ? >>> not to /usr/lib ? not even symlinked to there. >> >> On Mac OS X, a .app folder is an application package. So, what you are >> seeing here is not an install package, but the contents of a >> ready-to-run application with private .dylibs that are not shared with >> other applications. > > So, if several applications, say GRX and GIMP, use the same addons > dylibs, there are several copies of the same on the disk, and also in > memory if they are run simultaneously. > This is really not economical. May be Apple thinks that nowadays all > kind of memories are cheap and abundant. So why spare some ? > Anyway this is a sure way to avoid version conflicts. > > Maurice This is the point, where package manager like fink, macports or homebrew come into play and provide an infrastructure for the installation of open source software and also deal with version conflicts as good as possible. They are similar to apt-get and yum on linux. In fink the way to avoid version conflicts is to "live" in a directory separate from /usr/local. The default is /sw. In most packages, which are build with "./configure; make; sudo make install" this can simply be achieved by setting --prefix=/sw, but if need be the build scripts can be extended. In a number of cases, the developers of "upstream" are much less cooperative than you and maintainers of the fink package description have to modify the build process. Sometimes they end up with a complete rewrite of the build process. Thanks for your patience. Since building basically appears to work, the next step is to check the installation. I am bit too busy at the moment, but I will have a go at it later next week. Very likely, some of Adrian's remarks will prove to be very helpful. My initial interest was using grx from Pascal. However, the headers will need modifications for using them with freepascal. Time will show, whether I find time to have a go at that. Are you aware of other software using grx which could be interesting to port? Michael.

2 1

addition of a Mac OS X / X11 target to GRX
by Maurice Lombardi 16 Nov '12

16 Nov '12

I am the current maintainer of GRX, which home page is http://grx.gnu.de/ This is an old 2D graphics library written in C with pascal interface for GPC (which is the main reason I use / maintain it). Written initially for DOS/DJGPP, it has been extended to Windows (mingw), linux (console and X11), plus some more esoteric systems. Now a new user Schindler Karl-Michael <karl-michael.schindler(a)web.de> succeeded in compiling / running the X11 version under Mac OS X, with a few modifications. I try to include a macosx target in the GRX sources, but there are a few problems. The first is that I have no Mac computer, so that I have to rely to others to experiment ! Besides some obvious modifications of header files, I included a set of makefile.osx in the src, test, test/bgi, pascal and pascal/bgi subdirectories, and corrected the configure script accordingly. The makefile.osx are copies of makefile.x11 with only in principle minor modifications. The most obvious is the change of dynamic library compilation (the $(GRX20SHna) target in src/makefile.osx), which I have modified according to your rts/makefile patch to compile GPC. It works, but it was necessary to include extra -I and -L parameters to find the headers and libraries for X11, and for auxiliary libraries png, jpeg, tiff if they are used (there are options in configure to do so). This is not necessary in linux (and other targets) if these libraries are correctly installed in system directories, /usr and the like. In principle Karl-Michael has first done it, before compiling grx. Is there something esoteric in Mac OS X, like /sbin/ldconfig to register .so dynamic libraries in linux ? If you want to experiment, you can download grx 2.4.9 from the home page mentioned above, and a macosx.diff in the "more things" sections found in this page (it contains in addition some sanitization of other makefiles, to enable easier comparison). With it grx compiles/runs without the auxiliary libraries, but I had to include an extra $(X11LIBS) in the $(GRX20SHna) dynamic lib target. You can find our full discussion in the GRX list archive at http://www.g-n-u.de/pipermail/grx/ The last message contains proposals to add -I and -L parameters to find location of auxiliary headers and libraries. It works that way, but I do not understand the need for these extra parameters. Regards 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

2 6

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

11 Nov '12

Hi I did not find an easy replacement for ldconfig. Therefore, I made some additional changes in the makefiles to enable the build with image formats: diff -r grx249 3/src/makefile.osx grx249 2/src/makefile.osx 64a65,67 > ADDON_LIBS += -L${prefix}/lib > INCDIR += -I${prefix}/include > 66a70 > ADDON_LIBS += -ltiff 70a75 > ADDON_LIBS += -ljpeg 76a82 > ADDON_LIBS += -lpng 146c152 < $(CC) $(LDOPT) -dynamiclib -dylib_install_name,$(notdir $(GRX20SHna)) -o $(GRX20SHna) $(LO) $(X11LIBS) --- > $(CC) $(LDOPT) -dynamiclib -dylib_install_name,$(notdir $(GRX20SHna)) -o $(GRX20SHna) $(LO) $(X11LIBS) $(ADDON_LIBS) diff -r grx249 3/test/bgi/makefile.osx grx249 2/test/bgi/makefile.osx 25c25 < ADDON_LIBS= --- > ADDON_LIBS=-L${prefix}/lib diff -r grx249 3/test/makefile.osx grx249 2/test/makefile.osx 10c10 < INCDIR= -I../include --- > INCDIR= -I../include -I${prefix}/include 25c25 < ADDON_LIBS= --- > ADDON_LIBS=-L${prefix}/lib

1 0

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

10 Nov '12

> Date: Sat, 10 Nov 2012 09:26:39 +0100 > From: Maurice Lombardi <Maurice.Lombardi(a)ujf-grenoble.fr> > Subject: Re: grx on Mac OS X > To: grx(a)gnu.de > Message-ID: <509E0FBF.6000000(a)ujf-grenoble.fr> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > In linux you need to run > /sbin/ldconfig > as root after installing manually a new software to register shared > libraries > This is frequently overlooked when installing with a package manager, > because it does so automatically. > This is indicated in the top level readme file of grx. > Does this exists in OS X ? or an equivalent ? > If so try with the -v option to see what it does: the directories in > which links are registered are indicated. > In my system I see that way registering X11, png, tiff, jpeg and grx > libraries. > For you, it could be also the problem with X11 libraries > > Maurice You have hit the nail on its head. There is no ldconfig on Mac OS X. But there were hints to dyld, libtool and ranlib, which I did not need until now. So, i am reading the docs about them and will come back after I found out more. Michael.

1 0

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

10 Nov '12

> Date: Fri, 09 Nov 2012 09:46:55 +0100 > From: Maurice Lombardi <Maurice.Lombardi(a)ujf-grenoble.fr> > Subject: Re: grx on Mac OS X > To: grx(a)gnu.de > Message-ID: <509CC2FF.1090607(a)ujf-grenoble.fr> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Looking into the two linux systems I have access to, I see > - In one, a group computer to which I have full root access, there is no > /usr/X11 directory, only a /usr/X11R6 directory which contains virtually > nothing, only a bin subdirectory containing symlinks to mkfontdir and > mkfontscale > - In the other, a lab computer to which I have no root access, I see > neither /usr/X11 nor /usr/X11R6 directories (but they could be hidden > from ordinary users). > > X11 files are contained in regular /usr/include, /usr/lib, /usr/lib32, > /usr/lib64 directories, and thus they are not found through $(X11INCS) > and $(X11LIBS). The only necessary stuff when compiling binaries seems > to be -lX11 contained in $(X11LIBS). > > Probably you can check on your system. On a plain Mac OS X, there is no X11. At least with some versions and it must be installed by the user. If so, it is placed in /usr/X11/, for example /usr/X11/lib/libX11.dylib. At least on 10.6, i also have /usr/X11R6, but this is only a symlink to /usr/X11. With the latest patch "./configure --target=osx; make" gives a successful build. Thank you for your patience. The next step is enabling the extra image file formats. This crashes with undefined symbols, when building the library. Example after ./configure --target=osx --enable-png ... gcc -m32 -dynamiclib -dylib_install_name,libgrx20X-2.4.9.dylib -o ../lib/macosx/libgrx20X-2.4.9.dylib draw/bitblt.lo ... Undefined symbols: "_png_set_gray_to_rgb", referenced from: _readpng in png2ctx.lo "_png_set_IHDR", referenced from: _writepng in ctx2png.lo and many more in png2ctx.lo and ctx2png.lo. As with X11, the library and the library path are needed, depending on the installation of libpng.dylib. Example: -L/usr/local/lib and -lpng

2 1

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

09 Nov '12

> Date: Thu, 08 Nov 2012 11:48:48 +0100 > From: Maurice Lombardi <Maurice.Lombardi(a)ujf-grenoble.fr> > Subject: Re: grx on Mac OS X > To: grx(a)gnu.de > Message-ID: <509B8E10.8030804(a)ujf-grenoble.fr> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Le 07/11/2012 22:47, Schindler Karl-Michael a ?crit : >> I applied your patch to a fresh copy of the sources, configure for osx. > > <snip> > > Oops, I forgot to replace -f makefile.x11 by -f makefile.osx in the top > makefile.osx. > > corrected and uploaded. > I also made /usr/X11 the default X11base both for osx and x11, because > ir works also in the two linux systems I have access to > >> >> Besides this error, there are a couple of warnings. If you intend to work on them, i could send you the complete list. > > They occur because gcc becomes more and more picky with time. > Not easy to correct because options to suppress some warnings in recent > versions of gcc are not understood in older versions and cause build crashes > >> 2 Examples: >> >> In file included from bgi/textd.c:25: >> bgi/text.h:79: warning: ?packed? attribute ignored for field of type ?FontNameTyp? >> bgi/text.h:81: warning: ?packed? attribute ignored for field of type ?uchar? >> bgi/text.h:82: warning: ?packed? attribute ignored for field of type ?uchar? >> bgi/text.h:83: warning: ?packed? attribute ignored for field of type ?uchar? >> bgi/text.h:84: warning: ?packed? attribute ignored for field of type ?uchar? >> bgi/text.h:88: warning: ?packed? attribute ignored for field of type ?char? >> bgi/text.h:90: warning: ?packed? attribute ignored for field of type ?char? >> bgi/text.h:91: warning: ?packed? attribute ignored for field of type ?uchar? >> bgi/text.h:93: warning: ?packed? attribute ignored for field of type ?uchar? >> bgi/text.h:94: warning: ?packed? attribute ignored for field of type ?uchar? >> bgi/text.h:95: warning: ?packed? attribute ignored for field of type ?uchar? >> bgi/text.h:96: warning: ?packed? attribute ignored for field of type ?schar? >> bgi/text.h:97: warning: ?packed? attribute ignored for field of type ?uchar[5]? >> > No harm, it is really a warning that the packed attribute changes > nothing, and is thus superfluous. > -Wno-attributes suppress these warnings in gcc 4.7.2, but is not > understood in gcc 3.4.5 > >> bgi/lnestyle.c: In function ?setlinestyle?: >> bgi/lnestyle.c:51: warning: pointer targets in assignment differ in signedness >> bgi/lnestyle.c:54: warning: pointer targets in assignment differ in signedness >> bgi/lnestyle.c:57: warning: pointer targets in assignment differ in signedness > > This could be corrected for by changing the sources. In fact the correct > signedness is not always obvious, and in BGI the old BP signs are kept > everywhere to keep consistency with old programs, but are different from > those of GRX. > > Maurice OK. With the new patch, there is progress, but still one issue. gcc -m32 -dynamiclib -dylib_install_name,libgrx20X-2.4.9.dylib -o ../lib/macosx/libgrx20X-2.4.9.dylib draw/bitblt.lo ... fails with missing symbols from X11. Therefore, i tried make LDOPT='-m32 -L/usr/X11/lib -lX11' which gives a succesfull gcc -m32 -L/usr/X11/lib -lX11 -dynamiclib -dylib_install_name,libgrx20X-2.4.9.dylib -o ../lib/macosx/libgrx20X-2.4.9.dylib draw/bitblt.lo ... after this make runs fine until its end. make install seems to do reasonable things :-) I could easily add the LDOPT part in the fink package description, but maybe it could be solved at the code level. I also tried the program xdemogrx. It works, but I am not really sure about bugs. I will see. Maybe, we should get the makefile correct first. Michael.

2 1

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

08 Nov '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > From: Maurice Lombardi <Maurice.Lombardi(a)ujf-grenoble.fr> > Subject: Re: grx on Mac OS X > To: grx(a)gnu.de > Message-ID: <50991504.2000800(a)ujf-grenoble.fr> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > snip snap explanations of build and install. OK. I think we reached common ground about proceeding in general and i would like to continue on specific problems when building. I applied your patch to a fresh copy of the sources, configure for osx. make goes quite through a lot of code, but gets stuck when building the library. short log the build: >patch -p1 < ../macosx.diff ... >./configure --target=osx ... >make all ... rm -f ../lib/macosx/libgrx20X.so.2.4.9 gcc -m32 -shared -Wl,-soname,libgrx20X.so.2 -o ../lib/macosx/libgrx20X.so.2.4.9 draw/bitblt.lo draw/bitbltnc.lo ... long list of files ... bgi/bgiprint.lo ld: unknown option: -soname collect2: ld returned 1 exit status As a remedy i changed makefile.x11 to $(CC) $(LDOPT) -shared -L/usr/X11/lib -lX11 -o $(GRX20SHna) $(LO) then the build succeeds and continues with more sources. The next stop is: gcc -c -O2 -fno-strict-aliasing -Wall -m32 -m32 -D__XWIN__ -I. -I./include -I../include -I/usr/include -I../addons/print -I../addons/bmp utilprog/bin2c.c -o utilprog/bin2c.o utilprog/bin2c.c: In function ‘main’: utilprog/bin2c.c:98: warning: pointer targets in assignment differ in signedness utilprog/bin2c.c:106: warning: pointer targets in assignment differ in signedness gcc -m32 -o ../bin/bin2c utilprog/bin2c.o ../lib/macosx/libgrx20X.a -L/usr/lib -lX11 ld: library not found for -lX11 After ./configure --target=osx --with-x11-base=/usr/X11 another "make all" works without an error to the end. Besides this error, there are a couple of warnings. If you intend to work on them, i could send you the complete list. Greetings . Michael Schindler 2 Examples: In file included from bgi/textd.c:25: bgi/text.h:79: warning: ‘packed’ attribute ignored for field of type ‘FontNameTyp’ bgi/text.h:81: warning: ‘packed’ attribute ignored for field of type ‘uchar’ bgi/text.h:82: warning: ‘packed’ attribute ignored for field of type ‘uchar’ bgi/text.h:83: warning: ‘packed’ attribute ignored for field of type ‘uchar’ bgi/text.h:84: warning: ‘packed’ attribute ignored for field of type ‘uchar’ bgi/text.h:88: warning: ‘packed’ attribute ignored for field of type ‘char’ bgi/text.h:90: warning: ‘packed’ attribute ignored for field of type ‘char’ bgi/text.h:91: warning: ‘packed’ attribute ignored for field of type ‘uchar’ bgi/text.h:93: warning: ‘packed’ attribute ignored for field of type ‘uchar’ bgi/text.h:94: warning: ‘packed’ attribute ignored for field of type ‘uchar’ bgi/text.h:95: warning: ‘packed’ attribute ignored for field of type ‘uchar’ bgi/text.h:96: warning: ‘packed’ attribute ignored for field of type ‘schar’ bgi/text.h:97: warning: ‘packed’ attribute ignored for field of type ‘uchar[5]’ bgi/lnestyle.c: In function ‘setlinestyle’: bgi/lnestyle.c:51: warning: pointer targets in assignment differ in signedness bgi/lnestyle.c:54: warning: pointer targets in assignment differ in signedness bgi/lnestyle.c:57: warning: pointer targets in assignment differ in signedness -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJQmtb9AAoJEHaCPVPT4dXk6ggIANtrYw5/s0UKrd5x6uKtummJ ME6+P2NsJe1VSqUVm2VlAgTTTDrMv4xD5CPqRyGp6uMYmeUTlPtAubL+bbmlFh5R efKOgW6D6Xok73nWykUZxPWeBHztuu/DGb6eNE4h5n3iDexPwyzbZoU/nQpjgNOE eL2mDDYFikvgo9D4MOVr4QGDkLouktCNUH4lbV7l5dbMipydFkGV2jyKxoGFqty9 OX9cszrbcYdX3ru9RIrbFbY0p4rRjfFYQNsmrVbyrX/C5PP7XeY1gQAyrReLtWMT SI7+JNDEhdZJmD2fIBKjS1FIS7/EfjaoqOAqLmvUj1rhQPKBHGAWQyuVS0qLquA= =s97k -----END PGP SIGNATURE-----

2 1

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