Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[fix failure to find libunwind on armhf] switch to cmake or autotools #34

Open
sten0 opened this issue Mar 29, 2018 · 7 comments
Open

Comments

@sten0
Copy link
Contributor

sten0 commented Mar 29, 2018

Hi!

While investigating why Debian builds were failing for armhf and finding that libunwind wasn't being correctly detected, several people advised me to add either autotools or cmake support to memleax and to drop the hand-written configure. Have you already tried either of these, is there one you would prefer, and are you interested in adding the support yourself or would you like me to learn how to do this?

Sincerely,
Nicholas

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/memleax.html

@WuBingzheng
Copy link
Owner

Thanks for post this.

I am not familiar with the package built system.
But it seems that libunwind is not installed in the system, because I see the following output which is not printed by my configure file:

 pbuilder-satisfydepends-dummy depends on libunwind-dev; however:
  Package libunwind-dev is not installed.

So would you like to make sure what's the problem? Is "libunwind not installed" or "installed but cat not detected by my hand-written configure" ?

I did not use autotools or cmake neither. I can not give you advice.
If that's useful to fix the problem, you are welcomed to add them.

@sten0
Copy link
Contributor Author

sten0 commented Apr 1, 2018

Hi! Thank you for such a prompt reply :-) Yes, libunwind8 and libunwind-dev are installed. Here are the filelists:
https://packages.debian.org/sid/armhf/libunwind8/filelist
https://packages.debian.org/jessie/armhf/libunwind-dev/filelist

On the IRC channel #debian-mentors@oftc someone recommended adding autotools or cmake support as a way to prevent these kinds of issues--might be caused by changing binutils and gcc versions? The idea being do the work once and never worry about it again ;-) I'm leaning towards cmake, because it's simpler and because I don't think memleaks would benefit from autotools' extensive legacy (old UNIX systems) and non-Linux support...so I think it would be a lot more trouble for little gain. What do you think? P.S. Yes, I'm willing to learn how to add this support

@WuBingzheng
Copy link
Owner

Thanks for the improvement.

@morxa
Copy link
Contributor

morxa commented Jul 5, 2018

What's the status here? I'm currently looking into packaging memleax for Fedora, but the hand-written configure script is a blocker, as it doesn't accept some of the options that are passed by Fedora's %configure macro. A configure script based on autotools or a cmake setup would solve the issue.

@WuBingzheng
Copy link
Owner

I do not know the status.
Would you like to do this if you are familiar with autotools or cmake?

@sten0
Copy link
Contributor Author

sten0 commented Jul 6, 2018 via email

@WuBingzheng
Copy link
Owner

look forward to your work!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants