hi all
i have adapted gÃŒnter's build system (and of course, overcomplicated things again ;-) :-( ) i have checked it into Gem/src and i do think it is ready for testing by now.
features: moved from src/Gnu to src checks work (e.g. for ARB-extensions) dependencies are generated on the fly (no need for Make.depend) source-files are generated on the fly (no need for Make.source) source-files containing white-spaces are ignored partial compilation support (e.g. skip openGL/ if you don't want it) usage of pkg-config automatic checking for apple-frameworks ...
caveats: i just _had_ to: add my own m4-code, esp. for package-detection (this is: per default use PKG_CHECK_MODULES, fall back to AC_CHECK_LIB ffmpeg-detection seems to work on my machines, but i am not sure whether it really does. GemLibs might be a bit ignored without manual tuning.
m4-features: added checks for flags supported by the compiler overcomplicated package-detection (see above: using PKG_CHECK_MODULES and as a fallback AC_CHECK_LIB)
m4-caveats: haven't found a way yet how to test for special linker flags.
file-layout:
src/acinclude.m4-(aclocal)->src/aclocal.m4-+ |-(autoconf)-> src/configure src/configure.ac---------------------------+
src/Make.config.in ---------------(./configure)-->src/Make.config
src/Base/config${KERN}.h.in --(./configure)-->src/Base/config${KERN}.h
with ${KERN} being $(uname -s) (Linux, Darwin,...)
src/Makefile includes src/Make.include includes src/Make.config master-makefile, cd's into subdirs and calls make there
src/Makefile.subdir includes src/Make.include includes src/Make.config makefile for subdirectories (called via "make -f ../Makefile.subdir")
both the old and the new build-system can live together (with the old build-system having files in src/*/ and the new one _only_ in src/)
in theory, you just need to check it out, cd to Gem/src and run "make" everything (including aclocal.m4 and configure) should be built as needed.
would be great if someone could test it (at least on linux-flavours and osX; i fear w32 will not work out of the box, but who knows)
mfg.asd.r IOhannes
Hi Johannes and gemers,
I just tried under OSX10.3 and I get tons of these:
g++ -c -fPIC -g -O2 -framework OpenGL -framework AGL -framework Carbon -framework QuickTime -freg-struct-return -O3 -fno-builtin -falign-loops=16 -funroll-loops -ffast-math -faltivec -ip -ipo_obj -I.. gemlist_info.cpp -o gemlist_info.o g++: -framework: linker input file unused because linking not done g++: OpenGL: linker input file unused because linking not done g++: -framework: linker input file unused because linking not done g++: AGL: linker input file unused because linking not done g++: -framework: linker input file unused because linking not done g++: Carbon: linker input file unused because linking not done g++: -framework: linker input file unused because linking not done g++: QuickTime: linker input file unused because linking not done
Is this 10.3 specific ?
Guenter
On Mon, 4 Jul 2005, IOhannes m zmoelnig wrote:
hi all
i have adapted g�nter's build system (and of course, overcomplicated things again ;-) :-( ) i have checked it into Gem/src and i do think it is ready for testing by now.
features: moved from src/Gnu to src checks work (e.g. for ARB-extensions) dependencies are generated on the fly (no need for Make.depend) source-files are generated on the fly (no need for Make.source) source-files containing white-spaces are ignored partial compilation support (e.g. skip openGL/ if you don't want it) usage of pkg-config automatic checking for apple-frameworks ...
caveats: i just _had_ to: add my own m4-code, esp. for package-detection (this is: per default use PKG_CHECK_MODULES, fall back to AC_CHECK_LIB ffmpeg-detection seems to work on my machines, but i am not sure whether it really does. GemLibs might be a bit ignored without manual tuning.
m4-features: added checks for flags supported by the compiler overcomplicated package-detection (see above: using PKG_CHECK_MODULES and as a fallback AC_CHECK_LIB)
m4-caveats: haven't found a way yet how to test for special linker flags.
file-layout:
src/acinclude.m4-(aclocal)->src/aclocal.m4-+ |-(autoconf)-> src/configure src/configure.ac---------------------------+
src/Make.config.in ---------------(./configure)-->src/Make.config
src/Base/config${KERN}.h.in --(./configure)-->src/Base/config${KERN}.h
with ${KERN} being $(uname -s) (Linux, Darwin,...)
src/Makefile includes src/Make.include includes src/Make.config master-makefile, cd's into subdirs and calls make there
src/Makefile.subdir includes src/Make.include includes src/Make.config makefile for subdirectories (called via "make -f ../Makefile.subdir")
both the old and the new build-system can live together (with the old build-system having files in src/*/ and the new one _only_ in src/)
in theory, you just need to check it out, cd to Gem/src and run "make" everything (including aclocal.m4 and configure) should be built as needed.
would be great if someone could test it (at least on linux-flavours and osX; i fear w32 will not work out of the box, but who knows)
mfg.asd.r IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
On Jul 6, 2005, at 5:28 AM, günter geiger wrote:
Hi Johannes and gemers,
I just tried under OSX10.3 and I get tons of these:
g++ -c -fPIC -g -O2 -framework OpenGL -framework AGL -framework Carbon -framework QuickTime -freg-struct-return -O3 -fno-builtin -falign- loops=16 -funroll-loops -ffast-math -faltivec -ip -ipo_obj -I.. gemlist_info.cpp -o gemlist_info.o g++: -framework: linker input file unused because linking not done g++: OpenGL: linker input file unused because linking not done g++: -framework: linker input file unused because linking not done g++: AGL: linker input file unused because linking not done g++: -framework: linker input file unused because linking not done g++: Carbon: linker input file unused because linking not done g++: -framework: linker input file unused because linking not done g++: QuickTime: linker input file unused because linking not done
Is this 10.3 specific ?
...aha! finally someone else tests out the osx stuff before me! :-)
...anyway, I'll get to trying out the "even newer" build system today...just looking at the g++ line I can already see lots of unfamiliar things, especially "-ip -ipo_obj"...
hang in there... jamie
ok,
...now I've tried it...
On Jul 6, 2005, at 10:03 AM, james tittle wrote:
On Jul 6, 2005, at 5:28 AM, günter geiger wrote:
Is this 10.3 specific ?
...nope, I get the same stuff on 10.4.1 with gcc-4.0...
...aha! finally someone else tests out the osx stuff before me! :-)
...anyway, I'll get to trying out the "even newer" build system today...just looking at the g++ line I can already see lots of unfamiliar things, especially "-ip -ipo_obj"...
hang in there...
...here's what I'm seeing when trying a "cold" make in Gem/src:
Result: Target : Gem.pd_darwin Objects : Base Controls Geos Manips MarkEx Nongeos Particles Pixes openGL
Configuration: Compiler : g++ CXXFLAGS : -g -O2 -framework OpenGL -framework AGL - framework Carbon -framework QuickTime -freg-struct-return -O3 -fno- builtin -falign-loops=16 -funroll-loops -ffast-math -faltivec -I/usr/ X11R6/include : -I/sw/include INCLUDES : DEFINES :
LIBS : -lGLU -lGL -lXext -lXxf86vm -lXext -lX11 - ldl -lz -lm -L/usr/X11R6/lib : -L/sw/lib -L/usr/X11R6/lib -llcms -ltiff - lfreetype -ljpeg -lpng -lXext -lXt -lSM -lICE -lX11 -lbz2 -lxml2 -lz - lm -lpthread -lMagick++ -lMagick LDFLAGS : -shared -Wl,-export-dynamic : -L/usr/X11R6/lib
Strip : strip -x
Install path : /usr/local
pure-data: version : 0.0
used optional libraries:
font-rendering :
image-support use ImageMagick : yes use TIFF : no use JPEG : no video-support use mpeg : no use mpeg-3 : no use QuickTime : no use aviplay : no use ffmpeg : no input-support use v4l : no use ieee1394 : no
misc using ARB-extensions : yes using reg-struct-ret : yes
compiler yes
Now run make ...
...just some thoughts:
* -framework isn't a CXXFLAG, it's a linker flag... * probably should default to no-x11 on osx, with the option of re- configuring if ya want to try it with gem (never have myself): plus, the libs will probably cause havoc conflicting with the frameworks (especially -lGL) * m_pd.h is found for me, but then I don't install into /usr/local * "-shared -Wl,-export-dynamic" isn't the correct way to link: we use "-bundle -bundle_loader /where/is/pd" * I'm not sure if we should use -O3, -Os is seemingly recommended in apple's docs (basically -O2 + smaller size)...
...those are just off the top of my head, will continue to poke around and re-configure as I used for the /src/gnu build system...
jamie
On Jul 6, 2005, at 11:22 AM, james tittle wrote:
...those are just off the top of my head, will continue to poke around and re-configure as I used for the /src/gnu build system...
...hmm, now I've tried:
tiggity:~/puredataDev/Gem/src tigital$ ./configure --includedir=../../ GemLibs:../../pd-0.38-4/src --with-ftgl --without-x configure: error: expected an absolute directory name for -- includedir: ../../GemLibs:../../pd-0.38-4/src
...is there any particular reason why configure needs an absolute directory name in this build system and not the src/gnu one?
jamie
james tittle wrote:
On Jul 6, 2005, at 11:22 AM, james tittle wrote:
...those are just off the top of my head, will continue to poke around and re-configure as I used for the /src/gnu build system...
...hmm, now I've tried:
tiggity:~/puredataDev/Gem/src tigital$ ./configure --includedir=../../ GemLibs:../../pd-0.38-4/src --with-ftgl --without-x configure: error: expected an absolute directory name for -- includedir: ../../GemLibs:../../pd-0.38-4/src
...is there any particular reason why configure needs an absolute directory name in this build system and not the src/gnu one?
i guess, "because the current directory is undefined"
anyhow, i noticed that i could perfectly well run a "configure"-script on osX (don't know which version though; i guess is 10.3; how can i get the osX-version from the command line??) that was made with autoconf on x86-linux.
jamie, what was your problem again with using a linux-generated configure-script ?
if there is none, i'd like to check one in, which would enable people with the wrong version of autoconf-tools installed to compile Gem without installing the correct version.
mfg.asd.r IOhannes
On Jul 7, 2005, at 7:49 AM, IOhannes m zmoelnig wrote:
james tittle wrote:
On Jul 6, 2005, at 11:22 AM, james tittle wrote:
...those are just off the top of my head, will continue to poke around and re-configure as I used for the /src/gnu build system...
...hmm, now I've tried: tiggity:~/puredataDev/Gem/src tigital$ ./configure -- includedir=../../ GemLibs:../../pd-0.38-4/src --with-ftgl --without-x configure: error: expected an absolute directory name for -- includedir: ../../GemLibs:../../pd-0.38-4/src ...is there any particular reason why configure needs an absolute directory name in this build system and not the src/gnu one?
i guess, "because the current directory is undefined"
...I thought it used to work? Isn't there a way for configure to know what directory it's in? In any case, it's just a bit more typing...
anyhow, i noticed that i could perfectly well run a "configure"- script on osX (don't know which version though; i guess is 10.3; how can i get the osX-version from the command line??) that was made with autoconf on x86-linux.
jamie, what was your problem again with using a linux-generated configure-script ?
if there is none, i'd like to check one in, which would enable people with the wrong version of autoconf-tools installed to compile Gem without installing the correct version.
...I didn't have any problem using the linux-generated configure- script: we deleted it from cvs because we wanted to force people to create their own so that it's as up-to-date as possible (remember, it was very old and crusty)...
...so to just to let off, here's how I'm configuring:
./configure --includedir=/Users/tigital/puredataDev/GemLibs --with- pd=/Users/tigital/pd-0.38-4/bin --with-ftgl --without-x --without- ImageMagick
...and here's the current output:
Result: Target : Gem.pd_darwin Objects : Base Controls Geos Manips MarkEx Nongeos Particles Pixes openGL
Configuration: Compiler : g++ CXXFLAGS : -g -O2 -freg-struct-return -O3 -fno- builtin -falign-loops=16 -funroll-loops -ffast-math -faltivec : INCLUDES : DEFINES :
LIBS : -ldl -lz -lm : LDFLAGS : -framework QuickTime -framework Carbon - framework AGL -framework OpenGL :
Strip : strip -x
Install path : /usr/local
pure-data: version : 0.0
used optional libraries:
font-rendering :
image-support use ImageMagick : use TIFF : use JPEG : video-support use mpeg : use mpeg-3 : use QuickTime : use aviplay : use ffmpeg : input-support use v4l : no use ieee1394 :
misc using ARB-extensions : yes using reg-struct-ret : yes
Now run make ...
almost there, james
On Thu, 7 Jul 2005, james tittle wrote:
./configure --includedir=/Users/tigital/puredataDev/GemLibs --with- pd=/Users/tigital/pd-0.38-4/bin --with-ftgl --without-x --without- ImageMagick
I think the --with-pd flag should point to the pd base directory, so the script can detect the binary and the include file m_pd.h at the same time.
--with-pd=/Applications/Pd-0.38-3/Contents/Resources on OSX for example
Guenter
...and here's the current output:
Result: Target : Gem.pd_darwin Objects : Base Controls Geos Manips MarkEx Nongeos Particles Pixes openGL
Configuration: Compiler : g++ CXXFLAGS : -g -O2 -freg-struct-return -O3 -fno- builtin -falign-loops=16 -funroll-loops -ffast-math -faltivec : INCLUDES : DEFINES :
LIBS : -ldl -lz -lm : LDFLAGS : -framework QuickTime -framework Carbon - framework AGL -framework OpenGL :
Strip : strip -x
Install path : /usr/local
pure-data: version : 0.0
used optional libraries:
font-rendering :
image-support use ImageMagick : use TIFF : use JPEG : video-support use mpeg : use mpeg-3 : use QuickTime : use aviplay : use ffmpeg : input-support use v4l : no use ieee1394 :
misc using ARB-extensions : yes using reg-struct-ret : yes
Now run make ...
almost there, james
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
On Jul 7, 2005, at 1:20 PM, günter geiger wrote:
On Thu, 7 Jul 2005, james tittle wrote:
./configure --includedir=/Users/tigital/puredataDev/GemLibs --with- pd=/Users/tigital/pd-0.38-4/bin --with-ftgl --without-x --without- ImageMagick
I think the --with-pd flag should point to the pd base directory, so the script can detect the binary and the include file m_pd.h at the same time.
--with-pd=/Applications/Pd-0.38-3/Contents/Resources on OSX for example
...very good idea: "kill two bird's with one stone"-kind of strategy :-) It's also good that it'll work with the application bundle...perhaps we should have the default on osx be "--with-pd=/ Applications/Pd.app/Contents/Resources", or whatever? This does bring up the issue that I think the application bundle should be called "Pd.app" or "Pd_devel.app", and have the version in the plist and/or have pd announce it's version on startup, like the externals do...
jamie
On Thu, 7 Jul 2005, james tittle wrote:
Applications/Pd.app/Contents/Resources", or whatever? This does bring up the issue that I think the application bundle should be called "Pd.app" or "Pd_devel.app", and have the version in the plist and/or have pd announce it's version on startup, like the externals do...
Not sure if this is really necessary. But then, it would make some things easier, and AFAIK on windows the pd folder comes without version too. Maybe you should propose this for the next release via the pd list. (Do not propose a Pd_devel.app though, Pd.app should be enough), different versions of PD can be installed into different folders by the user.
Guenter
jamie _______________________________________________ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
james tittle wrote:
ok,
...just some thoughts:
- -framework isn't a CXXFLAG, it's a linker flag...
ah yes, should've read this mail before i answered the last one.
- probably should default to no-x11 on osx, with the option of re-
configuring if ya want to try it with gem (never have myself): plus, the libs will probably cause havoc conflicting with the frameworks (especially -lGL)
hmm, gÃŒnter, what is the suggested way to handle such things with configure ?
- m_pd.h is found for me, but then I don't install into /usr/local
/usr/local is just the default installation path of configure; you should be able to set it with a flag to configure (but it is only of importance, if you want to install Gem via "make install"; otherwise you are safe by ignoring it)
- "-shared -Wl,-export-dynamic" isn't the correct way to link: we use
"-bundle -bundle_loader /where/is/pd"
well, again: configure should figure out, that "-shared ..." is invalid. for bundle-loader i have obviously used the wrong options.
- I'm not sure if we should use -O3,s is seemingly recommended in
apple's docs (basically -O2 + smaller size)...
aha. reading the man-page for g++ it says: "If you use multiple -O options, with or without level numbers, the last such option is the one that is effective."
and on "-Os" it says that it turns _off_ optimizazions that might increase size.
so to be on the safe side, it would probably be good to use "-Os -O3" (?)
...those are just off the top of my head, will continue to poke around and re-configure as I used for the /src/gnu build system...
ok.
i just noticed that our G4 is online and did some testing myself with the new configure thing. i hopefully fixed a lot of issues you 2 were having. i'll check them in in a second. finally it compiled, linked and stripped cleanly. unfortunately, i was having a break during compilation and when i cam back from dinner, the G4 was turned off. (it is physically located in one of our studios, and i guess it was too loud for the people working in there) so i don't know whether pd is able to load the produced library (and of course i have no idea, whether Gem will work once it is loaded)
ah, one last thing: i have also moved the content of macos_math.{h,cpp} into Base/GemMath.h. so in future we would just have to include "Base/GemMath.h" as opposed to <math.h> and the float vs. double thing will get corrected automatically.
mfg.as.dr IOhannes
On Jul 7, 2005, at 7:17 AM, IOhannes m zmoelnig wrote:
james tittle wrote:
ok, ...just some thoughts:
- -framework isn't a CXXFLAG, it's a linker flag...
ah yes, should've read this mail before i answered the last one.
...fixed!
- probably should default to no-x11 on osx, with the option of
re- configuring if ya want to try it with gem (never have myself): plus, the libs will probably cause havoc conflicting with the frameworks (especially -lGL)
hmm, günter, what is the suggested way to handle such things with configure ?
...fixed, but I'm still getting some x11 stuff because I have imagemagick via fink...unfortunately, --without-imagemagick doesn't seem to work, but --without-ImageMagick does: is it possible to make this work both ways?
- m_pd.h is found for me, but then I don't install into /usr/local
/usr/local is just the default installation path of configure; you should be able to set it with a flag to configure (but it is only of importance, if you want to install Gem via "make install"; otherwise you are safe by ignoring it)
...apparently here I made a typo! I meant to say that m_pd.h IS NOT being found, even with "--includedir=/absolute/path/to/pd/src": how else can I set this (outside of PATH environment variables)?
- "-shared -Wl,-export-dynamic" isn't the correct way to link:
we use "-bundle -bundle_loader /where/is/pd"
well, again: configure should figure out, that "-shared ..." is invalid. for bundle-loader i have obviously used the wrong options.
...haven't gotten this far, but it is good to have the "--with-pd=/ path/to/pd/bin" that you added...
- I'm not sure if we should use -O3,s is seemingly recommended
in apple's docs (basically -O2 + smaller size)...
aha. reading the man-page for g++ it says: "If you use multiple -O options, with or without level numbers, the last such option is the one that is effective."
and on "-Os" it says that it turns _off_ optimizazions that might increase size.
so to be on the safe side, it would probably be good to use "-Os - O3" (?)
...that's the thing: why have two "-Ox" flags if only the last one is effective? As far as -Os goes, apparently size increasing optimizations aren't necessarily desirable on a ppc: apple docs always suggest using -Os...otoh, I've never done profiling of -Os vs. -O3 code to see if there's any real difference in our case, so it's just speculation...
i just noticed that our G4 is online and did some testing myself with the new configure thing. i hopefully fixed a lot of issues you 2 were having. i'll check them in in a second. finally it compiled, linked and stripped cleanly. unfortunately, i was having a break during compilation and when i cam back from dinner, the G4 was turned off. (it is physically located in one of our studios, and i guess it was too loud for the people working in there) so i don't know whether pd is able to load the produced library (and of course i have no idea, whether Gem will work once it is loaded)
...what, ya'll don't have it in an anechoic chamber? ;-)
ah, one last thing: i have also moved the content of macos_math.{h,cpp} into Base/ GemMath.h. so in future we would just have to include "Base/GemMath.h" as opposed to <math.h> and the float vs. double thing will get corrected automatically.
...thanx for doing the janitorial cleanup!
jamie
On Thu, 7 Jul 2005, IOhannes m zmoelnig wrote:
- probably should default to no-x11 on osx, with the option of re-
configuring if ya want to try it with gem (never have myself): plus, the libs will probably cause havoc conflicting with the frameworks (especially -lGL)
hmm, g�nter, what is the suggested way to handle such things with configure ?
hmm, dont know yet, have to figure out what this really means. (I didn't know OSX has X windows development stuff installed)
Guenter
- m_pd.h is found for me, but then I don't install into /usr/local
/usr/local is just the default installation path of configure; you should be able to set it with a flag to configure (but it is only of importance, if you want to install Gem via "make install"; otherwise you are safe by ignoring it)
- "-shared -Wl,-export-dynamic" isn't the correct way to link: we use
"-bundle -bundle_loader /where/is/pd"
well, again: configure should figure out, that "-shared ..." is invalid. for bundle-loader i have obviously used the wrong options.
- I'm not sure if we should use -O3,s is seemingly recommended in
apple's docs (basically -O2 + smaller size)...
aha. reading the man-page for g++ it says: "If you use multiple -O options, with or without level numbers, the last such option is the one that is effective."
and on "-Os" it says that it turns _off_ optimizazions that might increase size.
so to be on the safe side, it would probably be good to use "-Os -O3" (?)
...those are just off the top of my head, will continue to poke around and re-configure as I used for the /src/gnu build system...
ok.
i just noticed that our G4 is online and did some testing myself with the new configure thing. i hopefully fixed a lot of issues you 2 were having. i'll check them in in a second. finally it compiled, linked and stripped cleanly. unfortunately, i was having a break during compilation and when i cam back from dinner, the G4 was turned off. (it is physically located in one of our studios, and i guess it was too loud for the people working in there) so i don't know whether pd is able to load the produced library (and of course i have no idea, whether Gem will work once it is loaded)
ah, one last thing: i have also moved the content of macos_math.{h,cpp} into Base/GemMath.h. so in future we would just have to include "Base/GemMath.h" as opposed to <math.h> and the float vs. double thing will get corrected automatically.
mfg.as.dr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
On Jul 8, 2005, at 11:07 AM, günter geiger wrote:
On Thu, 7 Jul 2005, IOhannes m zmoelnig wrote:
- probably should default to no-x11 on osx, with the option of re-
configuring if ya want to try it with gem (never have myself): plus, the libs will probably cause havoc conflicting with the frameworks (especially -lGL)
hmm, günter, what is the suggested way to handle such things with configure ?
hmm, dont know yet, have to figure out what this really means. (I didn't know OSX has X windows development stuff installed)
...just wanted to point out that the x11 stuff isn't installed by default: it's an extra package that can be "custom" installed...but it seems most savvy users have it...also, there's the possibility that it is installed via fink (ie. /sw/...)
l8r, jamie
james tittle wrote:
On Jul 6, 2005, at 5:28 AM, gÃŒnter geiger wrote:
Hi Johannes and gemers,
I just tried under OSX10.3 and I get tons of these:
g++ -c -fPIC -g -O2 -framework OpenGL -framework AGL -framework Carbon -framework QuickTime -freg-struct-return -O3 -fno-builtin -falign- loops=16 -funroll-loops -ffast-math -faltivec -ip -ipo_obj -I.. gemlist_info.cpp -o gemlist_info.o g++: -framework: linker input file unused because linking not done g++: OpenGL: linker input file unused because linking not done g++: -framework: linker input file unused because linking not done g++: AGL: linker input file unused because linking not done g++: -framework: linker input file unused because linking not done g++: Carbon: linker input file unused because linking not done g++: -framework: linker input file unused because linking not done g++: QuickTime: linker input file unused because linking not done
Is this 10.3 specific ?
oh damned. i thought "-framework bla" was a compiler-flag, and not a linker-flag. this explains why the compiler bails out.
...anyway, I'll get to trying out the "even newer" build system today...just looking at the g++ line I can already see lots of unfamiliar things, especially "-ip -ipo_obj"...
hmm, this means that the check for compiler-flags seems to not work correctly "-ip -ipo_obj" are flags for the icc vectorizer; GEM_CHECK_CXXFLAGS() should test whether the compiler is able to manage these flags, and if it does not fail, they are added to the CXXFLAGS. what does configure say when it comes to checking these ?
on my debian x86 using g++, it says: checking whether compiler accepts "-ip -ipo_obj"... no
you should get the same....
mfg.ad.sr IOhannes
-
g�nter geiger -
IOhannes m zmoelnig -
james tittle