-
-
Notifications
You must be signed in to change notification settings - Fork 11.4k
Conversation
We can ignore the first problem since it'll be dealt with in #46125 but looks like there'll need to be a
|
url "http://downloads.asterisk.org/pub/telephony/asterisk/asterisk-13.6.0.tar.gz" | ||
sha256 "8a01b53c946d092ac561c11b404f68cd328306d0e3b434a7485a11d4b175005a" | ||
|
||
option "with-sample-config", "Install the sample config files. NOTE. Without this, you won't have any config file." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any situation where you wouldn't want a sample config?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not yet so familiar with asterisk as to knowledgable answer that question.
As a base for this formula I used the last one that was removed in 29680ba, that is wehre with-sample-config
option stems from.
I would be ok with removing it.
Toolkit for building communications applications
I came across a homebrew-asterisk tap by @leedm777, it might be worthwhile to base a common asterisk formula on those. I'll have a look. What's everybody's opinion about this? |
Interestingly the tapped asterisk segfaults for me. I'll dig deeper. @leedm777 care to give any hints what may go wrong and how I might be able to help improve the tap or bring asterisk into the main homebrew repo? |
The segfaults disappear when asterisk is compiled against the OpenSSL provided by the system, i.e. when |
Presuming it takes one, try feeding the configure script a path to our OpenSSL. Some scripts can get confused about which OpenSSL to use. |
The previously mentioned homebrew-asterisk tap passes ``--with-ssl=Formula["openssl"].opt_prefix` to the configure script and asterisk also segfaults. |
If you can't get it working with our OpenSSL, we won't accept it here I'm afraid. You may need to check with upstream and see whether they are aware of any reason it wouldn't build against newer OpenSSL versions. |
Interesting. What's the reason behind this requirement? |
The system version is deprecated, outdated and no longer really secure. |
OpenSSL 0.9.8, and by extension the system OpenSSL, is terrible. Outdated cipher choices & is dead upstream in ~5 weeks time. |
Garg, I jumped on Mike again 😓. |
@DomT4 Don't worry about it 😀 |
That makes sense. @leedm777 any insight you could provide on why asterisk segfaults (for me?) when installed with homebrew's OpenSSL? |
I have been trying to build asterisk on El Capitan. Both the @leedm777 tap and the formula above result in 'Segmentation fault: 11' when I run asterisk after the build. It does build fine without errors. |
Sorry for the wall of text, but there's a lot to respond to. re: merging the formulas, I would be very happy with contributing the formulas in my tap back to Homebrew. I haven't because it started out as a personal project, and they were pretty specific to my day to day work with Asterisk. I've since made the formulas generic, and I'd say my tap is Pretty Good™. With the minor exception that it apparently it segfaults for some people. Yeah, except for that one thing. If nothing else, I think there's a lot of good stuff in my tap that I would like to see in any official formula (making clang optional, an Asterisk-customized version of PJSIP (a.k.a. PJPROJECT), plist, dev-mode support, a Travis build catching devel and head failures early). re: segfaults, with my tap I only see them when using Any chance of getting a stack trace/core dump from when it happens? You may need to install And could you pastebin the output of re: OpenSSL support upstream, Asterisk should work with that latest OpenSSL. In fact, I'm really surprised it ran at all with 0.9.8. re: sample configs, the Asterisk sample configs are not the best place to start; those are really more for reference documentation. Asterisk has recently started including better sample configs that target use cases instead of trying to be extensive documentation. The Makefile target installing them was added after 13.6.0, and I was planning on switching to installing the If we're starting a formula based on 13.6.0, then I recommend backporting the the patch adding the Makefile target and installing |
How would I create stack traces? I can build on a clean VM and provide it later tonight. |
There are some instructions on the Asterisk wiki. It recommends enabling I just pushed an update to add a
Wow! Thanks for taking the time to work on it. I should point out (since it's an easy step to miss on a fresh machine), that you will need to have the CLT installed for Asterisk to compile properly (see #34461). Be sure to run |
Apologies, I promised too much. My saved VM is pre-Xcode. For some reason App Store is taking it's sweat time. 6 hours later and Xcode download has still 2 hours to go... Reading the Asterisk wiki for now. |
@adilinden Yuck. Sorry for the hassle :-( |
I have to apologize again. I can no longer reproduce 'Segmentation fault: 11'. It builds fine and it starts fine. I do not know what to say... I even tried a Core 2 Duo and a i5 hardware. In both cases, as well as my segfault issues, all Fusion VM running 10.11. Unfortunately I did not save the state of the segfault build. I rolled back to an earlier snapshot and reinstalled Xcode and homebrew. |
@adilinden Thanks for taking the time to look into it. It's a crazy issue that is really hard to reproduce, unless it happens to you. When it happens, it happens every time you start Asterisk. Until it stops happening, then it's impossible to reproduce again. On the bright side, at some point someone in the future may be googling for "segfault asterisk homebrew", come across this issue, and upload the backtrace or To everyone else on the thread, is there enough interest that I should put up a PR proposing the Asterisk formulas from my tap? My biggest question would be if there are any concerns about having the keg-only version of PJSIP that's different from the standard formula. |
After further investigation I came across the following oddity: Running asterisk compiled from the leedm777/homebrew-asterisk tap works fine if Could this be related to my uncommon homebrew installation location @leedm777 Could there be an issue with asterisk's What do the homebrew maintainers think of the
|
Potentially. Some build scripts favour |
@DomT4 Yes, that is possible via the |
@afh You're also picking up the system sqlite instead of homebrew's, which could also be a problem. And you're missing I don't see the problem on my install, but I also have homebrew installed into $ otool -L $(brew --prefix)/sbin/asterisk
/usr/local/sbin/asterisk:
/usr/local/Cellar/asterisk/13.6.0/lib/libasteriskssl.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current version 10.9.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
/usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current version 55.1.0)
/usr/lib/libxslt.1.dylib (compatibility version 3.0.0, current version 3.26.0)
/usr/local/opt/sqlite/lib/libsqlite3.0.dylib (compatibility version 9.0.0, current version 9.6.0)
/usr/local/opt/openssl/lib/libssl.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/opt/openssl/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/opt/jansson/lib/libjansson.4.dylib (compatibility version 12.0.0, current version 12.0.0)
/usr/local/lib/libuuid.16.dylib (compatibility version 17.0.0, current version 17.22.0)
/usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0)
/usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libedit.3.dylib (compatibility version 2.0.0, current version 3.0.0)
/usr/local/opt/ncurses/lib/libncursesw.6.dylib (compatibility version 6.0.0, current version 6.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 104.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1225.1.1)
/usr/local/lib/gcc/5/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
$ otool -L $(brew --prefix)/lib/libasteriskssl.dylib
/usr/local/lib/libasteriskssl.dylib:
/usr/local/opt/asterisk/lib/libasteriskssl.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/opt/openssl/lib/libssl.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/opt/openssl/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1225.1.1)
/usr/local/lib/gcc/5/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) |
@leedm777 We'd rather use the system versions of libraries where possible. |
@leedm777 I've done further tests and used the formula from you tap, here are my findings: After
Adding Asterisk was been built with
With this setup asterisk crashes with a segfault, here's the LLDB backtrace:
In the backtrace I stumbled upon frame #2, #3, #4. So I tried compiling asterisk with
For some odd reason even though the asterisk formula from your tap specifically uses the This compiled asterisk binary runs just fine. Where would I look in asterisk's compile setup (configure et al) in order to find out/change which paths are checked in which order? For me putting homebrew in |
@afh That is an excellent detailed report. Thanks! I think we're probably getting pretty far afield from this PR, so I've created leedm777/homebrew-asterisk#20 and suggest we move the discussion to there. |
Interesting. I created leedm777/homebrew-asterisk#21 to track fixing that issue in my tap. |
@leedm777 Thanks for tracking the issues on your tap. I need to sort out some of the confusion that I've had with trying to find a solution to the issue and will post updates to the aforementioned issues. |
@afh Still interested in working on this? |
Closing this due to inactivity/lack of response. If you'd still like to pursue this, feel free to respond to the previous comments/questions and re-open on the new |
Toolkit for building communications applications
Please also consider merging #46125 since the PR contains this formula's optional dependency on spandsp.