Summary:	ASTERISK-07668: [patch] Compilation failures when building on Solaris with Zaptel drivers
Reporter:	Bob Atkins (bob)	Labels:
Date Opened:	2006-09-03 05:55:35	Date Closed:	2011-06-07 14:02:59
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Addons/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) configure.patch ( 1) Makefile_apps.patch_090306 ( 2) Makefile_res.patch_090306 ( 3) Makefile.patch_090306 ( 4) makeopts.in.patch
Description:	Several search paths are not correct when compiling under Solaris with zaptel drivers. In addition some other seach paths need to be modified to account for theuse of the /opt path for include files and library searches. Installation paths are also peculiar for Solaris systems. ****** ADDITIONAL INFORMATION ****** Main, apps and res Makefiles are affected and require changes to allow a clean compile on Solaris when zaptel drivers are used. These patches also include changes to include the /opt tree for local includes and libraries. Installation paths have also been changed to reflect standard installation paths for Solaris systems. Asterisk will not compile/link with -lncurses, at least on Solaris 2.8 however, it does compile with -lcurses. libmtmalloc has been added to the LIBS to provide for optimum performance for multi-threaded apps in Solaris. I am submitting patches for all affected files to this bug report for consideration.
Comments:	By: Bob Atkins (bob) 2006-09-15 19:55:15 Any possibility that this bug can be looked at for possible incoporation? By: Tilghman Lesher (tilghman) 2006-09-16 03:12:26 We need you to file a disclaimer before we can even look at your patches. By: Bob Atkins (bob) 2006-09-16 11:30:10 I filed a disclaimer a few months ago before I submitted my first bugs. Digium does have it on file. By: Bob Atkins (bob) 2006-09-16 11:32:58 Sorry - it looks like I forgot to check the Disclaimer on File box when I submitted this bug. I can't fix it now that the bug is open. By: jmls (jmls) 2006-11-01 06:12:19.000-0600 is this still the case with 1.2.13, and is it relevant to 1.4 / trunk ? By: Bob Atkins (bob) 2006-11-05 04:44:09.000-0600 The patches that I have attached to the bug note have not been incorporated in v1.2.13. In looking at the Makefile for 1.4.0-beta3 it looks like things have taken a step even further backwards in terms of portability for Solaris builds. This is disappointing to say the least. I'm not saying that my patches are the solution but at the same time it seems that nobody else has been working on Solaris portability. We are running Asterisk 1.2.12 in production on Sun Solaris 8 and will shortly have it running on Solaris 10. I expect to be submitting a bunch more portability fixes. By: Serge Vecher (serge-v) 2006-11-09 11:00:21.000-0600 Thanks for working on this, Bob. If anybody you know have tested your patches, a quick note with their testing experience would really help the chances of these patches being merged in. By: Olle Johansson (oej) 2007-02-16 07:58:21.000-0600 Ok, we need to set the target now to Asterisk 1.4, where everything has been changed with configure and menuselect. Can you please look into 1.4 and see if there's any improvements or if we need to change? By: Bob Atkins (bob) 2007-03-07 15:21:52.000-0600 I tried to build v1.4 but it failed to compile menuselect on Solaris with what looked like a basic code compilation error. I figured that I would wait until v1.4.1 was released before it would make sense to seriously debug the Solaris build process which I intend to do next. I am at the VPF conference in Miami and won't be able to do any work on this until next week. By: Bob Atkins (bob) 2007-03-26 12:27:15 Attempting to build asterisk v1.4.2 on Solaris 10 with gcc v4.1.1 fails the tests for the IMAP library. The configure test for IMAP is too severely limited to allow any influence by externally defined LDFLAGS and CFLAGS. The test will not support building wiht a shared c-client library. In general configure tests should not specify the full path of a library but should instead specify -L<path> and -l<lib> which will provide much more flexibility. The same is true for -I<path> for includes. This is especially true for the UW IMAP c-client library since that package's author doesn't have an installation specified for the c-client library so it could be installed in a variety of ways on different systems. In addition, tests for the IMAP library must also include linking to the SSL libs in order to pass. However, the SSL library test come *after* the IMAP library tests in the configure script. I recommend that the tests be reversed and that the tests for the IMAP library incorporate the learned search paths for the SSL libraries. I have uploaded a somewhat brute force patch for the configure script to get the tests for the IMAP library to work properly. The patch allows externally defined LDFLAGS and CFLAGS to influence the test and will support static or shared versions of the c-client library (for those of us that build shared libs) and the test will also support 64 bit builds. By: Bob Atkins (bob) 2007-03-26 12:33:15 menuselect configure script fails with the following error: make[1]: Entering directory `/home/bob/src/asterisk/asterisk-1.4.2_64bit/menuselect' configure: error: C compiler cannot create executables See `config.log' for more details. make[1]: *** [autoconfig.h] Error 77 Turns out that makeopts.in has hardcoded HOST_CC=cc. This breaks builds for those of us that expect to be using gcc as the preferred compiler. This along with the IMAP test problems that I reported in my earlier note are not just Solaris specific portability issues. I would expect that both of these problems would likely affect all OS ports. I have uploaded a patch to makeopts.in that changes HOST_CC=@CC@ so that the desired compiler gets passed down into the makeopts script as a result of the configure script. By: Serge Vecher (serge-v) 2007-03-26 12:39:24 bob: would you please combine those two patches in a single one and post as a separate issue under "Core Asterisk -> config" since the problems they fix are not necessarily Solaris-specific? Thanks. By: Michiel van Baak (mvanbaak) 2007-09-08 05:32:07 Is this still relevant with current 1.4 and/or trunk ? By: Bob Atkins (bob) 2007-09-09 22:20:09 The entire build system for 1.4 is seriously broken for Solaris. Unfortunately there are way too many problems for us to devote time to fixing in a manner that would be reasonable to contribute back. We took the axe out and hacked our own build solution for asterisk 1.4 on Solaris which we continue to use today. SOme of the biggest issues that we ran into had to do with specifying the full path to option libraries which prevent the linker from performing any searches making it impossible to specify alternative library search paths - this was a particular impact when trying to incorporate the c-client imap library. If anyone is wondering Solaris typically uses /opt and /usr/sfw rather than /usr/local. We also found that CFLAG and LDFLAG options provided to the configure script were not being properly passed down to sub-ordinate configure scripts - this further broke the build process. Finally - menuselect is a complete waste of time and adds a fully non-standard method to configure the build that everyone has to learn. All build options should be specified to the configure script. Take a look at the way PHP is built. If PHP doesn't need something like menuselect I don't see why asterisk does. I hope that others with far more experience than I will be able to fully fix the build process for asterisk 1.4 so that it is compliant with the vast majority of opensource software that uses the autoconf/configure build process. Please do not wait on me to close this ticket as I am not able to contribute anything back to fix the problems that I reported. By: Tilghman Lesher (tilghman) 2007-09-09 23:54:18 The 1.4 system is actually not broken at all for Solaris.  This past week, I successfully built and installed Asterisk on Solaris 11, with only one minor change, and it had to do with the fact that sunfreeware's gcc is a relatively old 3.4.6. The one change I made was to include/asterisk/lock.h to change an assembly parameter that did not work correctly in the assembler. Other than that, I simply had to change the path to set /usr/local/bin first and /usr/xpg4/bin second.  /usr/local/bin is where sunfreeware installed GNU make and gcc, which /usr/xpg4/bin is where a compatible version of awk can be found.  I would invite you to try this technique, as it makes the Asterisk 1.4 build system work just fine. By: Tilghman Lesher (tilghman) 2007-09-10 00:01:26 Closed at request of reporter.