makepkg is creating a /usr/lib64 why?[SOLVED]

lordnaikon · 2015-03-22 19:50:07

Hi there,

i'm trying to use vmime (http://www.vmime.org/) for a project. after seeking through the AUR there is no package available that builds out of the box. So i tried to make my own.
I am using the src from github (https://github.com/kisli/vmime) which build just fine. But after the simple step to wrap it in an arch package i get an issue i can't find documentation about. after the package() step i have a folder /usr/lib64 where the lib is copied. Obviously i cant use that to install cuz pacman don't let me install files under /usr/lib64 but i cant'f find the step where this folder is created in the first place.

i tried -DCMAKE_INSTALL_LIBDIR=/usr/lib without any success. I can't really belief this has something to do with cmake cuz if i am building this "standalone" i get a simple "lib" folder. But using makepgk suddenly i have an lib64 folder inside my pgk.

what is causing the creation of the /usr/lib64 folder?

Here is my script so far:

pkgname=libvmime-git
pkgver=0.9.2
pkgrel=1
pkgdesc="A powerful C++ class library for working with RFC-822 and MIME messages."
arch=("i686" "x86_64")
url="http://www.vmime.org/"
license=("GPL3")
depends=("gsasl" "gnutls")
makedepends=("cmake")
conflicts=("libvmime" "libvmime-svn" "zarafa-libvmime")
optdepends=("sendmail: sendmail protocol support")

build() {
  git clone git://github.com/kisli/vmime.git ${pkgname}
  cd ${srcdir}/${pkgname}
  cmake -DVMIME_HAVE_MESSAGING_PROTO_SENDMAIL:BOOL=OFF \
        -DCMAKE_INSTALL_PREFIX:PATH=/usr \
	-DVMIME_SHARED_PTR_USE_CXX=ON \
	-DVMIME_SHARED_PTR_USE_BOOST=OFF
  make
}

package() {
  cd ${srcdir}/${pkgname}
  make DESTDIR="${pkgdir}" install
}

Last edited by lordnaikon (2015-03-23 08:52:34)

Trilby · 2015-03-22 20:25:43

Please see the guidelines on vcs PKGBUILDs - this was a real pain to work with until I fixed the git clone parts:

_gitname=vmime
pkgname="lib${_gitname}-git"
pkgver=0.9.2
pkgrel=1
pkgdesc="A powerful C++ class library for working with RFC-822 and MIME messages."
arch=("i686" "x86_64")
url="http://www.vmime.org/"
license=("GPL3")
depends=("gsasl" "gtk3" "icu")
makedepends=("cmake")
conflicts=("libvmime" "libvmime-svn" "zarafa-libvmime")
optdepends=("sendmail: sendmail protocol support")
source=("${_gitname}::git://github.com/kisli/vmime.git")
sha256sums=('SKIP')

build() {
  cd ${srcdir}/${_gitname}
  cmake -DVMIME_HAVE_MESSAGING_PROTO_SENDMAIL:BOOL=OFF \
        -DCMAKE_INSTALL_PREFIX:PATH=/usr \
		  -DCMAKE_LIBRARY_OUTPUT_DIRECTORY:PATH=/lib \
	-DVMIME_SHARED_PTR_USE_CXX=ON \
	-DVMIME_SHARED_PTR_USE_BOOST=OFF
  make
}

package() {
  cd ${srcdir}/${_gitname}
  make DESTDIR="${pkgdir}" install
}

Notice that I also added the LIBRARY_OUTPUT_DIRECTORY which I think is what is needed. I don't use cmake, though, so I'm still testing this - it's building as we speak, but it takes a while. I also added gtk3 and icu as a dependencies as they are also required.

When you build this "standalone" do you also install it? The lib64 path is in the installation directives, not the build directives. The cmake-generated Makefile creates /lib64.

EDIT: this doesn't seem to fix it. I'll leave this to those who are familiar with CMAKE, but that is the source of this.

karol · 2015-03-22 20:39:29

This is sometimes fixed with

sed 's/lib64/lib/g' -i <somefile>

but I have no idea if it applies to this case too.

lordnaikon · 2015-03-22 20:49:58

Trilby wrote:

Please see the guidelines on vcs PKGBUILDs - this was a real pain to work with until I fixed the git clone parts

Yes i am aware of that, it is in the "construction" state, sry for the inconvenience. I'll try to come up with a better one next time ..

Trilby wrote:

Notice that I also added the LIBRARY_OUTPUT_DIRECTORY which I think is what is needed.

Ah yes! Thats the right option i guess and not my MAKE_INSTALL_LIBDIR now that i think about it ...

Trilby wrote:

I don't use cmake, though, so I'm still testing this - it's building as we speak, but it takes a while. I also added gtk3 as a dependency as that is also required.

Really? Thanks for pointing this out, this seems to be odd ...

Trilby wrote:

When you build this "standalone" do you also install it? The lib64 path is in the installation directives, not the build directives. The cmake-generated Makefile creates /lib64.

NO! I don't want to ruin my system ... i just looked at the CMakeList and the Makefile but can't find anything about lib64

... ok after writing this text its done with the building process but i still get a /usr/lib64 folder even with your LIBRARY_OUTPUT_DIRECTORY ? Whats your build saying?

Last edited by lordnaikon (2015-03-22 20:50:49)

lordnaikon · 2015-03-22 20:54:09

karol wrote:

This is sometimes fixed with
sed 's/lib64/lib/g' -i <somefile>
but I have no idea if it applies to this case too.

Thanks for the hint, i'll try that and report. This is strange, cmake isn't that uncommon but to be honest i only use this for "play projects" that i never install. I'll guess the wiki needs some love about this topic ...

Trilby · 2015-03-22 21:08:31

I'm not sure if our wiki needs documenation on build systems - the build systems should have their own documentation out there, I've just never taken the time to learn cmake as I never use it.

As for Karol's suggestion, cmake/FindICU.cmake is the only file to actually specify lib64 before the build process. I'm retrying the build with that sed replacement.

lordnaikon · 2015-03-22 21:19:35

"I'm not sure if our wiki needs documenation on build systems"

Yes you're right about that, thats just a messed up cmake i just wondered where this is coming from in the first place ... the doku of vmime says nothing about that, the other cmake options to enable c++11 smart pointer instead of boost pointer i had to dig out of the cmake .. the only options that are mentioned in the doku are "if you wanna build with openssl or gnutls ... "

i grep a bit around and after the build i found a vmime.pc file with "libdir=/usr/lib64" but thats generated by cmake so i looked a bit closer to the CMakeList and found

# Automatically set lib suffix
IF(UNIX AND NOT APPLE AND NOT CMAKE_CROSSCOMPILING AND NOT EXISTS "/etc/debian_version")
	IF(CMAKE_SIZEOF_VOID_P EQUAL 8 AND NOT LIB_SUFFIX)
		# ...only if LIB_SUFFIX is not defined...
		IF(NOT DEFINED LIB_SUFFIX)
			# ...and if CMAKE_INSTALL_LIBDIR does not already contain the suffix
			IF(NOT "${CMAKE_INSTALL_LIBDIR}" MATCHES ".*64.*")
				SET(LIB_SUFFIX 64)
			ENDIF()
		ENDIF()
	ENDIF()
ENDIF()

# Determine library installation dir, in this order:
#   1) use VMIME_INSTALL_LIBDIR if set
#   2) use LIB_INSTALL_DIR if defined
#   3) use CMAKE_INSTALL_LIBDIR if set
#      if it is a relative path, prepend CMAKE_INSTALL_PREFIX to it
#   4) use CMAKE_INSTALL_PREFIX/lib
IF(NOT DEFINED VMIME_INSTALL_LIBDIR)
	IF(DEFINED LIB_INSTALL_DIR)
		SET(VMIME_INSTALL_LIBDIR ${LIB_INSTALL_DIR})
	# respect CMAKE_INSTALL_LIBDIR if set
	ELSEIF(DEFINED CMAKE_INSTALL_LIBDIR)
		SET(VMIME_INSTALL_LIBDIR ${CMAKE_INSTALL_LIBDIR})
		IF(IS_ABSOLUTE ${VMIME_INSTALL_LIBDIR})
			SET(VMIME_INSTALL_LIBDIR ${CMAKE_INSTALL_LIBDIR}${LIB_SUFFIX})
		ELSE()
			SET(VMIME_INSTALL_LIBDIR ${CMAKE_INSTALL_PREFIX}/${CMAKE_INSTALL_LIBDIR}${LIB_SUFFIX})
		ENDIF()
	ELSE()
		SET(VMIME_INSTALL_LIBDIR ${CMAKE_INSTALL_PREFIX}/lib${LIB_SUFFIX})
	ENDIF()
ENDIF()

GRRR *:( So i'll try VMIME_INSTALL_LIBDIR instead of my first MAKE_INSTALL_LIBDIR

EDIT://

Trilby wrote:

As for Karol's suggestion, cmake/FindICU.cmake is the only file to actually specify lib64 before the build process. I'm retrying the build with that sed replacement.

i guess that needs to stay, it just searches for needed libs

Last edited by lordnaikon (2015-03-22 21:34:21)

lordnaikon · 2015-03-22 21:42:37

ok now it builds and i can install it with pacman. I also linked it to a project without any errors.. my "final" PKGBUILD for today looks like this:

_gitname=vmime
pkgname="lib${_gitname}-git"
pkgver=0.9.2
pkgrel=1
pkgdesc="A powerful C++ class library for working with RFC-822 and MIME messages."
arch=("i686" "x86_64")
url="http://www.vmime.org/"
license=("GPL3")
depends=("gsasl" "gnutls" "gtk3")
makedepends=("cmake")
conflicts=("libvmime" "libvmime-svn" "zarafa-libvmime")
optdepends=("sendmail: sendmail protocol support")
source=("${_gitname}::git://github.com/kisli/vmime.git")
sha256sums=('SKIP')

build() {
  cd ${srcdir}/${_gitname}

  cmake -DVMIME_HAVE_MESSAGING_PROTO_SENDMAIL:BOOL=OFF \
        -DCMAKE_INSTALL_PREFIX:PATH=/usr \
	-DVMIME_INSTALL_LIBDIR=/usr/lib \
	-DVMIME_SHARED_PTR_USE_CXX=ON \
	-DVMIME_SHARED_PTR_USE_BOOST=OFF
  make
}

package() {
  cd ${srcdir}/${_gitname}
  make DESTDIR="${pkgdir}" install
}

ill guess icu is also needed as a dependency but after that should i make this available to AUR? I've never done this before ..

Last edited by lordnaikon (2015-03-22 21:43:44)

WorMzy · 2015-03-22 21:52:43

If you're planning on submitting it to the AUR, please also enclose any instance of $srcdir or $pkgdir in double-quotes. e.g.

cd "${srcdir}/${_gitname}"

That'll prevent any breakage caused by someone building in a directory path with spaces (e.g. "/home/use/my builds/vmime").

Use namcap to identify packages that should be included as dependencies.

lordnaikon · 2015-03-22 22:16:42

@WorMzy: thanks! Whats the implications on submitting to the AUR? I think i need to read more about that here https://wiki.archlinux.org/index.php/Ar … Repository ? and namcap is great, thanks!

libvmime-git E: Dependency icu detected and not included (libraries ['usr/lib/libicuuc.so.54'] needed in files ['usr/lib/libvmime.so.0.0.0'])
libvmime-git W: Dependency gnutls included but already satisfied
libvmime-git W: Dependency included and not needed ('gtk3')

so as i guessed i need icu. interesting that gnutls is not needed, after checking gsasl (the only one left) its plausible cuz gsasl needs gnutls, great!

EDIT:// i found this package to be orphaned https://aur.archlinux.org/packages/libvmime-git/ should i adopt it?

Last edited by lordnaikon (2015-03-22 22:19:08)

Trilby · 2015-03-22 22:24:29

Namcap is very handy, but can get some things wrong. It says gtk3 is not needed, but unless there is an option to pass to cmake, cmake will error out if it doesn't find gtk3 (at least it did for me).

As for adoption, yes, adopt and update that one.

lordnaikon · 2015-03-22 22:35:59

Trilby wrote:

Namcap is very handy, but can get some things wrong. It says gtk3 is not needed, but unless there is an option to pass to cmake, cmake will error out if it doesn't find gtk3 (at least it did for me).

is there an easy way to check that besides to make a "clean" install to a vm?

Trilby wrote:

As for adoption, yes, adopt and update that one.

ok, i will do that. I'll leave gtk3 as dependency in there as long as i checked that on a clean install. So my final pkgbuild looks like this:

# Maintainer: Dustin Bensing <dustin dot bensing at googlemail dot com>
# Contributor: Kristjan Reinloo <mail at kreinloo dot net>
_gitname=vmime
pkgname="lib${_gitname}-git"
pkgver=r1023.23fc354
pkgrel=1
pkgdesc="A powerful C++ class library for working with RFC-822 and MIME messages."
arch=("i686" "x86_64")
url="http://www.vmime.org/"
license=("GPL3")
depends=("gsasl" "icu" "gtk3")
makedepends=("cmake")
conflicts=("libvmime" "libvmime-svn" "zarafa-libvmime")
optdepends=("sendmail: sendmail protocol support")
source=("${_gitname}::git://github.com/kisli/vmime.git")
sha256sums=('SKIP')

pkgver() {
  cd "${srcdir}/${_gitname}"
  printf "r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
}

build() {
  cd "${srcdir}/${_gitname}"

  cmake -DVMIME_HAVE_MESSAGING_PROTO_SENDMAIL:BOOL=OFF \
        -DCMAKE_INSTALL_PREFIX:PATH=/usr \
	-DVMIME_INSTALL_LIBDIR=/usr/lib \
	-DVMIME_SHARED_PTR_USE_CXX=ON \
	-DVMIME_SHARED_PTR_USE_BOOST=OFF
  make
}

package() {
  cd "${srcdir}/${_gitname}"
  make DESTDIR="${pkgdir}" install
}

I did not really understand the purpose of "pkgrel" and if it applies to packages build from git ...

EDIT:// changed the pkgver ..

Last edited by lordnaikon (2015-03-22 23:37:53)

WorMzy · 2015-03-23 00:18:53

Hmm, you should also add git to the makedepends array, since it's needed to clone the source code.

is there an easy way to check that besides to make a "clean" install to a vm?

A clean-chroot.

I've just built it in one, and it appears that gtk3 is still needed to build, but is still identified as an unneeded dependency by namcap. Looking at the error, it appears that it fails building an example "viewer" program, which suggests to me that gtk3 is only needed if you want to build the samples.

If you want to continue building the samples (they're not installed, but may be useful to check that the library built correctly), change gtk3 to a makedepends. Otherwise, pass -DVMIME_BUILD_SAMPLES=OFF to cmake to disable the samples and remove the gtk3 dependency altogether.

Please remember to mark your thread as [SOLVED].

lordnaikon · 2015-03-23 08:56:13

@WorMzy: thanks for the suggestions. I think i'll go with the -DVMIME_BUILD_SAMPLES=OFF approach looks like the cleanest one. And thanks for your effort! But i'll try the clean-chroot anyway just for my personal education Thanks @ all for helping me!

Last edited by lordnaikon (2015-03-23 08:57:09)

Arch Linux

#1 2015-03-22 19:50:07

makepkg is creating a /usr/lib64 why?[SOLVED]

#2 2015-03-22 20:25:43

Re: makepkg is creating a /usr/lib64 why?[SOLVED]

#3 2015-03-22 20:39:29

Re: makepkg is creating a /usr/lib64 why?[SOLVED]

#4 2015-03-22 20:49:58

Re: makepkg is creating a /usr/lib64 why?[SOLVED]

#5 2015-03-22 20:54:09

Re: makepkg is creating a /usr/lib64 why?[SOLVED]

#6 2015-03-22 21:08:31

Re: makepkg is creating a /usr/lib64 why?[SOLVED]

#7 2015-03-22 21:19:35

Re: makepkg is creating a /usr/lib64 why?[SOLVED]

#8 2015-03-22 21:42:37

Re: makepkg is creating a /usr/lib64 why?[SOLVED]

#9 2015-03-22 21:52:43

Re: makepkg is creating a /usr/lib64 why?[SOLVED]

#10 2015-03-22 22:16:42

Re: makepkg is creating a /usr/lib64 why?[SOLVED]

#11 2015-03-22 22:24:29

Re: makepkg is creating a /usr/lib64 why?[SOLVED]

#12 2015-03-22 22:35:59

Re: makepkg is creating a /usr/lib64 why?[SOLVED]

#13 2015-03-23 00:18:53

Re: makepkg is creating a /usr/lib64 why?[SOLVED]

#14 2015-03-23 08:56:13

Re: makepkg is creating a /usr/lib64 why?[SOLVED]

Board footer