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
