[SOLVED] Cannot build extra/timidity++ in clean chroot

quequotion · 2017-03-25 12:26:24

Is there a proper place in the forums to ask about packages in [extra], or is it considered one of the "official" repositories?

Anyway, I am trying to debug a problem with timidity++ but the package cannot be built. I am curious how it is available from the extra repository, as I cannot get it to build even in a clean chroot.

It always fails with:

dl_hpux.c:30:16: fatal error: dl.h: No such file or directory
 #include <dl.h>

My best guess is that it wants to configure an output for HP-UX, but it doesn't make sense that it should do that. The PKGBUILD's ./configure section does not include hpux among the enabled audio outputs. Timidity's configure offers no method to disable specific audio outputs; they can only be whitelisted with --enable-audio=list or all disabled with --disable-audio.

EDIT: extra/timidity++, not community/

Last edited by quequotion (2017-03-25 15:25:41)

WorMzy · 2017-03-25 12:39:27

Builds fine in a clean chroot here. How is yours set up?

Mod note: moving to Creating and Modifying Packages.

Trilby · 2017-03-25 12:44:02

timidty++ is in [extra] not [community]. What package are you actually trying to build? timidity-freepats?

quequotion · 2017-03-25 12:47:17

WorMzy wrote:

Builds fine in a clean chroot here. How is yours set up?

According to the "Classic Way" as described in the wiki.

Mod note: moving to Creating and Modifying Packages.

Noted for future reference: Direct questions about extra/packages to this subforum.

Do you have a package providing that header file installed in your $CHROOT/root?

Last edited by quequotion (2017-03-25 12:49:39)

quequotion · 2017-03-25 12:48:17

Trilby wrote:

timidty++ is in [extra] not [community]. What package are you actually trying to build? timidity-freepats?

I meant the package in extra/, misread the terminal.

The only way I can get the package to build, either normally or in a clean chroot, is with this patch:

--- src/TiMidity++-2.14.0/configure	2012-06-28 23:14:25.000000000 +0900
+++ src/TiMidity++-2.14.0/configure	2017-03-25 21:00:43.621073161 +0900
@@ -16190,9 +16190,9 @@
 fi
 echo "$as_me:$LINENO: result: $ac_cv_func_shl_load" >&5
 echo "${ECHO_T}$ac_cv_func_shl_load" >&6
-if test $ac_cv_func_shl_load = yes; then
-  have_dl=hpux
-fi
+#if test $ac_cv_func_shl_load = yes; then
+#  have_dl=hpux
+#fi
 
   fi
   if test "$have_dl" = "no"; then
@@ -16286,9 +16286,9 @@
 fi
 echo "$as_me:$LINENO: result: $ac_cv_func_NSLinkModule" >&5
 echo "${ECHO_T}$ac_cv_func_NSLinkModule" >&6
-if test $ac_cv_func_NSLinkModule = yes; then
-  have_dl=dyld
-fi
+#if test $ac_cv_func_NSLinkModule = yes; then
+#  have_dl=dyld
+#fi
 
   fi
   if test "$have_dl" = "no" -a "x$ac_cv_lib_dl_dlopen" = xyes; then

After bypassing the check for "hpux", it fails again looking for "dyld".

Why would these checks pass if the headers are missing?

Last edited by quequotion (2017-03-25 12:54:35)

Trilby · 2017-03-25 12:59:26

timidity++ just built find in a chroot here too. Are you using the exact PKGBUILD and patches from the ABS, or have you made changes?

WorMzy · 2017-03-25 13:03:39

quequotion wrote:

Noted for future reference: Direct questions about extra/packages to this subforum.

Yeah, no. If you have a question about creating or modifing packages, this is the correct forum for it. Read the subforum names and descriptions to see what sort of topics belong in other subforums. It's all fairly intuitive, although I appreciate that there is a certain amount of crossover in some instances. Use your best judgement, and the mod team will sort out any misplaced topics.

Do you have a package providing that header file installed in your $CHROOT/root?

Nope. Here's my build log: https://paste.pound-python.org/show/PSQ … 46NSfjZjr/

quequotion · 2017-03-25 13:08:52

Trilby wrote:

timidity++ just built find in a chroot here too. Are you using the exact PKGBUILD and patches from the ABS, or have you made changes?

I was using the exact PKGBUILD from the ABS, but I just found that replacing ./configure with ./autogen.sh prevents the false positives (making above patch unnecessary).

Is there a reason why the PKGBUILD uses configure instead of autogen.sh?

Last edited by quequotion (2017-03-25 13:09:59)

WorMzy · 2017-03-25 13:19:37

Well, it's what upstream recommends. I suspect the maintainer has had no reason to deviate from their instructions.

INSTALL wrote:

