I'm not a Windows guy at all, and even I was able to get this to compile and run 'use ARS;' cleanly on Windows 7 Ultimate 64bit with Strawberry Perl 64bit. Very clearly written - thank you. I will try to include it in the INSTALLATION file updates
Compiling ARSPerl for Windows 32/64 =================================== 1) Download ARSPerl source zip from https://github.com/jeffmurphy/ARSperl and unpack 2) Download and install 32 or 64-bit Strawberry perl from strawberryperl.com 3) Download desired ARS API files from RRR and unpack 4) Edit Makefile.PL, and update $ARSAPI to indicate where ARS API files have been unpacked 5) If compiling for 64-bit, the following lines need updating in Makefile.PL as well (changes correct for 764sp5, may not be correct for all 64 ARS APIs?): $ARS_LIBS = join(' ', map { "$ARSAPI/lib/" . $_ } @{$ra_arlibs}); change to: $ARS_LIBS = join(' ', map { "$ARSAPI/lib64/" . $_ } @{$ra_arlibs}); $ARS_LDPATH = qq{-L"$ARSAPI/lib"}; change to: $ARS_LDPATH = qq{-L"$ARSAPI/lib64"}; my $ar_lib_dir = join('/', $path_to_api_dir, 'lib'); change to: my $ar_lib_dir = join('/', $path_to_api_dir, 'lib64'); 6) cd to ARSPerl directory and run perl Makefile.PL 7) dmake 8) If desired (and able!), run dmake test 9) dmake install Prior to using the compiled ARSPerl, update %PATH% first (paths correct for 764sp5, may not be correct for all ARS APIs?): 32-bit: Add the bin and lib directories from where the ARS API files were unpacked 64-bit: Add the lib64 directory from where the ARS API files were unpacked On Wed, May 20, 2015 at 5:38 PM, Glyn Davies <[email protected]> wrote: > So, I've now had a chance to look at compiling ARSPerl with ActiveState > Perl and the only thing that needs to be done to get it to compile is to > install MinGW. This is provided by ActiveState, and doing the following: > > ppm install MinGW > > will install a copy of gcc and dmake under the site directory that can > then be used to compile perl modules which include XS code. Once that's > done, the instructions I provided for compiling ARSPerl with Strawberry > Perl will do the trick. > > I did receive some compiler warnings when using perl binaries where there > is a mismatch between the ptrsize and ivsize as shown from the output of > perl -V. I came across this with both Strawberry and ActiveState 64-bit > perl binaries and 32-bit perl binaries where 64-bit integers are turned on. > These warnings relate to potential size mismatches when casting. > > Strawberry offer a 32-bit perl without the 64-bit ints turned on and the > warnings did not appear there. > > I've had a quick look into this, and there are some instances in the > source where making use of perl's PTR2UV/PTR2IV and INT2PTR macros allowed > the source to compile without any warnings being generated. > > Tim's kindly provided some info on how to use github, so I'll have a look > and providing the details of the updates tomorrow. From there, some testing > will be required as of course compiling is one thing - making sure it works > is another thing entirely :) > > Many thanks, > > Glyn > > ------------------------------ > Date: Wed, 20 May 2015 09:07:46 -0400 > From: [email protected] > To: [email protected] > Subject: [Arsperl-users] ARSperl - modernization efforts and long term > maintenance - May 18-19, 2015 > > > Tim Lank <timlank> > May 18 > to Jeff, Misi, support, thilo.stapff, thilo.stapff, jls17, Andrew, > bautista, makarow, gdf, wjm, gng, greg.george, Michiel.biejen, ggrabler, > matt.reinfeldt, Alex, conny.martin, i.d.trimnell > > > ARSperl community: > > I've compiled your name and email address as someone who has previously > invested significant time and sweat equity into ARSperl. > > http://sourceforge.net/projects/arsperl/ > As you know, Jeff and Joel Murphy created a great service to the community > back in 1995. For the last 20 years, this product has helped all of us in > some way. > Some of us still rely on this project code daily and want it to support > ARS as it moves to version 9 and beyond. > > If I understand correctly, Jeff no longer has convenient access to the API > packages, demo server, etc.. As a result, he has a limited ability to > code, test and maintain the project as he has so well in the past. > > My hope is that you will be interested in assisting with a modernization > effort and ongoing longer-term maintenance of the project. Please chime > in to this thread if you are interested. > Sincerely, > Tim Lank > > > > Andrew Hicox <andrew> > May 18 > to me, support, wjm, bautista, Alex, Misi, thilo.stapff, jls17, Jeff, > conny.martin, matt.reinfeldt, greg.george, makarow, ggrabler, > Michiel.biejen, i.d.trimnell, gng, gdf, thilo.stapff > > > Thanks for sending this out, Tim! > I'm quite interested in this. In fact, not a day goes by that I don't > need ARSPerl for something. It's just too damn handy of a tool, to let it > permanently fall by the wayside, so definitely count me in. > So ...what is the current status? I see the module has been forked on > github. Do we have a working 64 bit version yet? Are we at the point where > we just need to test and bug fix then get it back on cpan? > Let me know where to help, and I'll jump right in :-) > Andy > > > jeff murphy <jcmurphy> > May 18 > to Andrew, me, support, wjm, bautista, Alex, Misi, thilo.stapff, jls17, > conny.martin, matt.reinfeldt, greg.george, makarow, ggrabler, > Michiel.biejen, i.d.trimnell, gng, gdf, thilo.stapff > > > thanks to John Luthgers work the code on GH should work on 64bit now. i > linked github and SF but need to doublecheck to make sure that’s working (I > do all of my dev on GH these days). the code needs some love to get it > working and packaged on Windows. once that occurs and people are happy with > the results, I will cut a release and post to CPAN and SF. > > > > Misi Mladoniczky > May 18 > to me, Jeff, support, thilo.stapff, thilo.stapff, jls17, Andrew, bautista, > makarow, gdf, wjm, gng, greg.george, michiel.biejen, ggrabler, > matt.reinfeldt, Alex, conny.martin, i.d.trimnell > > > Hi, > > If someone missed it, I regularly publish the API packages for download: > https://rrr.se/cgi/index?pg=arapi > > As you see, for version 9, there are only Windows and Linux versions. I am > waiting for BMC to supply the other platforms for download. > > Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) > > Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13): > * RRR|License - Not enough Remedy licenses? Save money by optimizing. > * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. > Find these products, and many free tools and utilities, at http://rrr.se. > > > Tim Lank <timlank> > May 18 > to glynd1972, jeff, Andrew, support, wjm, bautista, Alex, Misi, > thilo.stapff, jls17, conny.martin, matt.reinfeldt, greg.george, Makarow, > Georg, i.d.trimnell, gng, David, thilo.stapff, Michiel.beijen > > > including Glyn Davies (previously contributed Win32 code) and correcting > email address for Michiel Beijen..... > Link to GH: https://github.com/jeffmurphy/ARSperl > Thanks, > Tim > > > Andrew Hicox <andrew> > May 18 > to Misi, me, support, wjm, bautista, Alex, thilo.stapff, jls17, Jeff, > conny.martin, matt.reinfeldt, michiel.biejen, greg.george, makarow, > ggrabler, i.d.trimnell, gng, gdf, thilo.stapff > > > Wow, that is a really handy resource for getting the api. Thank you! Its > sort of astounding that bmc themselves can't manage to put a dead simple > page like that together. > So, I'm trying to compile the latest ARSperl from github, against the > 812sp1 Linux api ... > The makefile.pl complains that licuucbmc_lx64, licuil8nbmc_lx64, and > licudatabmc_lx64 are missing. However nothing like that appears to be in > the ars api directory. Maybe I need to make some symlinks or something? > It makes without error, but attempts to 'use ARS;' provoke an exception > from dynaloader, via ARS.so "undefined symbol: u_toupper _3_2" > Maybe I need an older api? Anyone got this one working on 8.1 yet, or am I > venturing I to uncharted teritorry? > -Andy > > > Tim Lank <timlank> > May 18 > to Andrew, Misi, support, bautista, Alex, thilo.stapff, jls17, Jeff, > conny.martin, matt.reinfeldt, greg.george, Makarow, Georg, i.d.trimnell, > gng, David, thilo.stapff, glynd1972, Michiel > > > Andrew, > > I was able to use the ARSperl from github and compiled and am running > against the 764sp5 Linux api without any problems. I did adjust the > Makefile.PL and made links > > $ARSAPI = <path to the api> > $ARSVERSION = 7.64 > $ARCHITECTURE = "lx64" > > cp api764sp5linux/bin/* api764sp5linux/lib > > cd api764sp5linux/lib > > ln -s libicudatabmc.so.32 libicudatabmc.so > > ln -s libicui18nbmc.so.32 libicui18nbmc.so > > ln -s libicuiobmc.so.32 libicuiobmc.so > > ln -s libicuucbmc.so.32 libicuucbmc.so > > ln -s libicudatabmc_lx64.so.32 libicudatabmc_lx64.so > > ln -s libicui18nbmc_lx64.so.32 libicui18nbmc_lx64.so > > ln -s libicuiobmc_lx64.so.32 libicuiobmc_lx64.so > > ln -s libicuucbmc_lx64.so.32 libicuucbmc_lx64.so > > These might be useful.... > http://sourceforge.net/p/arsperl/mailman/arsperl-users/?viewmonth=201505 > http://sourceforge.net/p/arsperl/mailman/arsperl-users/?viewmonth=201502 > > Setting the LD_LIBRARY_PATH might also be helpful. > > > Misi has had success also and of course John Luthgers (jls17 at GMX dot > NET) would know the most since he wrote the 64-bit pieces. > > > Thanks, > Tim > > Luthgers, John > May 18 > to me, jeff, Andrew, support, wjm, bautista, Alex, Misi, thilo.stapff, > conny.martin, matt.reinfeldt, greg.george, Makarow, Georg, i.d.trimnell, > gng, David, thilo.stapff, glynd1972, Michiel.beijen > > > Hi, > > Currently I’m planning to add support to compile arsPerl using arapi 9.0 > and the second task is getting a stable windows version. I used Visual > Studio to build arsPerl on Windows and there were lots of crashes related > to freeing memory allocated by other components (Perl, ARSperl and ARAPI). > The conclusion was memory allocated by ARAPI needs to be freed by ARAPI and > memory allocated by Perl must be freed by Perl. In case Perl and ARAPI are > using different C++-runtimes (each has it’s own memory management), this > looks like the only solution. But quite a lot of work is necessary, because > we need memory-routines for many structures. In case someone has build a > stable Windows version previously and can suggest a better solution to this > issue, any help would be appreciated. > > After reading parts of the code I think there are lots of features missing > introduced by the last couple of api-releases (maybe back to 7.5?). At the > same time I don’t know if support of those missing things is relevant to > other people .. we are using ARSperl mainly for data manipulation tasks and > the capabilities are sufficient in most cases. So I’m not sure what > features others are interested in. > > The latest changes were (this code is now in Jeff’s github repo): > - Linux 64bit is working using GCC > - Compiling using ARAPI 8.0 / 8.1 possible > - added new functions: ars_GetSessionConfiguration, ars_SetOverlayGroup, > ars_SwitchToBestPracticeMode and ars_SwitchToBaseMode > - automatic API-Version detection in Makefile.PL > - dropped support to compile ARSperl using ARAPI below version 4.5 > - small bugfixes > > I don’t know how much effort I can spent on ARSperl in the future, but I > try to help out if possible. > > Greetings > -John- > > > Luthgers, John > May 18 > to me, Andrew, Misi, support, bautista, Alex, thilo.stapff, Jeff, > conny.martin, matt.reinfeldt, greg.george, Makarow, Georg, i.d.trimnell, > gng, David, thilo.stapff, glynd1972, Michiel > > > Andrew, > > like you and everybody else learned the hard way: not even BMC is able to > put all necessary library files in one place. The files are located across > different folders of the server installation and the best thing is the > icudt32.dll on windows. One filename for 32-bit and 64-bit, but ofc > different content. But like Tim pointed out, a few symlinks and you should > be fine. And the latest code on github should work up to api-version 8.1. > Just put all necessary library files in one folder, add the symlinks and > set the LD_LIBRARY_PATH to this lib-folder. > > -John- > > > > Misi Mladoniczky > May 19 > to John, me, Andrew, support, bautista, Alex, thilo.stapff, Jeff, > conny.martin, matt.reinfeldt, greg.george, Makarow, Georg, i.d.trimnell, > gng, David, thilo.stapff, glynd1972, Michiel > > > Hi, > > The scripts I use to extract the API-packages are supposed to find all > these > scattered files and put them in the /api812sp1/bin/ directory. I also try > to > rename them to whatever name is required. The idea is to NOT need to do all > the symlinks. > > If I have missed any files, or if they have the wrong name. Please let me > know > and I will try to fix it. > > Best Regards - Misi, RRR AB, http://rrr.se > > > Tim Lank <timlank> > May 19 > to Misi, John, Andrew, support, bautista, Alex, thilo.stapff, Jeff, > conny.martin, matt.reinfeldt, greg.george, Makarow, Georg, i.d.trimnell, > gng, David, thilo.stapff, glynd1972, Michiel > > > Misi, > > Thanks a ton for doing all of this, it is a huge service. > > These files do end up in the bin directory in what I pull & extract from > your site. The compiler/linker seems to need to see them in the lib > directory (also? I can't remember - perhaps its just the lib directory > presence needed - probably a good test to make). I do know that when > symlinks are created from those files in bin to lib, then everything seems > happier. > > > Misi Mladoniczky > May 19 > to me, John, Andrew, support, bautista, Alex, thilo.stapff, Jeff, > conny.martin, matt.reinfeldt, greg.george, Makarow, Georg, i.d.trimnell, > gng, David, thilo.stapff, glynd1972, Michiel > > > Hi, > > Did you set LD_LIBRARAY_PATH to point to the bin directory as well? > > In the distribution I like to keep it separated in the bin directory so > that > you can easily find the files I picked from outside the actual api > directory. > > I set this manually in the resulting Makefile: > LD_RUN_PATH = /opt/bmc/api764sp2linux/bin > > But I guess it will work just as fine to copy/link the so-files to/from the > lib directory. > > > Misi Mladoniczky > May 19 > to me, John, Andrew, support, bautista, Alex, thilo.stapff, Jeff, > conny.martin, matt.reinfeldt, greg.george, Makarow, Georg, i.d.trimnell, > gng, David, thilo.stapff, glynd1972, Michiel > > > Hi, > > I added it to two more places in my Makefile: > > Makefile:EXTRALIBS = -L/opt/bmc/api764sp2linux/lib > -L/opt/bmc/api764sp2linux/bin -licuucbmc_lx64 -licui18nbmc_lx64 > -licudatabmc_lx64 > > Makefile:LDLOADLIBS = -L/opt/bmc/api764sp2linux/lib > -L/opt/bmc/api764sp2linux/bin -lnsl -lpthread -licuucbmc_lx64 > -licui18nbmc_lx64 -licudatabmc_lx64 > > Makefile:LD_RUN_PATH = /opt/bmc/api764sp2linux/bin > > > Glyn Davies > May 19 > to John, Michiel.beijen, bautista, i.d.trimnell, Georg, thilo.stapff, > David, greg.george, Misi, thilo.stapff, Makarow, conny.martin, support, > gng, Andrew, me, Alex, matt.reinfeldt, jeff, wjm > > > It's been a while since I've compiled ARSperl on Windows, but hopefully I > can provide some helpful info based on my experiences. The first couple of > points will probably hold true across all platforms, but did seem > especially important for Windows! > The first thing to mention is that I found it best to compile ARSperl > using the same compiler as was used to produce the perl binary. This was to > ensure no issues related to runtime libraries between perl and the ARSperl > DLL (this was based around info found on the following link: > http://community.activestate.com/faq/windows-compilers-perl-modules). > The other piece of advise I have is that if you're compiling ARSperl for a > number of different Windows versions, then compile on the oldest one you > intend to work with. This will avoid any potential problems with linking > against libraries that might not be available on older versions. > For the project I was working on, I started off with Strawberry Perl so > this was straightforward enough as that comes with its own build > environment (GCC, dmake, etc.). Due to requirements of the project, I ended > up compiling my own perl binary using the Citrus GCC binaries ( > http://sourceforge.net/projects/perlmingw) and compiling ARSperl from > that. > I did look at ActiveState Perl as well briefly, and for that a compiler > that links against plain old MSVCRT.DLL was required (rather than a version > specific MS runtime DLL). On the 32-bit side this meant either using Visual > Studio 6, or MinGW. I may have some notes on compiling ARSperl for > ActiveState Perl using MinGW, so I'll see what I can turn up with regards > to that. > Not sure about the 64-bit version of ActiveState Perl, but I'd assume the > same should be possible there (with VS 2003's compiler or a 64-bit MinGW?). > My work has moved on, and I've not worked with Remedy for nearly 18 months > now and don't even have access to a system running Remedy. So while I can > provide advice or test building ARSperl, I don't have the ability to > actually test functionality of the library unfortunately. > Hope this info helps, and if I find my notes on compiling ARSperl for > ActiveState Perl with MinGW then I'll add that into this thread. > Many thanks, > Glyn > > > Luthgers, John > May 18 > > Hi, > > Currently I’m planning to add support to compile arsPerl using arapi 9.0 > and the second task is getting a stable windows version. I used Visual > Studio to build arsPerl on Windows and there were lots of crashes related > to freeing memory allocated by other components (Perl, ARSperl and ARAPI). > The conclusion was memory allocated by ARAPI needs to be freed by ARAPI and > memory allocated by Perl must be freed by Perl. In case Perl and ARAPI are > using different C++-runtimes (each has it’s own memory management), this > looks like the only solution. But quite a lot of work is necessary, because > we need memory-routines for many structures. In case someone has build a > stable Windows version previously and can suggest a better solution to this > issue, any help would be appreciated. > > After reading parts of the code I think there are lots of features missing > introduced by the last couple of api-releases (maybe back to 7.5?). At the > same time I don’t know if support of those missing things is relevant to > other people .. we are using ARSperl mainly for data manipulation tasks and > the capabilities are sufficient in most cases. So I’m not sure what > features others are interested in. > > The latest changes were (this code is now in Jeff’s github repo): > - Linux 64bit is working using GCC > - Compiling using ARAPI 8.0 / 8.1 possible > - added new functions: ars_GetSessionConfiguration, ars_SetOverlayGroup, > ars_SwitchToBestPracticeMode and ars_SwitchToBaseMode > - automatic API-Version detection in Makefile.PL > - dropped support to compile ARSperl using ARAPI below version 4.5 > - small bugfixes > > I don’t know how much effort I can spent on ARSperl in the future, but I > try to help out if possible. > > Greetings > -John- > > Tim Lank > May 18 > > including Glyn Davies (previously contributed Win32 code) and correcting > email address for Michiel Beijen..... > Link to GH: https://github.com/jeffmurphy/ARSperl > > Thanks, > Tim > > > Tim Lank <timlank> > May 19 > to Misi, John, Andrew, support, bautista, Alex, thilo.stapff, Jeff, > conny.martin, matt.reinfeldt, greg.george, Makarow, Georg, i.d.trimnell, > gng, David, thilo.stapff, glynd1972, Michiel > > > Hi Misi, > I really don't want to cause a stir or a problem here. The overriding > sentiment to take away from this is that I think we all are really, really > appreciative of your willingness to provide what you do at this site to the > community at large. I can't imagine it not being publicly available as you > have made it. What I can't say enough is THANK YOU! > Having said all that, what I have to say below is extremely minor.... > > I guess I've always liked to try and follow the Filesystem Hierarchy > Standard (http://www.pathname.com/fhs/pub/fhs-2.3.pdf) which specifies to > keep executable/command/binaries in directories called "bin" and keep > library files (those compiled files that are not capable of > executing/running on their own) in directories called "lib". > This is what the Makefile.PL as provided seems to want also as evidenced > in this portion which MakeMaker turns into the actual Makefile: > > if( $WINDOWS ){ > $ARS_LDPATH = qq{-L"$ARSAPI/lib"}; > $INCLUDES = qq{-I"$ARSAPI/include"}; > }else{ > $ARS_LDPATH = "-L$ARSAPI/lib"; > $INCLUDES = "-I$ARSAPI/include"; > } > By putting all of the libraries into lib, and symlinking them to have the > shortened names as the Makefile.PL wants as shown here (the .32 extension > is notably absent from what is specified) > > if ($GNU_WIN) { > $ARS_LIBS = join(' ', map { "$ARSAPI/lib/" . $_ } @{$ra_arlibs}); > } elsif ($WINDOWS) { > $ARS_LIBS = join(' ', map { '-l' . $_ } @{$ra_arlibs}); > } else { > $ARS_LIBS .= " -lpthread "; > $ARS_LIBS .= " -licuucbmc$LARCH -licui18nbmc$LARCH > -licudatabmc$LARCH " if $ARAPIVERSION >= ARS_VERSION_70; > } > This eliminates the need to go and modify the Makefile at all. > Setting the LD_LIBRARY_PATH in this case to be the resulting lib directory > (in my case /opt/remedy/api764sp5linux/lib) may not even be needed for the > make, but I do it for good hygiene and so that things are subsequently > found at runtime. A more permanent solution would be to create a > /etc/ld.so.conf.d/arsperl.conf with this path as content and run ldconfig > (see Alex's post to arsperl-users). > So with what I pull from your website, and dropping John's code into a > directory by the name of /opt/remedy/ARSperl-1.93, I can simply do the > following: > > cd /opt/remedy > mv api764sp5linux/bin/* api764sp5linux/lib > cd api764sp5linux/lib > ln -s libicudatabmc.so.32 libicudatabmc.so > ln -s libicui18nbmc.so.32 libicui18nbmc.so > ln -s libicuiobmc.so.32 libicuiobmc.so > ln -s libicuucbmc.so.32 libicuucbmc.so > ln -s libicudatabmc_lx64.so.32 libicudatabmc_lx64.so > ln -s libicui18nbmc_lx64.so.32 libicui18nbmc_lx64.so > ln -s libicuiobmc_lx64.so.32 libicuiobmc_lx64.so > ln -s libicuucbmc_lx64.so.32 libicuucbmc_lx64.so > > > export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/remedy/api764sp5linux/lib > > > cd ../../ARSperl-1.93 (John's forked version) > vi Makefile.PL > > ensure the following are set properly: > $ARSAPI = "/opt/remedy/api764sp5linux"; > $ARCHITECTURE = "lx64"; # Linux 64-bit > > > perl Makefile.PL > make > make install > If you were willing to copy all of the contents of the bin over to lib and > create the symlinks before performing the tar.gz on the structure, that > would eliminate the entire first section of my procedure. > Of course if you'd rather not do that, it is absolutely fine and we will > adapt as needed. > Again, we are nothing but thankful for what you are doing. > > Thanks, > Tim > > > Misi Mladoniczky > May 19 > to me, John, Andrew, support, bautista, Alex, thilo.stapff, Jeff, > conny.martin, matt.reinfeldt, greg.george, Makarow, Georg, i.d.trimnell, > gng, David, thilo.stapff, glynd1972, Michiel > > > Hi Tim > > I will not argue with this. I do not feel qualified to do so in any event > ;-) > > There are trhee original reasons for me to create the api/bin-directory. > 1. The files are found inte serverinstall/bin directory > 2. I wanted to have have a directory containing only the files that need > to be > shipped together with any executable you compile > 3. I wanted to separate what was originally contained in the > serverinstall/api > directory from the files I added > > I can certainly move everything to the lib directory if you feel that is > better. > > I can also create some symlinks as you describe. > > I could also create symlinks from the lib to the bin directory. > > In the Windows distribution I have a bin and bin64 directory. I guess I > should > copy the files into the respective lib and lib64 directory. > > Should I go ahead and do this? > > > Tim Lank <timlank> > May 19 > to Misi, John, Andrew, support, bautista, Alex, thilo.stapff, Jeff, > conny.martin, matt.reinfeldt, greg.george, Makarow, Georg, i.d.trimnell, > gng, David, thilo.stapff, glynd1972, Michiel > > > Misi, > > Totally up to you. A compromise might be to perform a cp instead of a mv > to keep two copies, retain the one in bin and have a new one in lib. > Afterwards, within the lib directory, create the symlinks in there. I > don't think there would be a need to create symlinks from the lib to bin > directory though. > Afterwards, the normal tar gzip process you do "should" retain the > symlinks. > I really can't speak about the Windows distribution since I'm a Linux-only > guy. > Maybe Glyn or John would have an opinion on that? > > Thanks, > Tim > > > Andrew Hicox <andrew> > May 19 > to Misi, me, John, support, bautista, Alex, thilo.stapff, Jeff, > conny.martin, matt.reinfeldt, greg.george, Makarow, Georg, i.d.trimnell, > gng, David, thilo.stapff, glynd1972, Michiel > > > Thanks everyone, setting up the symlinks to the *.so files in the api bin > directory fixed it right up. Now I've got 64-bit ARSPerl on Linux! No more > having to custom compile a 32-bit perl interpreter ... no more needing to > make sure 32-bit compat libs are installed for every dependency of every > other module I need on my 32-bit perl! > w00t! Seriously ... this is such a huge thing! > > We need to get this back to CPAN with a quickness, Dare I say it, even if > it doesn't work on Windows ... if we must, just release a "beta" module to > CPAN or whatever. That's where everyone is looking ... that's where I > looked for years and years, and presumed the module must just be dead, and > that I was one of maybe two or three people in the world stil using it. > I had no idea this effort even existed until Tim contacted me about a > separate issue with Remedy::ARSTools (which has ARSPerl as a dependency). I > think were this thing updated on CPAN (where people looking for this module > are more than likely going), and if maybe a blurb were put in the release > README or something, we might find more contributers. Might be worth > posting on ARSList and BMC Communities too. The more people we have > involved the better ... as several here have mentioned moving on to other > responsibilities, not having access to an ARServer to test etc ... if we > want this module to continue to live (I do!) then we need more cooks in the > kitchen. > > A couple of notes from the build: > 1) Regarding the symlinks etc ... > The Makefile.PL throws the "probably harmless" error for the missing libs. > We need to fix that warning ... as it's actually fatal. Taking it a step > further, I think it'd be pretty easy to hack a little section onto the > Makefile.PL that descends the API directory looking for the missing *.so > files, and spits out a blurb about needing to create the symlinks. Better > still, if the user executing the Makefile.PL has permissions, the script > could actually make the symlinks. I'd be willing to take on that > modification, if you guys agree that's a direction to take. > 2) MANIFEST appears to have some bogus entries > I get this warning when executing the Makefile.PL: > Checking if your kit is complete... > Warning: the following files are missing in your kit: > .#Makefile.PL.1.85 > blib/arch/.exists > blib/arch/auto/ARS/.exists > blib/bin/.exists > blib/lib/.exists > blib/lib/ARS.pm > blib/lib/ARS/ar-h.pm > blib/lib/ARS/arerrno-h.pm > blib/lib/ARS/nparm.pm > blib/lib/ARS/OOform.pm > blib/lib/ARS/OOmsgs.pm > blib/lib/ARS/OOsup.pm > blib/lib/auto/ARS/.exists > blib/lib/auto/ARS/autosplit.ix > blib/man1/.exists > blib/man3/.exists > blib/script/.exists > Makefile > Makefile.old > pm_to_blib > t/config.cache > Please inform the author. > I suspect we just need to remove these from the MANIFEST? > I'd be happy to take that action too, unless someone objects. > -Andy > > > > > Tim Lank <timlank> > May 19 > to Glyn, John, Michiel, bautista, i.d.trimnell, Georg, thilo.stapff, > David, greg.george, Misi, thilo.stapff, Makarow, conny.martin, support, > gng, Andrew, Alex, matt.reinfeldt, jeff, wjm > > > Jeff, > In light of the complexity of migrating Windows code to 64-bit and the > lack of experienced Windows developers that have the time, ability, > willingness, tools & vested interest to complete this... > Would you entertain cutting a release without Windows 64bit capabilities & > moving on for the rest of the community? > Thanks, > Tim > > > jeff murphy <jcmurphy> > May 19 > to me, Glyn, John, Michiel, bautista, i.d.trimnell, Georg, thilo.stapff, > David, greg.george, Misi, thilo.stapff, Makarow, conny.martin, support, > gng, Andrew, Alex, matt.reinfeldt, wjm > > > yeah, i’ll post a pkg to CPAN with a note about compatibility > > > Glyn Davies > May 19 > to jeff, me, John, Michiel, bautista, i.d.trimnell, Georg, thilo.stapff, > David, greg.george, Misi, thilo.stapff, Makarow, conny.martin, support, > gng, Andrew, Alex, matt.reinfeldt, wjm > > > Hopefully this may be of use to you all, but I've just refreshed my memory > on how I'd done this in the past and have had a go at compiling 32 and > 64-bit Windows ARSperl against the 764sp5 ARS API files and Strawberry > Perl. I was able to compile successfully and then run perl -e "use ARS;" > without any DLL-related errors for both 32 and 64-bit versions. > > Unfortunately, that's as far as I can take it in terms of testing, so > hopefully somebody else will be able to follow the attached notes and do > some more thorough testing than I managed! > > I have found my compiling against ActiveState perl and MinGW notes but > they're a little out of date and only cover 32-bit, so I need to have a > look over them to get something that works. > > The only other I'd mention is that it looked like the modifications I put > forward for supportrev.h and supportrev.c have been lost in the last update > to those files? The updates were required to avoid issues I ran up against > when ARSperl was trying to free memory following compilation with gcc on > Windows. > > If they are indeed missing, then it's something to bear in mind if memory > related issues are encountered during testing (specifically I hit the > problem when passing strings to update fields with ars_SetEntry). It could > be that the problem has gone away now, but I thought I'd mention it. > > I'll report back on how I get on with compiling using ActiveState Perl > once I've had a chance to look into that. > > If there's any further help I can provide in the meantime, then please let > me know! > > Cheers, > > Glyn > ________________________________________ > Attachments area > Compiling ARSPerl for Windows 32/64 > =================================== > > 1) Download ARSPerl source zip from https://github.com/jeffmurphy/ARSperl > and unpack > > 2) Download and install 32 or 64-bit Strawberry perl from > strawberryperl.com > > 3) Download desired ARS API files from RRR and unpack > > 4) Edit Makefile.PL, and update $ARSAPI to indicate where ARS API files > have been unpacked > > 5) If compiling for 64-bit, the following lines need updating in > Makefile.PL as well (changes correct for 764sp5, may not be correct for all > 64 ARS APIs?): > > $ARS_LIBS = join(' ', map { "$ARSAPI/lib/" . $_ } @{$ra_arlibs}); > change to: > $ARS_LIBS = join(' ', map { "$ARSAPI/lib64/" . $_ } @{$ra_arlibs}); > > $ARS_LDPATH = qq{-L"$ARSAPI/lib"}; > change to: > $ARS_LDPATH = qq{-L"$ARSAPI/lib64"}; > > my $ar_lib_dir = join('/', $path_to_api_dir, 'lib'); > change to: > my $ar_lib_dir = join('/', $path_to_api_dir, 'lib64'); > > 6) cd to ARSPerl directory and run perl Makefile.PL > > 7) dmake > > 8) If desired (and able!), run dmake test > > 9) dmake install > > Prior to using the compiled ARSPerl, update %PATH% first (paths correct > for 764sp5, may not be correct for all ARS APIs?): > > 32-bit: Add the bin and lib directories from where the ARS API files > were unpacked > 64-bit: Add the lib64 directory from where the ARS API files were unpacked > > > > Michiel Beijen > May 19 > to ARSperl, Glyn, jeff, me, John, bautista, i.d.trimnell, Georg, > thilo.stapff, David, greg.george, Misi, thilo.stapff, Makarow, > conny.martin, support, gng, Andrew, Alex, matt.reinfeldt, wjm > > > Hi all, > > I just created two 'housekeeping' related pull requests at > https://github.com/jeffmurphy/ARSperl/pulls > > can we maybe take this (probably useful) discussion to the existing > mailinglist (cc) for developers or maybe even for users? A big running > email thread with lots of CC's is kind of annoying. > > -- > Michiel > > > Michiel Beijen > May 19 > to ARSperl, Glyn, jeff, me, John, bautista, i.d.trimnell, Georg, > thilo.stapff, David, greg.george, Misi, thilo.stapff, Makarow, > conny.martin, support, gng, Andrew, Alex, matt.reinfeldt, wjm, ARSperl > > > The address @arsperl.org does not seem to be working. Tried sourceforge > mailing list address. > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications Performance > metrics, stats and reports that give you Actionable Insights Deep dive > visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > -- Arsperl-users mailing list [email protected] > https://lists.sourceforge.net/lists/listinfo/arsperl-users > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > > > -- > Arsperl-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/arsperl-users >
------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
-- Arsperl-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/arsperl-users
