I usually do stack install <package-name> and Stack installs it in the location ~/.local/bin.
Is there a way for me to specify the destination location ?
You can use the --local-bin-path to specify your custom destination path. Demo:
$ stack install tldr --local-bin-path /home/sibi
Copying from /home/sibi/github/tldr-hs/.stack-work/install/x86_64-linux/lts-12.10/8.4.3/bin/tldr to /home/sibi/tldr
Copied executables to /home/sibi:
- tldr
Warning: Installation path /home/sibi not found on the PATH environment variable.
$ ls -lh /home/sibi/tldr
-rwxr-xr-x 1 sibi sibi 3.0M Dec 23 01:37 /home/sibi/tldr
Related
I build my first rpm package. It is the prescriped way to deploy applications to our distributed SuSE Servers.
The application is build with NodeJs and Typescript.
We have a build step that transcribes the Typescript to Javascript into a dist folder. NPM provides the dependencies in a node_modules folder. Then there are some .env config files, a bash script to start the application called myApplication and a init.d script called myDaemon. These are all packed into a tar.gz file. The structure is the following:
myApplication.tar.gz
|
|--dist
| |
| |-index.js
| |-...
|
|--node_modules
| |
| |-dependency_a
| |-dependency_b
| |-...
|
|--.env
|--.env.production
|--.env.development
|--.env.sample
|--myApplication
|--myDaemon
The rpmbuild unpacks the tar.gz file, creates the needed folders in the build root and copies the files to the correct folders. dist and node_modules go the a folder in /opt. The configuration files to folder in /etc/, the daemon to /etc/init.d and the executable bash script to start the application to /usr/bin. The README is treated as documentation and the logfiles are marked as ghost.
This is the spec file:
%define debug_package %{nil}
# Use other payload algorithm to fix the following error on SuSE: Failed dependencies: rpmlib(FileDigests) <= 4.6.0-1 is needed
%define _binary_filedigest_algorithm 1
# automatically generate requires and provides from package.json
%{?nodejs_find_provides_and_requires}
# filter out any false provides created due to dependencies with native components
%{?nodejs_default_filter}
# name of zip file containing source without .zip extension
%define modname myApplication
Summary: The %{modname} is a nodeJs project
Name: %{modname}
Group: Applications/Server
Version: 0.1
Release: 1
License: None
URL: https://private.git/myApplication
Source0: myApplication.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: x86_64
ExclusiveArch: x86_64
BuildRequires: npm
Requires: nodejs10
AutoReq: no
AutoProv: no
%description
%{Summary}
#Unpack the tar.gz file
%prep
%setup -q -n myApplication
%build
#Code is already build
%install
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT/etc/myApplication
%{__cp} -r $RPM_BUILD_DIR/myApplication/.env* $RPM_BUILD_ROOT/etc/myApplication
mkdir -p $RPM_BUILD_ROOT/opt/myApplication/dist
%{__cp} -r $RPM_BUILD_DIR/myApplication/dist $RPM_BUILD_ROOT/opt/myApplication/
mkdir -p $RPM_BUILD_ROOT/opt/myApplication/node_modules
%{__cp} -r $RPM_BUILD_DIR/myApplication/node_modules $RPM_BUILD_ROOT/opt/myApplication/
mkdir -p $RPM_BUILD_ROOT/usr/bin
%{__cp} -r $RPM_BUILD_DIR/myApplication/myApplication $RPM_BUILD_ROOT/usr/bin/myApplication
mkdir -p $RPM_BUILD_ROOT/etc/init.d/
%{__cp} -r $RPM_BUILD_DIR/myApplication/myDaemon $RPM_BUILD_ROOT/etc/init.d/myDaemon
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(0755, root, root)
%doc README.md
%dir /etc/myApplication
%config /etc/myApplication/.env
%config /etc/myApplication/.env.production
%config /etc/myApplication/.env.development
/etc/myApplication/.env.sample
/opt/myApplication
/usr/bin/myApplication
/etc/init.d/myDaemon
%ghost /var/log/myApplication.log
%ghost /var/log/myDaemon.log
%changelog
* Wed Sep 29 2021 seism0saurus
- Initial spec file for myApplication
The rpm build with -vv runs fine and lists all dependencies from node_modules. I can also open the rpm with a zip utility and can see all needed dependencies inside the /opt/myApplication/node_modules folder.
But only some of the dependencies in that node_modules folder are installed, when I run zypper install myApplication.rpm. For example dependency_b is missing but dependency_a was installed. I can check that with rpm -V -v --nodeps -p myApplication.rpm. The folders are marked as missing. Here is a part from the output:
.......T /opt/myApplication/node_modules/triple-beam/test.js
missing /opt/myApplication/node_modules/url-parse
missing /opt/myApplication/node_modules/url-parse/LICENSE
missing /opt/myApplication/node_modules/url-parse/README.md
missing /opt/myApplication/node_modules/url-parse/dist
missing /opt/myApplication/node_modules/url-parse/dist/url-parse.js
missing /opt/myApplication/node_modules/url-parse/dist/url-parse.min.js
missing /opt/myApplication/node_modules/url-parse/dist/url-parse.min.js.map
missing /opt/myApplication/node_modules/url-parse/index.js
missing /opt/myApplication/node_modules/url-parse/package.json
........ /opt/myApplication/node_modules/util-deprecate
I usually use Debian/GNU Linux and not SuSE, so I don't have any experience with rpm.
Can someone explain, why the folders and files are not installed, although rpm knows, that they should be installed and shows them as missing?
How can I fix that? Is something wrong with my spec or my approach to package a NodeJs application?
--- EDIT ---
The rpm package works fine inside my Leap 15 containers (rpm 4.14.3). The problems is only on a SLES 11 installation (rpm 4.4.2.3).
So the problems seems to be related with the old version of rpm.
--- EDIT 2 ---
I tweaked the spec by configuring the compression algorithm:
%define _source_payload w0.gzdio
%define _binary_payload w0.gzdio
Now i can install the package correctly with rpm but zypper has still the same problem.
Any thoughts on that?
Kind regards,
seism0saurus
The final solution was to use a different compression algorithm in the spec file and to give the package a new version number, so that zypper doesn't use the old version from cache.
%define _source_payload w0.gzdio
%define _binary_payload w0.gzdio
I have built a package from https://github.com/fd00/yacp using cygport; however I just noticed that cygport [packagename.cygport] install command does NOT install in the cygwin filesystem, but in a subdirectory of the source build directory; as such, executables are not in the cygwin path, and you cannot call them by name.
I have seen:
http://cygwin.1069669.n5.nabble.com/Manual-installation-of-cygport-packages-td132812.html
So for most cases, it works just fine just to unpack the archive into the
root file system in order to test it.
https://cygwin-ports-general.narkive.com/RrfmRgr6/how-to-install-a-package-build-with-cygport
you could install yourself or by descending to the build directory and doing 'make
install' or simply run it from the build directory :-)
So, now I have packagename.tar.xz and packaganame.hint - can't I use these with the Cygwin setup-x86_64.exe program (so that I'd have a marked entry, when I look up the package name in setup)?
If I "install" by just unpacking packagename.tar.xz into the Cygwin root filesystem, how do I "uninstall" then?
Does cygport change installation paths in respect to make install of the package? If not, then I guess make install is an option, because then I should have make uninstall too ...
cygport is the tool to build packages that can be installed with Cygwin setup-$ARCH.exe installation.
You can create a local setup structure, and use the calm package to create
the needed setup.ini file.
$ cygcheck -f /usr/bin/mksetupini
calm-20200220-1
Create a website directory similar to the cache you have from downloading, make a ARCH/release directory and copy the content of dist for the packages you are interested.
I am using a script like this to prepare the directory for setup
#!/bin/bash
cd /pub/altervista/
rm x86/setup.ini x86_64/setup.ini
for i in x86 x86_64
do
mksetupini --arch ${i} --inifile=${i}/setup.ini --releasearea=. --disable-check=missing-required-package,missing-depended-package
bzip2 <${i}/setup.ini >${i}/setup.bz2
xz -6e <${i}/setup.ini >${i}/setup.xz
done
In this moment its structure is like this:
$ cd http%3a%2f%2fmatzeri.altervista.org%2f
$ find x86_64/ -type f
x86_64/release/perl-Cairo/perl-Cairo-1.107-1-src.tar.xz
x86_64/release/perl-Cairo/perl-Cairo-1.107-1.hint
x86_64/release/perl-Cairo/perl-Cairo-1.107-1.tar.xz
x86_64/release/perl-Cairo/perl-Cairo-debuginfo/perl-Cairo-debuginfo-1.107-1.hint
x86_64/release/perl-Cairo/perl-Cairo-debuginfo/perl-Cairo-debuginfo-1.107-1.tar.xz
x86_64/release/perl-Glib/perl-Glib-1.3292-1-src.tar.xz
x86_64/release/perl-Glib/perl-Glib-1.3292-1.hint
x86_64/release/perl-Glib/perl-Glib-1.3292-1.tar.xz
x86_64/release/perl-Glib/perl-Glib-debuginfo
x86_64/release/perl-Glib/perl-Glib-debuginfo/perl-Glib-debuginfo-1.3292-1.hint
x86_64/release/perl-Glib/perl-Glib-debuginfo/perl-Glib-debuginfo-1.3292-1.tar.xz
x86_64/setup.bz2
x86_64/setup.ini
x86_64/setup.xz
than you can just install from that Website local directory. A fake Website works fine.
Ok, found and followed the instructions here: https://cygwin.com/package-server.html
First install calm via Cygwin's setup.exe (for me, setup-x86_64.exe):
Install calm 20200220-1
Install python36-setuptools 41.2.0-1 (automatically added)
Then, I have:
$ which mksetupini
/usr/bin/mksetupini
Note, I have already: /cygdrive/d/Downloads/cygwin_packages/http%3a%2f%2fcygwin.mirror.constant.com%2f/x86_64 where Cygwin stores downloaded packages; that directory has release subdir and setup.ini file.
So, now I can create a directory for my custom packages:
$ mkdir /cygdrive/d/Downloads/cygwin_packages/cygwin-custom
$ mkdir -p /cygdrive/d/Downloads/cygwin_packages/cygwin-custom/x86_64/release
Note that in my source build folder, I have a dist subfolder, which contains the packaging:
$ ls -la [packagename]-[version]-1bl1.x86_64/dist/[packagename]/
total 2557
drwxr-xr-x 1 user None 0 Mar 21 18:26 .
drwxr-xr-x 1 user None 0 Mar 21 18:26 ..
-rw-r--r-- 1 user None 373 Mar 21 18:26 [packagename]-[version]-1bl1.hint
-rw-r--r-- 1 user None 177772 Mar 21 18:26 [packagename]-[version]-1bl1.tar.xz
-rw-r--r-- 1 user None 2430900 Mar 21 18:26 [packagename]-[version]-1bl1-src.tar.xz
drwxr-xr-x 1 user None 0 Mar 21 18:26 [packagename]-debuginfo
drwxr-xr-x 1 user None 0 Mar 21 18:26 lib[packagename]0
drwxr-xr-x 1 user None 0 Mar 21 18:26 lib[packagename]-devel
I can just copy this to the arch/release child dir of cygwin-custom, and then change directory to cygwin-custom:
$ cp -a [packagename]-[version]-1bl1.x86_64/dist/[packagename] /cygdrive/d/Downloads/cygwin_packages/cygwin-custom/x86_64/release/
$ pushd /cygdrive/d/Downloads/cygwin_packages/cygwin-custom
Now, note that if I just call mksetupini as in the above webpage, it will fail:
$ mksetupini --arch x86_64 --inifile=x86_64/setup.ini --releasearea=.
mksetupini: package '[packagename]' version '[version]-1bl1' requires nonexistent or errored package 'cygwin'
mksetupini: package '[packagename]' version '[version]-1bl1' requires nonexistent or errored package 'libgcc1'
mksetupini: package '[packagename]' version '[version]-1bl1' requires nonexistent or errored package 'libreadline7'
...
... and the file setup.ini does not get created!
Then I thought I should symlink as in the above webpage:
$ for ARCH in x86_64 noarch ; do
mkdir -p ${ARCH}/release
cd ${ARCH}/release
ln -s /cygdrive/d/Downloads/cygwin_packages/http%3a%2f%2fcygwin.mirror.constant.com%2f/${ARCH}/release/* .
cd ../..
done
$ mksetupini --arch x86_64 --inifile=x86_64/setup.ini --releasearea=.
mksetupini: no .hint files in ./noarch/release/adwaita-icon-theme but has files: adwaita-icon-theme-3.26.1-1.tar.xz
mksetupini: no .hint files in ./noarch/release/base-cygwin but has files: base-cygwin-3.8-1.tar.xz
mksetupini: no .hint files in ./noarch/release/base-files but has files: base-files-4.3-2.tar.xz
...
mksetupini: package '[packagename]' version '[version]-1bl1' requires nonexistent or errored package 'cygwin'
mksetupini: package '[packagename]' version '[version]-1bl1' requires nonexistent or errored package 'libgcc1'
mksetupini: package '[packagename]' version '[version]-1bl1' requires nonexistent or errored package 'libreadline7'
mksetupini: package '[packagename]' version '[version]-1bl1' depends nonexistent or errored package 'cygwin'
...
... and this does not create setup.ini either.
Finally I found https://github.com/cascent/neovim-cygwin/issues/7 that mentioned the switch --okmissing required-package - so, finally this command:
$ mksetupini --arch x86_64 --inifile=x86_64/setup.ini --releasearea=. --okmissing required-package
... will finally create setup.ini - which will only contain our custom built packages, as they are the only ones that have a .hint file ( I don't have any .hint files in the http%3a%2f%2fcygwin.mirror.constant.com%2f directory, where cygwin usually downloads packages ):
$ cat x86_64/setup.ini
# This file was automatically generated at 2020-03-21 19:42:00 CET.
#
# If you edit it, your edits will be discarded next time the file is
# generated.
#
# See https://sourceware.org/cygwin-apps/setup.ini.html for a description
# of the format.
release: cygwin
arch: x86_64
setup-timestamp: 1584816120
# [packagename]
sdesc: "Blah blah ..."
...
Now, start Cygwin setup.exe, and when the choice screen is: "Cygwin Setup - Choose Installation Type"; here switch from "Install from Internet (...)" to "Install from Local Directory"; on Next > keep Root directory the same; on Next > Select Local Package Directory: I chose D:\Downloads\cygwin_packages\cygwin-custom - on Next > : Select Packages: View Full, then [packagename] is listed there ... and can be installed - and dependencies are resolved, too:
Install [packagename] [version]-1bl1
Install lib[packagename]0 [version]-1bl1 (automatically added)
And finally, after installation, I can call [packagename].exe by name directly in the Cygwin bash shell!
Not too bad of a process, but can get a bit involved if you cannot find the right documentation ...
I am writing an r package which provides a wrapper around the libSBML C library.
I am using the rcppgsl package as a reference, which looks for the location of header files and the library files for GNU Scientific Library GSL and uses that information to write the configure script and Makevars and Makevars.in. I am not building for Windows currently. On my machine (macOS), libsbml (SBML C library) is installed in usual locations, i.e.
header files are at - /usr/local/include/sbml
and library files at - /usr/local/lib. Indeed, if in my package Makevars file I use the following, I can build my package.
CXX=clang++
PKG_CPPFLAGS= -I/usr/local/include
PKG_LIBS= $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS) /usr/local/lib/libsbml-static.a
However, I want to learn how to use the configure script to find the library and use that information to build the package. The relevant portion of configure.ac from rcppgsl is
## Check for non-standard programs: gsl-config(1)
AC_PATH_PROG([GSL_CONFIG], [gsl-config])
## If gsl-config was found, let's use it
if test "${GSL_CONFIG}" != ""; then
# Use gsl-config for header and linker arguments
GSL_CFLAGS=`${GSL_CONFIG} --cflags`
GSL_LIBS=`${GSL_CONFIG} --libs`
else
AC_MSG_ERROR([gsl-config not found, is GSL installed?])
fi
I replaced GSL_CONFIG with LIB_SBML at relevant places, i.e., the entire configure.ac file I am using is pasted below (at the end).
However, I don't see configure, Makevars and Makevars.in being generated (which I see in rcppgsl). Any help here would be highly appreciated!
For the sake of completion, the output of
ls -l | grep sbml (in usr/local/include) is
drwxrwxr-x 58 root admin 1856 Aug 1 2016 sbml
and ls -l | grep sbml (in usr/local/lib) is
-rw-r--r-- 1 root wheel 7970584 Aug 2 2016 libsbml-static.a
-rwxr-xr-x 1 arcadmin staff 10453624 Nov 25 2014 libsbml.5.11.0.dylib
-rwxr-xr-x 1 root wheel 3813572 Aug 2 2016 libsbml.5.13.0.dylib
lrwxr-xr-x 1 root wheel 20 Aug 1 2016 libsbml.5.dylib -> libsbml.5.13.0.dylib
-rw-r--r-- 1 root wheel 13907656 Feb 26 2015 libsbml.a
lrwxr-xr-x 1 arcadmin staff 15 Mar 27 2015 libsbml.dylib -> libsbml.5.dylib
-rwxr-xr-x 1 root wheel 828 Feb 26 2015 libsbml.la
-rwxrwxr-x 1 root admin 13362732 Nov 25 2014 libsbmlj.jnilib
My configure.ac file --
## Process this file with autoconf to produce a configure script.
##
## Configure.ac for RcppSBML
##
## Copyright (C) 2010 Romain Francois and Dirk Eddelbuettel
## Copyright (C) 2014 - 2015 Dirk Eddelbuettel
##
## Licensed under GNU GPL 2 or later
# The version set here will propagate to other files from here
AC_INIT([Rcppsbml], 0.1.0)
# Checks for common programs using default macros
AC_PROG_CC
## Use gsl-config to find arguments for compiler and linker flags
##
## Check for non-standard programs: gsl-config(1)
AC_PATH_PROG([LIB_SBML], [libsbml])
## If gsl-config was found, let's use it
if test "${LIB_SBML}" != ""; then
# Use gsl-config for header and linker arguments
SBML_CFLAGS=`${LIB_SBML} --cflags`
SBML_LIBS=`${LIB_SBML} --libs`
else
AC_MSG_ERROR([libsbml not found, is SBML installed?])
fi
# Now substitute these variables in src/Makevars.in to create src/Makevars
AC_SUBST(LIB_SBML)
AC_SUBST(LIB_SBML)
AC_OUTPUT(src/Makevars)
Here a minimal setup:
Remove src/Makevars and create src/Makevars.in with content
PKG_CPPFLAGS= #SBML_INCLUDE#
PKG_LIBS= $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS) #SBML_LIBS#
I am not setting CXX since you cannot change that in src/Makevars, c.f. Package build ignores Makevars flags.
Create a minimal configure.ac file:
AC_INIT([Rcppsbml], 0.1.0)
AC_LANG(C++)
AC_REQUIRE_CPP
AC_PROG_CXX
# default values
AC_SUBST([SMBL_INCLUDE], "-I/usr/local/include")
AC_SUBST([SMBL_LIBS], "/usr/local/lib/libsbml-static.a")
# allow for override
AC_ARG_WITH([smbl],
AC_HELP_STRING([--with-smbl=PREFIX],
[path to where smbl is installed]),
[
SMBL_INCLUDE="-I${with_smbl}/include"
SMBL_LIBS="${with_smbl}/lib/libsbml-static.a"
],
[])
# create and report output
AC_CONFIG_FILES([src/Makevars])
AC_OUTPUT
echo
echo "Final src/Makevars"
cat src/Makevars
Call autoconf to create a configure file from your configure.ac template. You might want to check the script with ./configure and ./configure --with-smbl=/some/path.
Call
R CMD build ...
R CMD check [--install-args=--configure-args=--with-smbl=/some/path] ...
R CMD INSTALL [--configure-args=--with-smbl=/some/path]...
to build, check and install the package.
Possible extensions:
Allow for switching between static and dynamic linking.
Check that SMBL can be found in a usable state at the specified location.
I see three issues here:
The generation of configure from configure.ac is not automatic. You have to call autoconf.
Similarly, Makevars.in is not generated by the system. You have to provide it as template from which Makevars is generated by configure.
The GSL ships with gsl-config, other libraries make use of the general pkg-config. If your library does not support this, you can use the more traditional way to use default locations or those provided with --with-... arguments. For example in RcppArrayFire I use:
AC_SUBST([AF_INCLUDE], "")
AC_SUBST([AF_LIBS], "-laf")
AS_IF([test -e "${with_arrayfire}"],
[
AF_INCLUDE="-I${with_arrayfire}/include ${AF_INCLUDE}"
AF_LIBS="-L${with_arrayfire}/lib ${AF_LIBS} -Wl,-rpath,${with_arrayfire}/lib"
])
If a directory is supplied as --with-arrayfire=/relevant/path, then appropriate sub directories are searched for headers and dynamic libraries.
I'm following these instructions. I successfully did stack new and stack setup but stack build fails.
I found a git issue that this may be due to extra files listed in the cabal file, but removing them didn't fix the issue (and I'm just using the new-template without any changes). I am on Ubuntu 14.04 and installed stack using the script. Is there anything else I can look into?
It appears that this might be due to me trying to build inside of a cifs directory. Is there anything I can do to handle this?
# stack build
ehri-haskell-0.1.0.0: configure (lib + exe)
Configuring ehri-haskell-0.1.0.0...
ehri-haskell-0.1.0.0: build (lib + exe)
Preprocessing library ehri-haskell-0.1.0.0...
Preprocessing executable 'ehri-haskell-exe' for ehri-haskell-0.1.0.0...
ehri-haskell-0.1.0.0: copy/register
Installing library in
/mnt/docs/RubymineProjects/ehri-haskell/.stack-work/install/x86_64-linux/lts-8.6/8.0.2/lib/x86_64-linux-ghc-8.0.2/ehri-haskell-0.1.0.0-Kh3VLZPfbij7EgcL22QBMN
Installing executable(s) in
/mnt/docs/RubymineProjects/ehri-haskell/.stack-work/install/x86_64-linux/lts-8.6/8.0.2/bin
/mnt/docs/RubymineProjects/ehri-haskell/.stack-work/install/x86_64-linux/lts-8.6/8.0.2/bin/.copyFile5965166491189641421.tmp:
copyFile: does not exist (Host is down)
'cabal copy' failed. Error message:
-- While building package ehri-haskell-0.1.0.0 using:
/root/.stack/setup-exe-cache/x86_64-linux/Cabal-simple_mPHDZzAJ_1.24.2.0_ghc-8.0.2 --builddir=.stack-work/dist/x86_64-linux/Cabal-1.24.2.0 copy
Process exited with code: ExitFailure 1
One possible cause of this issue is:
* No module named "Main". The 'main-is' source file should usually have a header indicating that it's a 'Main' module.
# stack --version
Version 1.4.0, Git revision e714f1dd3fade19496d91bd6a017e435a96a6bcd (4640 commits) x86_64 hpack-0.17.0
Looks like the issue is caused by the depth of the folder where the project lives (Windows 10, x64). From the moment the depth exceeds some threshold, described error appears. So try moving the project folder up in directories tree.
[root#localhost local]# ll
lrwxrwxrwx. 1 root root 11 Sep 12 21:34 hbase -> hbase-1.1.2
drwxr-xr-x. 30 root root 4096 Sep 12 21:34 hbase-1.1.2
[root#localhost local]# ./hbase/bin/start-hbase.sh
Error: Could not find or load main class。 org.apache.hadoop.hbase.util.HBaseConfTool
Error: Could not find or load main class org.apache.hadoop.hbase.zookeeper.ZKServerTool
starting master, logging to /usr/local/hbase/logs/hbase-root-master-localhost.out
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=128m; support was removed in 8.0
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=128m; support was removed in 8.0
Error: Could not find or load main class org.apache.hadoop.hbase.master.HMaster
starting regionserver, logging to /usr/local/hbase/logs/hbase-root-1-regionserver-localhost.out
Error: Could not find or load main class org.apache.hadoop.hbase.regionserver.HRegionServer
Why does it show this error? The class file exists.
[root#localhost local]# find ./ -name HBaseConfTool.class
./hbase-1.1.2/hbase-server/target/classes/org/apache/hadoop/hbase/util/HBaseConfTool.class
The /etc/profile:
export JAVA_HOME=/usr/local/jdk1.8.0_20
export HBASE_HOME=/usr/local/hbase
export PATH=$JAVA_HOME/bin:$HBASE_HOME/bin:$PATH
export CLASSPATH=.:$JAVA_HOME/lib:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar:$HBASE_HOME/hbase-server/target/classes
I add $HBASE_HOME/hbase-server/target/classes, but it still does not find the class file。
I am just a newer，getting start follow official docs, but can not run。I am so eggache... sos...
thanks for you asking my quesiton。
I get the src version, and I use "mvn package -Dmaven.test.skip.exec=true -Dtar -e" compile，I hope it makes hbasexx-bin.tar.gz，but get nothing。
Complie hadoop src use 'mvn package -Pdist,native,docs -DskipTests -Dtar' ，then the xx.tar.gz can be found in hadoop-dist/target/ 。
Maybe my hbase compile command is wrong? I copy it from others。what is the right complie commad ？ I am not familiar with mvn params 。。。
/usr/local/hbase-1.1.2/bin/hbase --config conf classpath
I find that many main module path is the old compile path,
/root/hbase-1.1.2/hbase-it/target/hbase-it-1.1.2-tests.jar:/root/hbase-1.1.2/hbase-common/target/hbase-common-1.1.2.jar:/root/hbase-1.1.2/hbase-protocol/target/hbase-protocol-1.1.2.jar:/root/hbase-1.1.2/hbase-client/target/hbase-client-1.1.2.jar:
Oh my god,but how to complie in path /root compile /root/hbase-1.1.2 ,then I mv to /usr/local ? or how to modify classpath when I use in path /usr/local/hbase-1.1.2 ?
Maybe you are using source package.
Try binary package (http://apache.mirror.cdnetworks.com/hbase/1.1.2/hbase-1.1.2-bin.tar.gz) or build it first.
not "hbase-1.1.2-src.tar.gz"
but "hbase-1.1.2-bin.tar.gz"