======================================================================
Basic Installation
======================================================================
TiMidity++ uses GNU autotools to build. So the simplest way to
compile this package is:
1. "cd" to the directory containing TiMidity++'s source code and type
"./configure" to configure the package for your system. If you are
using csh on an old version of System V, you might need to type
"/bin/sh configure" instead to prevent csh from trying to execute
configure itself. Running configure takes a while. While running,
it prints some messages telling which features it is checking for.
2. Type "make" to compile the package.
NOTE: this make method requires GNU make. So if your system has it
as gamke, type "gmake" instead.
3. Type "make install" to install the programs and any data files and
documentation.

The problem seems to be your chroot. What packages, aside from base-devel, are installed in it? Did you enable testing in it?

Trilby · 2017-03-25 13:29:15

quequotion wrote:

I was using the exact PKGBUILD from the ABS, but I just found that replacing ./configure with ./autogen.sh prevents the false positives (making above patch unnecessary).

What? So you used the PKGBUILD from ABS, but you are trying to get rid of one of the patches ... but is the error you received from removing the patch?

Again, do you get the error in your first post when you build in a clean chroot using the PKGBUILD and patches from the ABS? Or do you only get an error when you deviate from that?

quequotion · 2017-03-25 15:16:31

WorMzy wrote:

What packages, aside from base-devel, are installed in it?

I made a whole new chroot from scratch and did some more testing. This was not package related; it was configuration.

Although my chroot was "clean" I had set some options in makepkg.conf to enable link-time optimization.

In theory LTO should work with any software that gcc can build; in practice problems like this happen from time to time.

The specific options I set are:

		CFLAGS+=" -flto=$(getconf _NPROCESSORS_ONLN)"
		CXXFLAGS+=" -flto=$(getconf _NPROCESSORS_ONLN)"
		LDFLAGS+=" -fuse-linker-plugin"
		LTOPLUGIN="$(gcc -print-search-dirs | grep install | awk '{print $2 "liblto_plugin.so"}')"
		ARFLAGS+=" --plugin $LTOPLUGIN"
		RANLIBFLAGS+=" --plugin $LTOPLUGIN"
		NMFLAGS+=" --plugin $LTOPLUGIN"

I did test with these settings disabled before posting the thread, not sure why that test failed in the same place with the same error.

Did you enable testing in it?

No.

quequotion · 2017-03-25 15:22:53

Trilby wrote:

What? So you used the PKGBUILD from ABS, but you are trying to get rid of one of the patches ... but is the error you received from removing the patch?

You should probably read that again; I got rid of my own patch.

I started with the exact PKGBUILD from ABS; did several build attempts, tested a few settings, couldn't get the package to build, then I made a patch to bypass the failing parts of configure. Later I found that autogen.sh somehow avoided the problem; later still I repeated the test of building without lto and this time I got a different result than before.

Note: autogen.sh still avoids the error, even with LTO enabled.

Last edited by quequotion (2017-03-25 15:36:48)

Trilby · 2017-03-25 15:58:02

quequotion wrote:

You should probably read that again...

No, I probably shouldn't. When you are seeking help the burden is on you to describe the situation. I asked if you were using the PKGBUILD and patches from the ABS and you avoided answering the complete question.

quequotion · 2017-03-25 17:39:47

Trilby wrote:

quequotion wrote:
You should probably read that again...
No, I probably shouldn't. When you are seeking help the burden is on you to describe the situation. I asked if you were using the PKGBUILD and patches from the ABS and you avoided answering the complete question.

I'm not trying to argue with you about it, but that's not what happened. Go back a few posts and you will see.

(ie, my first post was the answer to your question)

Last edited by quequotion (2017-03-25 17:41:30)

Arch Linux

#1 2017-03-25 12:26:24

[SOLVED] Cannot build extra/timidity++ in clean chroot

#2 2017-03-25 12:39:27

Re: [SOLVED] Cannot build extra/timidity++ in clean chroot

#3 2017-03-25 12:44:02

Re: [SOLVED] Cannot build extra/timidity++ in clean chroot

#4 2017-03-25 12:47:17

Re: [SOLVED] Cannot build extra/timidity++ in clean chroot

#5 2017-03-25 12:48:17

Re: [SOLVED] Cannot build extra/timidity++ in clean chroot

#6 2017-03-25 12:59:26

Re: [SOLVED] Cannot build extra/timidity++ in clean chroot

#7 2017-03-25 13:03:39

Re: [SOLVED] Cannot build extra/timidity++ in clean chroot

#8 2017-03-25 13:08:52

Re: [SOLVED] Cannot build extra/timidity++ in clean chroot

#9 2017-03-25 13:19:37

Re: [SOLVED] Cannot build extra/timidity++ in clean chroot

#10 2017-03-25 13:29:15

Re: [SOLVED] Cannot build extra/timidity++ in clean chroot

#11 2017-03-25 15:16:31

Re: [SOLVED] Cannot build extra/timidity++ in clean chroot

#12 2017-03-25 15:22:53

Re: [SOLVED] Cannot build extra/timidity++ in clean chroot

#13 2017-03-25 15:58:02

Re: [SOLVED] Cannot build extra/timidity++ in clean chroot

#14 2017-03-25 17:39:47

Re: [SOLVED] Cannot build extra/timidity++ in clean chroot

Board footer