Optimal configuration for compiling on 64-bit platforms
Hello, I'm sure this has been talked about several times and searching through the email archives etc. I have seen 64-bit been mentioned many times, but never seen a targetted instructions as to what are the best/optimal parameters to give the configure script to compile on a 64-bit Linux platform. In the wiki, the following is given: CFLAGS=-m64 CXXFLAGS=-m64 LDFLAGS=-m64 ./configure --prefix=/opt/freeswitch --enable-core-odbc-support \ --enable-core-libedit-support --enable-64 --with-openssl=/usr/sfw But it's for compiling in Solaris. Do these flags/settings work on Linux? Can we just use '--enable-64' and that would take care of everything or do we need the extra CFLAGS, CXXFLAGS and LDFLAGS as well? I'm using Debian 64-bit Thanks AEG
You can specifiy -march options on the CXX and CFLAGS section, but I've only seen noticeable performance increases on the 32-bit platforms. I personally have "-O2 -g -march=pentium3" on the CXX and CFLAGS section as I run a small home office setup on my P3 router ;) On Fri, Apr 8, 2011 at 7:18 PM, A E [Gmail] <all.eforums@gmail.com> wrote:
Hello, I'm sure this has been talked about several times and searching through the email archives etc. I have seen 64-bit been mentioned many times, but never seen a targetted instructions as to what are the best/optimal parameters to give the configure script to compile on a 64-bit Linux platform. In the wiki, the following is given:
CFLAGS=-m64 CXXFLAGS=-m64 LDFLAGS=-m64 ./configure --prefix=/opt/freeswitch --enable-core-odbc-support \ --enable-core-libedit-support --enable-64 --with-openssl=/usr/sfw
But it's for compiling in Solaris. Do these flags/settings work on Linux? Can we just use '--enable-64' and that would take care of everything or do we need the extra CFLAGS, CXXFLAGS and LDFLAGS as well? I'm using Debian 64-bit Thanks AEG _______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Compilation flags (if you do not compile on one machine kind and run on another kind) are taken care of automatically by the bootstrap/configure/make mechanism. You are not supposed to do anything (actually, fiddling with those options can damage performance/stability). -giovanni On 4/9/11, curriegrad2004 <curriegrad2004@gmail.com> wrote:
You can specifiy -march options on the CXX and CFLAGS section, but I've only seen noticeable performance increases on the 32-bit platforms. I personally have "-O2 -g -march=pentium3" on the CXX and CFLAGS section as I run a small home office setup on my P3 router ;)
On Fri, Apr 8, 2011 at 7:18 PM, A E [Gmail] <all.eforums@gmail.com> wrote:
Hello, I'm sure this has been talked about several times and searching through the email archives etc. I have seen 64-bit been mentioned many times, but never seen a targetted instructions as to what are the best/optimal parameters to give the configure script to compile on a 64-bit Linux platform. In the wiki, the following is given:
CFLAGS=-m64 CXXFLAGS=-m64 LDFLAGS=-m64 ./configure --prefix=/opt/freeswitch --enable-core-odbc-support \ --enable-core-libedit-support --enable-64 --with-openssl=/usr/sfw
But it's for compiling in Solaris. Do these flags/settings work on Linux? Can we just use '--enable-64' and that would take care of everything or do we need the extra CFLAGS, CXXFLAGS and LDFLAGS as well? I'm using Debian 64-bit Thanks AEG _______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Sent from my mobile device Sincerely, Giovanni Maruzzelli Cell : +39-347-2665618
On Sat, Apr 9, 2011 at 6:23 PM, Giovanni Maruzzelli <gmaruzz@gmail.com>wrote:
Compilation flags (if you do not compile on one machine kind and run on another kind) are taken care of automatically by the bootstrap/configure/make mechanism. You are not supposed to do anything (actually, fiddling with those options can damage performance/stability). -giovanni
Thanks Giovanni. How about the -"-enable-64" option in the configure script? is that needed or should I just do a standard ./bootstrap.sh && ./configure && make && make install? Thanks
It seems for me on a PIII under SL6/Fedora 12-13 that the auto-optmization doesn't happen at all On Sat, Apr 9, 2011 at 3:23 PM, Giovanni Maruzzelli <gmaruzz@gmail.com> wrote:
Compilation flags (if you do not compile on one machine kind and run on another kind) are taken care of automatically by the bootstrap/configure/make mechanism. You are not supposed to do anything (actually, fiddling with those options can damage performance/stability). -giovanni
On 4/9/11, curriegrad2004 <curriegrad2004@gmail.com> wrote:
You can specifiy -march options on the CXX and CFLAGS section, but I've only seen noticeable performance increases on the 32-bit platforms. I personally have "-O2 -g -march=pentium3" on the CXX and CFLAGS section as I run a small home office setup on my P3 router ;)
On Fri, Apr 8, 2011 at 7:18 PM, A E [Gmail] <all.eforums@gmail.com> wrote:
Hello, I'm sure this has been talked about several times and searching through the email archives etc. I have seen 64-bit been mentioned many times, but never seen a targetted instructions as to what are the best/optimal parameters to give the configure script to compile on a 64-bit Linux platform. In the wiki, the following is given:
CFLAGS=-m64 CXXFLAGS=-m64 LDFLAGS=-m64 ./configure --prefix=/opt/freeswitch --enable-core-odbc-support \ --enable-core-libedit-support --enable-64 --with-openssl=/usr/sfw
But it's for compiling in Solaris. Do these flags/settings work on Linux? Can we just use '--enable-64' and that would take care of everything or do we need the extra CFLAGS, CXXFLAGS and LDFLAGS as well? I'm using Debian 64-bit Thanks AEG _______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Sent from my mobile device
Sincerely,
Giovanni Maruzzelli Cell : +39-347-2665618
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
On Sat, Apr 9, 2011 at 6:41 PM, curriegrad2004 <curriegrad2004@gmail.com>wrote:
It seems for me on a PIII under SL6/Fedora 12-13 that the auto-optmization doesn't happen at all
Well, I tried the simple straight-forward ./bootstrap.sh && ./configure && make but got a WHOLE bunch of other errors, which look much worse than the ones I got with compiling with the switches forcing 64-bit build. Looks like my only solution here might be to download source of openssl and compile it on this machine and see if that gets accepted :(
Compiler options have nothing to do with libraries incompatibilities. Why don't you use the standard libraries given by your distro? Never heard someone had to compile ssl libs for FreeSWITCH. Also never heard someone used any compiler options on standard machines. FS is targeted toward 64bit OSes, most people use CentOS, Ubuntu and Debian. CentOS is by far the most used and the reference platform. On 64bit. That said, if you're trying to optimize it for a PIII, an EPIA 5000 or an ARM, or whatever is not a standard server class machine, yes you better know how to optimize :). On 4/10/11, A E [Gmail] <all.eforums@gmail.com> wrote:
On Sat, Apr 9, 2011 at 6:41 PM, curriegrad2004 <curriegrad2004@gmail.com>wrote:
It seems for me on a PIII under SL6/Fedora 12-13 that the auto-optmization doesn't happen at all
Well, I tried the simple straight-forward
./bootstrap.sh && ./configure && make but got a WHOLE bunch of other errors, which look much worse than the ones I got with compiling with the switches forcing 64-bit build.
Looks like my only solution here might be to download source of openssl and compile it on this machine and see if that gets accepted :(
-- Sent from my mobile device Sincerely, Giovanni Maruzzelli Cell : +39-347-2665618
On Sat, Apr 9, 2011 at 7:40 PM, Giovanni Maruzzelli <gmaruzz@gmail.com>wrote:
Compiler options have nothing to do with libraries incompatibilities. Why don't you use the standard libraries given by your distro? Never heard someone had to compile ssl libs for FreeSWITCH. Also never heard someone used any compiler options on standard machines. FS is targeted toward 64bit OSes, most people use CentOS, Ubuntu and Debian. CentOS is by far the most used and the reference platform. On 64bit. That said, if you're trying to optimize it for a PIII, an EPIA 5000 or an ARM, or whatever is not a standard server class machine, yes you better know how to optimize :).
Trust me, I wouldn't want to be messing around with compiler options, custom libraries and custom kernel, but so far I've had to do ALL of that. I am just having the hardest time having FS even compile for me. I wasted a bunch of days on various versions of Solaris and then gave up and moved on to linux thinking this will at least have me up and running and EVEN if there was any proof that FS would run faster/better on Sparc hardware with the latest Solaris then I'd compromise with lesser performing OS and since Debian seems to be the choice of the masses when it comes to using anything other than Solaris on a 64-bit Sparc hardware, I went with that. And now I'm having trouble compiling it on this too. Such a shame! And I can't even pin-point exactly which module it's crashing in...all I see is it's trying to build libfreeswitch.la and goes through the installed ssl packages and says they're incompatible and then fails since it can't find -lssl *sigh* Like I said, I've already tried doing the vanilla ./bootstrap.sh && ./configure && make but that don't work. So I HAVE to mess around with compiler options and env variables...but which ones and what exactly?
Believe me, no. Many people is using and compiling FS on debian without any hitch. Is clearly described on the wiki. Install the prerequisites, then bootstrap configure make install. Maybe you have not installed the prerequisites, or your Debian installation is somehow botched or damaged. Maybe you want to reinstall Debian, then compile FS again. -giovanni On 4/10/11, A E [Gmail] <all.eforums@gmail.com> wrote:
On Sat, Apr 9, 2011 at 7:40 PM, Giovanni Maruzzelli <gmaruzz@gmail.com>wrote:
Compiler options have nothing to do with libraries incompatibilities. Why don't you use the standard libraries given by your distro? Never heard someone had to compile ssl libs for FreeSWITCH. Also never heard someone used any compiler options on standard machines. FS is targeted toward 64bit OSes, most people use CentOS, Ubuntu and Debian. CentOS is by far the most used and the reference platform. On 64bit. That said, if you're trying to optimize it for a PIII, an EPIA 5000 or an ARM, or whatever is not a standard server class machine, yes you better know how to optimize :).
Trust me, I wouldn't want to be messing around with compiler options, custom libraries and custom kernel, but so far I've had to do ALL of that. I am just having the hardest time having FS even compile for me. I wasted a bunch of days on various versions of Solaris and then gave up and moved on to linux thinking this will at least have me up and running and EVEN if there was any proof that FS would run faster/better on Sparc hardware with the latest Solaris then I'd compromise with lesser performing OS and since Debian seems to be the choice of the masses when it comes to using anything other than Solaris on a 64-bit Sparc hardware, I went with that. And now I'm having trouble compiling it on this too. Such a shame! And I can't even pin-point exactly which module it's crashing in...all I see is it's trying to build libfreeswitch.la and goes through the installed ssl packages and says they're incompatible and then fails since it can't find -lssl *sigh*
Like I said, I've already tried doing the vanilla ./bootstrap.sh && ./configure && make but that don't work. So I HAVE to mess around with compiler options and env variables...but which ones and what exactly?
-- Sent from my mobile device Sincerely, Giovanni Maruzzelli Cell : +39-347-2665618
Also, maybe in one of your previous attempts you botched the FS source. Delete it completely and git clone it again. -giovanni On 4/10/11, Giovanni Maruzzelli <gmaruzz@celliax.org> wrote:
Believe me, no. Many people is using and compiling FS on debian without any hitch. Is clearly described on the wiki. Install the prerequisites, then bootstrap configure make install. Maybe you have not installed the prerequisites, or your Debian installation is somehow botched or damaged. Maybe you want to reinstall Debian, then compile FS again. -giovanni
On 4/10/11, A E [Gmail] <all.eforums@gmail.com> wrote:
On Sat, Apr 9, 2011 at 7:40 PM, Giovanni Maruzzelli <gmaruzz@gmail.com>wrote:
Compiler options have nothing to do with libraries incompatibilities. Why don't you use the standard libraries given by your distro? Never heard someone had to compile ssl libs for FreeSWITCH. Also never heard someone used any compiler options on standard machines. FS is targeted toward 64bit OSes, most people use CentOS, Ubuntu and Debian. CentOS is by far the most used and the reference platform. On 64bit. That said, if you're trying to optimize it for a PIII, an EPIA 5000 or an ARM, or whatever is not a standard server class machine, yes you better know how to optimize :).
Trust me, I wouldn't want to be messing around with compiler options, custom libraries and custom kernel, but so far I've had to do ALL of that. I am just having the hardest time having FS even compile for me. I wasted a bunch of days on various versions of Solaris and then gave up and moved on to linux thinking this will at least have me up and running and EVEN if there was any proof that FS would run faster/better on Sparc hardware with the latest Solaris then I'd compromise with lesser performing OS and since Debian seems to be the choice of the masses when it comes to using anything other than Solaris on a 64-bit Sparc hardware, I went with that. And now I'm having trouble compiling it on this too. Such a shame! And I can't even pin-point exactly which module it's crashing in...all I see is it's trying to build libfreeswitch.la and goes through the installed ssl packages and says they're incompatible and then fails since it can't find -lssl *sigh*
Like I said, I've already tried doing the vanilla ./bootstrap.sh && ./configure && make but that don't work. So I HAVE to mess around with compiler options and env variables...but which ones and what exactly?
-- Sent from my mobile device
Sincerely,
Giovanni Maruzzelli Cell : +39-347-2665618
-- Sent from my mobile device Sincerely, Giovanni Maruzzelli Cell : +39-347-2665618
On Sat, Apr 9, 2011 at 8:15 PM, Giovanni Maruzzelli <gmaruzz@celliax.org>wrote:
Believe me, no. Many people is using and compiling FS on debian without any hitch. Is clearly described on the wiki. Install the prerequisites, then bootstrap configure make install. Maybe you have not installed the prerequisites, or your Debian installation is somehow botched or damaged. Maybe you want to reinstall Debian, then compile FS again. -giovanni
Haha wow, you feel really strongly about that. I am not denying that many people out there might be running successfully on debian 64-bit, I guess I have the extra issue of it being on Sparc, which may OR may not have ALL packages and the packages FS finds aren't to some compatibility level, which I have no idea what that is. This is a fresh debian install so I have no idea what might be botched on it but I'm cleaning out FS SRC and tried to make it, and even though this time the 'configure' script finds the ssl libs (seeing from grepping for them in config.log), it crashes way earlier than before in trying to build sqlite. Here's the dump make[1]: Entering directory `/home/fs/freeswitch/libs/sqlite' ./libtool --tag=CC --mode=link gcc -g -O2 -g -O2 -DOS_UNIX=1 -DHAVE_USLEEP=1 -DHAVE_FDATASYNC=1 -I. -I./src -DNDEBUG -DTHREADSAFE=1 -DSQLITE_THREAD_OVERRIDE_LOCK=-1 -DSQLITE_OMIT_LOAD_EXTENSION=1 -DHAVE_READLINE=0 -lpthread \ -o sqlite3 ./src/shell.c libsqlite3.la \ -lncurses libtool: link: gcc -g -O2 -g -O2 -DOS_UNIX=1 -DHAVE_USLEEP=1 -DHAVE_FDATASYNC=1 -I. -I./src -DNDEBUG -DTHREADSAFE=1 -DSQLITE_THREAD_OVERRIDE_LOCK=-1 -DSQLITE_OMIT_LOAD_EXTENSION=1 -DHAVE_READLINE=0 -o sqlite3 ./src/shell.c ./.libs/libsqlite3.a -lpthread -lncurses /usr/bin/ld: sparc:v9 architecture of input file `./.libs/libsqlite3.a(complete.o)' is incompatible with sparc:v8plus output /usr/bin/ld: sparc:v9 architecture of input file `./.libs/libsqlite3.a(main.o)' is incompatible with sparc:v8plus output /usr/bin/ld: sparc:v9 architecture of input file `./.libs/libsqlite3.a(os_unix.o)' is incompatible with sparc:v8plus output /usr/bin/ld: sparc:v9 architecture of input file `./.libs/libsqlite3.a(prepare.o)' is incompatible with sparc:v8plus output /usr/bin/ld: sparc:v9 architecture of input file `./.libs/libsqlite3.a(printf.o)' is incompatible with sparc:v8plus output /usr/bin/ld: sparc:v9 architecture of input file `./.libs/libsqlite3.a(random.o)' is incompatible with sparc:v8plus output /usr/bin/ld: sparc:v9 architecture of input file `./.libs/libsqlite3.a(table.o)' is incompatible with sparc:v8plus output /usr/bin/ld: sparc:v9 architecture of input file `./.libs/libsqlite3.a(tokenize.o)' is incompatible with sparc:v8plus output /usr/bin/ld: sparc:v9 architecture of input file `./.libs/libsqlite3.a(trigger.o)' is incompatible with sparc:v8plus output /usr/bin/ld: sparc:v9 architecture of input file `./.libs/libsqlite3.a(update.o)' is incompatible with sparc:v8plus output /usr/bin/ld: sparc:v9 architecture of input file `./.libs/libsqlite3.a(util.o)' is incompatible with sparc:v8plus output /usr/bin/ld: sparc:v9a architecture of input file `./.libs/libsqlite3.a(vdbeapi.o)' is incompatible with sparc:v8plus output /usr/bin/ld: sparc:v9 architecture of input file `./.libs/libsqlite3.a(vdbeaux.o)' is incompatible with sparc:v8plus output /usr/bin/ld: sparc:v9 architecture of input file `./.libs/libsqlite3.a(vdbefifo.o)' is incompatible with sparc:v8plus output /usr/bin/ld: sparc:v9a architecture of input file `./.libs/libsqlite3.a(vdbemem.o)' is incompatible with sparc:v8plus output /usr/bin/ld: sparc:v9a architecture of input file `./.libs/libsqlite3.a(where.o)' is incompatible with sparc:v8plus output /usr/bin/ld: sparc:v9 architecture of input file `./.libs/libsqlite3.a(utf.o)' is incompatible with sparc:v8plus output /usr/bin/ld: sparc:v9 architecture of input file `./.libs/libsqlite3.a(legacy.o)' is incompatible with sparc:v8plus output /usr/bin/ld: sparc:v9 architecture of input file `./.libs/libsqlite3.a(vtab.o)' is incompatible with sparc:v8plus output /usr/bin/ld: sparc:v9 architecture of input file `./.libs/libsqlite3.a(analyze.o)' is incompatible with sparc:v8plus output /usr/bin/ld: sparc:v9 architecture of input file `./.libs/libsqlite3.a(attach.o)' is incompatible with sparc:v8plus output /usr/bin/ld: sparc:v9 architecture of input file `./.libs/libsqlite3.a(auth.o)' is incompatible with sparc:v8plus output /usr/bin/ld: sparc:v9 architecture of input file `./.libs/libsqlite3.a(btree.o)' is incompatible with sparc:v8plus output /usr/bin/ld: sparc:v9 architecture of input file `./.libs/libsqlite3.a(build.o)' is incompatible with sparc:v8plus output /usr/bin/ld: sparc:v9 architecture of input file `./.libs/libsqlite3.a(callback.o)' is incompatible with sparc:v8plus output /usr/bin/ld: sparc:v9 architecture of input file `./.libs/libsqlite3.a(delete.o)' is incompatible with sparc:v8plus output /usr/bin/ld: sparc:v9 architecture of input file `./.libs/libsqlite3.a(expr.o)' is incompatible with sparc:v8plus output /usr/bin/ld: sparc:v9a architecture of input file `./.libs/libsqlite3.a(func.o)' is incompatible with sparc:v8plus output /usr/bin/ld: sparc:v9 architecture of input file `./.libs/libsqlite3.a(hash.o)' is incompatible with sparc:v8plus output /usr/bin/ld: sparc:v9 architecture of input file `./.libs/libsqlite3.a(insert.o)' is incompatible with sparc:v8plus output /usr/bin/ld: sparc:v9 architecture of input file `./.libs/libsqlite3.a(opcodes.o)' is incompatible with sparc:v8plus output /usr/bin/ld: sparc:v9 architecture of input file `./.libs/libsqlite3.a(os.o)' is incompatible with sparc:v8plus output /usr/bin/ld: sparc:v9 architecture of input file `./.libs/libsqlite3.a(pager.o)' is incompatible with sparc:v8plus output /usr/bin/ld: sparc:v9 architecture of input file `./.libs/libsqlite3.a(parse.o)' is incompatible with sparc:v8plus output /usr/bin/ld: sparc:v9 architecture of input file `./.libs/libsqlite3.a(pragma.o)' is incompatible with sparc:v8plus output /usr/bin/ld: sparc:v9 architecture of input file `./.libs/libsqlite3.a(select.o)' is incompatible with sparc:v8plus output /usr/bin/ld: sparc:v9 architecture of input file `./.libs/libsqlite3.a(vacuum.o)' is incompatible with sparc:v8plus output /usr/bin/ld: sparc:v9a architecture of input file `./.libs/libsqlite3.a(vdbe.o)' is incompatible with sparc:v8plus output /usr/bin/ld: sparc:v9 architecture of input file `./.libs/libsqlite3.a(alter.o)' is incompatible with sparc:v8plus output /usr/bin/ld: sparc:v9 architecture of input file `./.libs/libsqlite3.a(date.o)' is incompatible with sparc:v8plus output ./.libs/libsqlite3.a(printf.o): In function `et_getdigit': printf.c:(.text+0x144): undefined reference to `_Qp_qtoi' printf.c:(.text+0x168): undefined reference to `_Qp_itoq' printf.c:(.text+0x1a8): undefined reference to `_Qp_sub' printf.c:(.text+0x1f4): undefined reference to `_Qp_mul' ./.libs/libsqlite3.a(printf.o): In function `vxprintf': printf.c:(.text+0xd48): undefined reference to `_Qp_dtoq' printf.c:(.text+0xdcc): undefined reference to `_Qp_flt' printf.c:(.text+0xf14): undefined reference to `_Qp_dtoq' printf.c:(.text+0xf54): undefined reference to `_Qp_add' printf.c:(.text+0xfa0): undefined reference to `_Qp_fgt' printf.c:(.text+0x1014): undefined reference to `_Qp_mul' printf.c:(.text+0x1074): undefined reference to `_Qp_fge' printf.c:(.text+0x10f8): undefined reference to `_Qp_mul' printf.c:(.text+0x1164): undefined reference to `_Qp_fge' printf.c:(.text+0x11e8): undefined reference to `_Qp_mul' printf.c:(.text+0x1254): undefined reference to `_Qp_fge' printf.c:(.text+0x12d8): undefined reference to `_Qp_mul' printf.c:(.text+0x1344): undefined reference to `_Qp_flt' printf.c:(.text+0x13c8): undefined reference to `_Qp_mul' printf.c:(.text+0x1434): undefined reference to `_Qp_flt' printf.c:(.text+0x14f0): undefined reference to `_Qp_dtoq' printf.c:(.text+0x1530): undefined reference to `_Qp_add' printf.c:(.text+0x1584): undefined reference to `_Qp_fge' printf.c:(.text+0x15f0): undefined reference to `_Qp_mul' ./.libs/libsqlite3.a(util.o): In function `sqlite3AtoF': util.c:(.text+0x1078): undefined reference to `_Qp_mul' util.c:(.text+0x10ac): undefined reference to `_Qp_itoq' util.c:(.text+0x10e4): undefined reference to `_Qp_add' util.c:(.text+0x11c4): undefined reference to `_Qp_mul' util.c:(.text+0x11f8): undefined reference to `_Qp_itoq' util.c:(.text+0x1230): undefined reference to `_Qp_add' util.c:(.text+0x126c): undefined reference to `_Qp_mul' util.c:(.text+0x12d8): undefined reference to `_Qp_div' util.c:(.text+0x1474): undefined reference to `_Qp_mul' util.c:(.text+0x14d4): undefined reference to `_Qp_mul' util.c:(.text+0x1534): undefined reference to `_Qp_mul' util.c:(.text+0x1594): undefined reference to `_Qp_mul' util.c:(.text+0x15e0): undefined reference to `_Qp_div' util.c:(.text+0x1608): undefined reference to `_Qp_mul' util.c:(.text+0x164c): undefined reference to `_Qp_qtod' collect2: ld returned 1 exit status make[1]: *** [sqlite3] Error 1 make[1]: Leaving directory `/home/fs/freeswitch/libs/sqlite' make: *** [libs/sqlite/libsqlite3.la] Error 2
On Sat, Apr 9, 2011 at 7:40 PM, Giovanni Maruzzelli <gmaruzz@gmail.com>wrote:
Compiler options have nothing to do with libraries incompatibilities. Why don't you use the standard libraries given by your distro? Never heard someone had to compile ssl libs for FreeSWITCH. Also never heard someone used any compiler options on standard machines. FS is targeted toward 64bit OSes, most people use CentOS, Ubuntu and Debian. CentOS is by far the most used and the reference platform. On 64bit. That said, if you're trying to optimize it for a PIII, an EPIA 5000 or an ARM, or whatever is not a standard server class machine, yes you better know how to optimize :).
Well 'you told me so' Giovanni ;) It's finally built! I deleted the entire source directory, did a brand new git clone, bootstrap and the whole process with NO switches, flags or options given to 'configure' But the 'configure' etc did NOT take care of the fact that it's a 64-bit platform, proven by the following: $ file ./.libs/freeswitch ./.libs/freeswitch: ELF 32-bit MSB executable, SPARC32PLUS, V8+ Required, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped Now I have heard from people in the debian-sparc forum that in the case of debian port, sparc32 is in fact faster than sparc64 and as a result the current userland is actually 32-bit. If that applies to FS built as 32-bit in this environment to be faster or comparable in performance to 64-bit, then I'm golden. Else, I guess I have no other choice as I can't figure out how to build it and get past the ssl problem I was having with all those m64 flags!
Sorry, I had not understood you were trying to use sparc, I was writing as you were using standard Intel. No idea how to help with your experimentations. -giovanni On 4/11/11, A E [Gmail] <all.eforums@gmail.com> wrote:
On Sat, Apr 9, 2011 at 7:40 PM, Giovanni Maruzzelli <gmaruzz@gmail.com>wrote:
Compiler options have nothing to do with libraries incompatibilities. Why don't you use the standard libraries given by your distro? Never heard someone had to compile ssl libs for FreeSWITCH. Also never heard someone used any compiler options on standard machines. FS is targeted toward 64bit OSes, most people use CentOS, Ubuntu and Debian. CentOS is by far the most used and the reference platform. On 64bit. That said, if you're trying to optimize it for a PIII, an EPIA 5000 or an ARM, or whatever is not a standard server class machine, yes you better know how to optimize :).
Well 'you told me so' Giovanni ;)
It's finally built! I deleted the entire source directory, did a brand new git clone, bootstrap and the whole process with NO switches, flags or options given to 'configure'
But the 'configure' etc did NOT take care of the fact that it's a 64-bit platform, proven by the following:
$ file ./.libs/freeswitch ./.libs/freeswitch: ELF 32-bit MSB executable, SPARC32PLUS, V8+ Required, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
Now I have heard from people in the debian-sparc forum that in the case of debian port, sparc32 is in fact faster than sparc64 and as a result the current userland is actually 32-bit. If that applies to FS built as 32-bit in this environment to be faster or comparable in performance to 64-bit, then I'm golden. Else, I guess I have no other choice as I can't figure out how to build it and get past the ssl problem I was having with all those m64 flags!
-- Sent from my mobile device Sincerely, Giovanni Maruzzelli Cell : +39-347-2665618
On Mon, Apr 11, 2011 at 3:31 AM, Giovanni Maruzzelli <gmaruzz@celliax.org>wrote:
Sorry, I had not understood you were trying to use sparc, I was writing as you were using standard Intel. No idea how to help with your experimentations. -giovanni
No worries :) Well you were still right. Now I'm trying to fight through the core dump! I only wish this was "experimentation". I have half a rack full of SunFire V100 and V240 machines and I have to make this work on them as all intel based machines are too weak and the relatively powerful ones are already running critical windows software.
participants (4)
-
A E [Gmail]
-
curriegrad2004
-
Giovanni Maruzzelli
-
Giovanni Maruzzelli