Please make configure script lib64 saavy
GoogleCodeExporter opened this issue · comments
Please add the variable libdir to the configure script so that I can parse the
command
./configure --prefix=/usr --libdir=/usr/lib64
Original issue reported on code.google.com by simon.lewis@slnet-online.de on 1 May 2012 at 9:30
Sorry, found the following solution:
qmake -makefile synthclone.pro
make
Original comment by simon.lewis@slnet-online.de on 1 May 2012 at 9:42
Issue 11 has been merged into this issue.
Original comment by surfacep...@gmail.com on 1 May 2012 at 3:56
I'm confused as to how the solution you suggested helps synthclone to be built
with libraries put in /usr/lib64.
I think that what probably needs to happen is 'synthclone.pri' needs to be
changed so that:
1.) 'CONFIG += x86_64' is added for 64-bit builds
2.) 'SYNTHCLONE_LIBRARY_SUFFIX' is set to 'lib64' for 64-bit builds
3.) 'SYNTHCLONE_PLUGIN_SUFFIX' is set to 'lib64/synthclone/plugins' for 64-bit builds
I need to do a bit more research to confirm whether or not I'm correct. In the
meantime, I'd like to hear your thoughts on how to solve the problem.
Original comment by surfacep...@gmail.com on 1 May 2012 at 4:09
Then again, maybe there's a good reason to add a 'libdir' flag to the
`configure` script. Hmmm.
Original comment by surfacep...@gmail.com on 1 May 2012 at 4:19
Try applying this patch and rebuilding. I don't have a 64-bit machine to test
it on. If it works, then I'll commit it and bump the revision.
Original comment by surfacep...@gmail.com on 2 May 2012 at 4:08
Attachments:
Scratch that. Try this patch instead. If it works, it will handle plugins
properly.
Original comment by surfacep...@gmail.com on 2 May 2012 at 4:50
Attachments:
On Issue #11, you posted:
Sorry, cannot make head or tail of the error message:
make[1]: *** [sub-plugins-make_default-ordered] Error 2
make[1]: Leaving directory `/home/simon/rpmbuild/BUILD/synthclone-0.2.0/src'
make: *** [sub-src-make_default] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.H0y1Ph (%build)
... and then you said that the project just wasn't 64-bit savvy because "The
make is looking for libportmidi under /usr/lib and not /usr/lib64".
I don't have all of the output from the command you ran (please post all the
output instead of just the error message next time), but if the build failed at
the point of looking for libportmidi and not before that point, then that means
that libsynthclone, the Hydrogen plugin, and the JACK plugin all built fine on
the 64-bit machine, which means that libsamplerate, Qt, and JACK were linked
into various components of synthclone without problems.
This begs the question: if these other components built correctly in this
environment, then why did the build that relied on libportmidi fail?
Can you please post the complete output of your RPM build?
Thanks.
Original comment by surfacep...@gmail.com on 2 May 2012 at 3:52
Not quite there but getting better...
- Sorry guys, I think I set a force trail in that I had mistakenly installed
the 32bit and not the 64 bit package of portmidi-devel
- Using the normal ./configure plus the diff doesn't get very far - see log
attached
- Using the following without diff builds but fails at the install into the
build root - see log attached
export PATH=${PATH}:%{_libdir}/qt4/bin
qmake -makefile synthclone.pro
%__make %{?_smp_mflags}
%__make DESTDIR=%{buildroot} install
- I guess I need to pass some arguments to the qmake something like
-DQMAKE_PREFIX=%{_prefix} and -DQMAKE_INSTALL_DIR=%{buildroot} but I quite
quite work it out.
I also attached the makefile generated by qmake.
I'm very grateful for all the help you can give, with best regards Simon
Original comment by simon.lewis@slnet-online.de on 2 May 2012 at 4:44
Attachments:
This is very helpful. :)
Here are some hints to help make the build successful:
1.) Read the following to understand the packaging scheme used by `synthclone`:
http://code.google.com/p/synthclone/source/browse/README.PACKAGING
2.) You'll find that you won't be able to use the normal 'configure', as this
isn't an autotools project.
3.) The first error in your qmake log is:
mkdir: cannot create directory `/usr/local/include/synthclone/': Permission denied
I'm assuming this is happening during:
%__make DESTDIR=%{buildroot} install
Try changing this line to read:
%__make install INSTALL_ROOT=%{buildroot}
4.) The qmake line should be a './configure' line. Something as simple as:
./configure --prefix=/usr
... will probably work out. If specifying the library directory is really
necessary, then we can talk about adding it to the configure script.
Hope this helps. :)
Out of question, for what distribution(s) are you building `synthclone`?
Original comment by surfacep...@gmail.com on 2 May 2012 at 5:05
Thanks for the quick response - I'm using fedora 16 however this applies
equally to opensuse, mandriva, mageia, centos etc..
The configure file is a no-goer as its too debian specific and not a universal
set-up
The following, as a first step works:
export PATH=${PATH}:%{_libdir}/qt4/bin
qmake -makefile synthclone.pro PREFIX=%{_prefix}
pushd src
qmake -makefile src.pro PREFIX=%{_prefix}
popd
%__make %{?_smp_mflags}
%__make install INSTALL_ROOT=%{buildroot}
However I need to move a lot of files around according to the following rules:
PREFIX=/usr
LIBDIR=/usr/lib64 (x86_64) /usr/lib (i686)
INCLUDEDIR=/usr/include
DATADIR=/usr/share
(Debian also uses the concepts LIBDIR INCLUDEDIR DATADIR)
Thanks for all your help up to now.
With best regards, Simon Lewis
Original comment by simon.lewis@slnet-online.de on 3 May 2012 at 5:05
AFAIK, the configure file doesn't have anything that's Debian-specific.
However, you're correct that the configuration file is not universal. I'd
certainly like to get it closer to being universal, which is why I'm asking
questions, and would like to get the configure file to support your use-case.
I have a couple questions:
1.) What does this:
pushd src
qmake -makefile src.pro PREFIX=%{_prefix}
popd
... do for you that this:
qmake -makefile synthclone.pro PREFIX=%{_prefix}
... doesn't already do?
2.) Why can't you just do this:
./configure --prefix=%{_prefix}
... instead of this:
qmake -makefile synthclone.pro PREFIX=%{_prefix}
pushd src
qmake -makefile src.pro PREFIX=%{_prefix}
popd
AFAICT, the configure command does all the same things the qmake commands do,
and it adds 'config.h' to the header files.
Original comment by surfacep...@gmail.com on 3 May 2012 at 4:22
Hi
Here is the answer to question 2:
[simon@spaceloopxl synthclone-0.2.0]$ ./configure --prefix=/usr
Traceback (most recent call last):
File "./configure", line 125, in <module>
main()
File "./configure", line 118, in main
if call(qmakeArgs):
File "/usr/lib64/python2.7/subprocess.py", line 493, in call
return Popen(*popenargs, **kwargs).wait()
File "/usr/lib64/python2.7/subprocess.py", line 679, in __init__
errread, errwrite)
File "/usr/lib64/python2.7/subprocess.py", line 1228, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory
[simon@spaceloopxl synthclone-0.2.0]$
As to question 1, I doubled checked the build process with qmake and found that
on make that the makefile for the sources is rewritten, so you are right, I
don't need the detour in the sources directory before building.
New point 3. A good example of a configure file that build on all distrubutions
and has done so for years is Qtractor. Perhaps there is a trick or two to be
learned there.
With best regards, Simon
r
Original comment by simon.lewis@slnet-online.de on 3 May 2012 at 5:56
Hi
The build project can be cloned from:
https://build.opensuse.org/package/show?package=Synthclone&project=home%3AWillia
mSimonLewis
As you will see the build was successful - there are few minor hacks in the
spec file.
However, when starting the app the following message was received:
[simon@spaceloopxl ~]$ /usr/bin/synthclone
"Translations loaded."
"Creating core application objects ..."
Error: core plugin directory is not accessible
"Unloading translations ..."
[simon@spaceloopxl ~]$
I'm guessing that the lib path is also hard-wired in the sources as well...
The build was made using qmake - which is common practice when making packages.
Original comment by simon.lewis@slnet-online.de on 5 May 2012 at 9:35
I understand that it's common to use `qmake` to make packages. The `configure`
script is just a wrapper around `qmake`. It does some things that `qmake`
can't elegantly do on its own, including creating a config.h header file.
Please use the `configure` script, as it's more versatile, and more likely to
work correctly for builds now and in the future.
It's become clear that I need to add some sort of --libdir option to the
configure script.
You're right; the 'lib' path is (currently) hardwired in the sources. For now,
you can solve the plugin directory error by modifying line 747 of
src/synthclone/controller.cpp to read:
if (pluginDirectory.cd("lib64")) {
I'll put some effort today into solving this problem in a more elegant fashion.
There are some recommendations in the 'README.PACKAGING' file regarding
separating `synthclone` into application and development packages.
Original comment by surfacep...@gmail.com on 5 May 2012 at 3:24
Please do not rename the 'synthclone-devel' documentation directory with any
name that implies that the documents are not strictly development documents.
The directory holds doxygen-generated documentation on the synthclone plugin
API. If and when there is actual help documentation for the application, then
it will be put in a directory with a name that will be similar to the one
you're using to rename the development documentation directory. A suitable
name that's similar might be:
share/doc/%{name}-dev-%{version}
This is more consistent with separating `synthclone` into application and
development packages.
I really appreciate that you're doing this, and I hope I'm not coming across as
a micro-managing type (if so, I apologize). Thank you for putting forth the
effort to make `synthclone` available to a wider audience. :)
Original comment by surfacep...@gmail.com on 5 May 2012 at 3:45
Please take a look at...
https://build.opensuse.org/package/binaries?package=Synthclone&project=home%3AWi
lliamSimonLewis&repository=Fedora_16
Original comment by simon.lewis@slnet-online.de on 6 May 2012 at 5:45
I think it looks great! I do have one question about the spec file, and I'm
not totally familiar with the RPM format, so maybe I'll end up learning
something by asking this question ...
Does each file that's installed need to be in the files section? I was looking
for references to the development API documentation, and I saw a `sed` command
that renamed the directory, but didn't see it referenced in the files section.
I'm really excited about seeing `synthclone` be available for download as an
RPM! Will you be submitting the RPM to Fedora and/or any other distributions?
Thanks again for putting forth the effort to do this. :) When I figure out how
I want to handle the `configure` script with regards to library directories,
I'll let you know.
Original comment by surfacep...@gmail.com on 6 May 2012 at 7:34
Yes, the build fails if one or more files in the buildroot are not include in
one of the package files lists.
In this spec file I used the %doc script to automatically pick-up the files in
the %_docdir. It is both a fedora and openSUSE requirement to use the %doc
script - plus it saves listing the files individually...
Original comment by simon.lewis@slnet-online.de on 6 May 2012 at 9:45
I believe the error above happens because qmake isn't in your path. So, this:
export PATH=${PATH}:%{_libdir}/qt4/bin
./configure --prefix=%{_prefix}
%__make %{?_smp_mflags}
%__make install INSTALL_ROOT=%{buildroot}
... should work.
I'll take a look at qtractor.
Original comment by surfacep...@gmail.com on 4 May 2012 at 2:49
Unfortunately, looking at Qtractor's build setup isn't very helpful. The build
process for Qtractor isn't nearly as complex as the build process for
`synthclone`, as Qtractor doesn't have a development API, headers, and plugins
based on its development API.
I'd really like to see what you're working on. Is there a public link
available?
Original comment by surfacep...@gmail.com on 4 May 2012 at 3:00
Hi Simon,
I know it's been a while, but I thought I'd let you know that my latest commit
contains what I believe is a more user-friendly configure script. If and when
you have some time, then I'd like to know if you think that the configure
script is now friendly to packagers that are creating packages for 64-bit
platforms. If the configure script is acceptable, then I'll go ahead and make
a release and close this issue.
Thanks in advance.
Original comment by surfacep...@gmail.com on 21 Aug 2012 at 3:43
- Changed state: Started
I think I've given enough time for a response. I'm closing this issue.
Original comment by surfacep...@gmail.com on 7 Feb 2013 at 6:16
- Changed state: Fixed