Hi Glyn,
thanks for providing those details. It’s good to have a double check. The steps
are nearly identical to mine in the past, so it tells me the issues are not
related to my builds. I’ve made a few more commits to my github fork to fix
some of the crashes and I also had to reapply your strdup patch to fix a few
issues when building with gcc.
A few things to notice on the windows builds:
1)
Maybe a little bit too much, but I compiled Perl myself (using MSVC and
MinGW[-w64]). This way I get a perl with debug support if I want to. In the
MinGW-w64 installer the latest GCC version is 4.9.2. I did use the package
x86_64-4.9.2-posix-seh-rt_v4-rev2. But there is a bug where binutils aren’t
able to read .lib files generated by Visual Studio. I did get the “error adding
symbols: File format not recognized” for arapi81_build001_win64.lib
https://sourceware.org/bugzilla/show_bug.cgi?id=17910
After using an older GCC 4.8.4 the compilation worked.
Which brings me to the next point.
2)
I still had a hard time to get 64-bit binary working on windows. Then I
stumpled about this:
http://sourceforge.net/p/mingw-w64/wiki2/Answer%2064%20bit%20MSVC-generated%20x64%20.lib/
So it looks like the binutils still produce invalid results. I wrote a simple
c-program (without any perl involved) with just a single ARInitialization call
and got a crash. After reading the article above I had to gendef and produced a
new arapi81_build001_win64.a (.. did the same for arrpc* and arutil*). Now I
changed the “sub findArLibs” in the Makefile.PL to “my @libs = <*win64.a>;” so
it links to my new generated *.a files. That did the trick and I had a working
64-bit build using gcc. Btw, the same issue occured using the 64-bit version of
StrawberryPerl.
---
I put those details here in case someone wants to test the builds now and
stumples about the same issues. In the future I might take a look at how we can
handle those issues in the Makefile.PL automatically.
-John-
From: Tim Lank
Sent: Thursday, May 21, 2015 1:41 AM
To: ARSperl User Discussion
Subject: Re: [Arsperl-users] ARSperl - modernization efforts and long term
maintenance - May 18-19, 2015
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------------------------------------------------------------------------------
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
