Launchpad itself

Build succeeds on my local machine but fails on PPA environment

Asked by Synapse Developer Team

(C/C++ specific)

While building my package, the build succeeds on my machine but the linking phase fails on PPA build machine.
I'm linking against a static library which is included in my source code distribution, and PPA complains that the file is not found. To be more specific, it says "No rule to make target 'foo.a'".

Is this behavior by design or am I doing something wrong?
Is it forbidden to include a binary library file in a source code tree?
I'm quite sure this is Launchpad PPA specific stuff.

Is there any solution/workaround for this? Any help would be appreciated.

Question information

Language:
English Edit question
Status:
Solved
For:
Launchpad itself Edit question
Assignee:
No assignee Edit question
Solved by:
Synapse Developer Team
Solved:
Last query:
Last reply:

This question was reopened

Revision history for this message
Colin Watson (cjwatson) said : 		#1

They're not forbidden as such, and PPAs as such don't care, but they're in dpkg-source's default list of files to ignore when building a source tarball and the -I option is used (see @tar_ignore_default_pattern in /usr/share/perl5/Dpkg/Source/Package.pm), and recipes don't provide a way to override that, so the source package built by your recipe doesn't include the .a files. You can see this by downloading and unpacking the package files from https://launchpad.net/~synapse-network/+archive/ubuntu/ppa/+packages and comparing them to your git tree.

Your options are:

 * build these objects from source
 * build-depend on and link against the packaged version of glfw instead, if that's possible
 * upload source packages to your PPA manually rather than using recipes
 * hack around this behaviour by storing the relevant files in your tree in some other way (for example you could embed a tarball)

Revision history for this message
Synapse Developer Team (synapse-network) said : 		#2

Thanks a lot for your detailed answer, that was exactly the information what I needed.

My feelings for each options are as follows:

1. This is a difficult problem.
  It is hard to maintain every objects (i.e. PPA packages) which might be VERY complicated or proprietary.
  And you also have to write debian/control, debian/rules, etc... stuff and so on.

2. This is difficult in some cases, too.
  Minor libraries are often not in existing PPA repositories and even if it exists, it is quite likely not maintained (sadly).

3. This looks fine to me.
  The difference between manual upload and recepies are, as far as I know, only the functionality of "daily builds".
  I think I can just upload the source package to my PPA manually. Quite simple.

4. This looks OK to me too.
  This could be a final solution when I come into another hard issue.

Anyway, thanks a lot for your answer!

Revision history for this message
Synapse Developer Team (synapse-network) said : 		#3

Thanks Colin Watson, that solved my question.

Revision history for this message
Synapse Developer Team (synapse-network) said : 		#4

But wait... I am indeed compiling glfw from source inside override_dh_* and launchpad is still complaining that the desired output libglfw3.a does not exist. Am I missing something?

It should have been done *after* the dpkg-source and I think the output during the build phase must not be ignored.

Revision history for this message
Synapse Developer Team (synapse-network) said : 		#5

Sorry, my bad. I was building against shared library, not the static library. Totally my bad.