Closed abmusse closed 8 years ago
Original comment by Aaron Bartell (Bitbucket: aaronbartell, GitHub: aaronbartell).
so to clarify, someone trying to do some simple node.js npm installs, that is considered bleeding edge?
My bleeding edge comment was based on versions of ibmichroot in relation to what's contained in 5733OPS.
Concerning npm installs, what you need to understand is you're not installing a simple Node module. There are 10's of thousands of Node modules that don't require compilation. This one isn't pure Javascript and instead relies on the guts on the V8 engine, which is written in C++, and therefore requires compilation.
What I have a harder time understanding is the developerWorks wiki that tells us only about the PTFs.
The 5733OPS opt 3 page does reference this repo, five separate times.
Original comment by Anonymous.
OK - that makes sense ... so to clarify, someone trying to do some simple node.js npm installs, that is considered bleeding edge?
I understand that the PTFs have potentially stale contents. I understand that this repo has potentially more recently updated contents. What I have a harder time understanding is the developerWorks wiki that tells us only about the PTFs.
And please understand, this is no criticism - I figure I'm just following the path that most noobs would follow and running into these challenges. Of course, this goes back to the group discussion in July and the new group discussion this week.
Original comment by Aaron Bartell (Bitbucket: aaronbartell, GitHub: aaronbartell).
but what about the others who have the same issue?
Opinion: 5733OPS is for those that aren't bleeding edge and can wait for features. Or another way to say it, ibmichroot repo will always be ahead of 5733OPS. The latest from this repo is what I always use. The sections that are under construction (i.e. yum) are adequately flagged in the README.md.
Original comment by Anonymous.
Indeed - I was using the pkg that was on the IBM i - latest PTFs, as documented on developerWorks. So that must be out of date?
The workaround as documented was not to alter the package, but I thought about that. No I just executed the wget and rpm as the workaround suggested. Things look good now for me - but what about the others who have the same issue?
Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).
What am I missing?
Appears libstdc++-devel-4.8.3-1.aix6.1.ppc.rpm was added added ...
Perhaps you need to download latest version ibmichroot.
#!shell
ibmichroot / pkg / pkg_perzl_gcc-4.8.3.lst
# rpm list
#
:rpm
# gcc
http://www.oss4aix.org/download/RPMS/gcc/gcc-4.8.3-1.aix6.1.ppc.rpm
http://www.oss4aix.org/download/RPMS/gcc/gcc-c++-4.8.3-1.aix6.1.ppc.rpm
http://www.oss4aix.org/download/RPMS/gcc/gcc-cpp-4.8.3-1.aix6.1.ppc.rpm
http://www.oss4aix.org/download/RPMS/gcc/libgcc-4.8.3-1.aix6.1.ppc.rpm
http://www.oss4aix.org/download/RPMS/gcc/libgomp-4.8.3-1.aix6.1.ppc.rpm
http://www.oss4aix.org/download/RPMS/gcc/libstdc++-4.8.3-1.aix6.1.ppc.rpm
http://www.oss4aix.org/download/RPMS/gcc/libstdc++-devel-4.8.3-1.aix6.1.ppc.rpm
http://www.oss4aix.org/download/RPMS/mpfr/mpfr-3.1.2-1.aix5.1.ppc.rpm
http://www.oss4aix.org/download/RPMS/gmp/gmp-6.0.0a-1.aix5.1.ppc.rpm
http://www.oss4aix.org/download/RPMS/libmpc/libmpc-1.0.2-1.aix5.1.ppc.rpm
http://www.oss4aix.org/download/RPMS/libsigsegv/libsigsegv-2.10-1.aix5.1.ppc.rpm
# utils
http://www.oss4aix.org/download/RPMS/make/make-4.1-1.aix5.3.ppc.rpm
http://www.oss4aix.org/download/RPMS/binutils/binutils-2.24-1.aix5.1.ppc.rpm
http://www.oss4aix.org/download/RPMS/bison/bison-3.0.4-1.aix5.1.ppc.rpm
http://www.oss4aix.org/download/RPMS/m4/m4-1.4.10-1.aix5.1.ppc.rpm
http://www.oss4aix.org/download/RPMS/gdb/gdb-7.8.2-1.aix5.1.ppc.rpm
# autotools
http://www.oss4aix.org/download/RPMS/autoconf/autoconf-2.63-1.aix5.1.ppc.rpm
http://www.oss4aix.org/download/RPMS/automake/automake-1.14.1-1.aix5.1.ppc.rpm
http://www.oss4aix.org/download/RPMS/libtool/libtool-1.5.26-2.aix5.1.ppc.rpm
Original comment by Aaron Bartell (Bitbucket: aaronbartell, GitHub: aaronbartell).
Best to convey output of installing pkg_perzl_gcc-4.8.3.lst
so we can see what happens when libstdc++...
is processed. Also post the contents of the .lst
file you changed.
Original comment by Anonymous.
So, I am going down this path months after this issue is resolved, and I'm a bit confused. I have the requirement to have this libstdc++ rpm, but it appears the lst was not updated as indicated above.
What am I missing?
Original comment by Aaron Bartell (Bitbucket: aaronbartell, GitHub: aaronbartell).
I have added the change in this commit
Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).
I have no objection to the add to the .lst. Please feel free to update.
BTW -- This is the nature of providing "gcc related build tooling and runtime" for people to build and run random Open Source. Aka, ALWAYS something missing, something new needed, etc. Frankly, we should expect evolution of .lst collection of 'popular tools and runtime' is inevitable. To wit, this case 'listed as a dependency' is only a mistake relative to whatever you happen to be building at the time (aka, 90% of projects do not need libstdc++ as they have no C++). So please expect the next guy to be equally surprised by lack of missing a critical 'dependency' (all relative to task).
Original report by Aaron Bartell (Bitbucket: aaronbartell, GitHub: aaronbartell).
This issue is being inspired by this opensource@midrange.com post. In it Kevin Turner describes the roadblock of needing the
algorithm
include and Kevin Alder (IBM) describes where/how to get it from perzl.I am recommending we add
libstdc++-devel-4.8.3
topkg_perzl_gcc-4.8.3.lst
.Since it is listed as a dependency on perzl.org I figure this was a mistake to not have in the first place.
Any objections?