I should also add the API version I used was: 812sp1
On Wed, May 20, 2015 at 7:21 PM, Tim Lank <[email protected]> wrote: > 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
