FreeSWITCH

Stock solaris 'tr' under SXDE breaks the libedit build

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: Build System
  • Labels:
    None
  • Environment:
    Solaris 10 SXDE VMWare release with SunStudio 12
  • Platform:
    Solaris x86/sunstudio
  • CPU Info:
    unknown
  • FreeSWITCH GIT Revision:
    unknown
  • Reproduced with GIT HEAD?:
    unknown

Description


Problem: 'undefined symbol: ED_UNASSIGNED' during the libedit build.

Cause: Broken 'tr' in the default path on sol10

Temporary Fix: Prepend /usr/xpg4/bin to the PATH

Might be worth either putting this in the build docs, or defaulting to it on a solaris build?

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Mike Jerris added a comment -
funny, I downloaded 09/07 last night to setup my vm to test this stuff some more. I will have to take a look, but i should be able to do some autoconf magic to detect the right locations for this.
Show
Mike Jerris added a comment - funny, I downloaded 09/07 last night to setup my vm to test this stuff some more. I will have to take a look, but i should be able to do some autoconf magic to detect the right locations for this.
Hide
Permalink
Jay Fenton added a comment -
I was doing this via /usr/bin/make, could it be localised to that? I had to continue the build with gmake after it aborted later on... let me know, I'll re-run it after a clean and see if the problem re-occurs.
Show
Jay Fenton added a comment - I was doing this via /usr/bin/make, could it be localised to that? I had to continue the build with gmake after it aborted later on... let me know, I'll re-run it after a clean and see if the problem re-occurs.
Hide
Permalink
Michal Bielicki added a comment -
Try to use JDS-CBE. I will make a wiki entry how to make a correct build env unde solaris. jds-cbe solves a lot of those problems. I will also be embedding freeswitch in SFE

links:

JDS-CBE: http://www.opensolaris.org/os/project/jds/contributing/building/
SFE: http://pkgbuild.sourceforge.net/spec-files-extra/
Show
Michal Bielicki added a comment - Try to use JDS-CBE. I will make a wiki entry how to make a correct build env unde solaris. jds-cbe solves a lot of those problems. I will also be embedding freeswitch in SFE links: JDS-CBE: http://www.opensolaris.org/os/project/jds/contributing/building/ SFE: http://pkgbuild.sourceforge.net/spec-files-extra/
Hide
Permalink
Jay Fenton added a comment -
Sorry guys, I'm out of the country atm. Blocking on testing the JDS-CBE build due to not having a Solaris ISO with me for the prerequisite packages (nor the bandwidth to get it).

I'll get back to you on this by the 7th and let you know how it goes.
Show
Jay Fenton added a comment - Sorry guys, I'm out of the country atm. Blocking on testing the JDS-CBE build due to not having a Solaris ISO with me for the prerequisite packages (nor the bandwidth to get it). I'll get back to you on this by the 7th and let you know how it goes.
Hide
Permalink
Jay Fenton added a comment -

Okay, I give up on JDS-CBE. The 09/07 SXDE release, sol-nv-b70b-x86-dvd.iso doesn't include the SUNWsmbaS pre-requisite package for JDS-CBE.

Seems like an update for JDS-CBE is long overdue, so it's not really a viable "consistent build environment" if it can't keep up with a release from 09/07?

As the build worked once the xpg4 binaries were prepended to the path, I'm happy for Mike to close this once he's done his autoconf magic.
Show
Jay Fenton added a comment - Okay, I give up on JDS-CBE. The 09/07 SXDE release, sol-nv-b70b-x86-dvd.iso doesn't include the SUNWsmbaS pre-requisite package for JDS-CBE. Seems like an update for JDS-CBE is long overdue, so it's not really a viable "consistent build environment" if it can't keep up with a release from 09/07? As the build worked once the xpg4 binaries were prepended to the path, I'm happy for Mike to close this once he's done his autoconf magic.
Hide
Permalink
Mike Jerris added a comment -
I have looked at this a bit more. The tr usage is internal to libtool and there is not much I can do to force a path as it is not used based on a var. tr MUST be in your path in order for libtool to work properly. Correcting this would require a patch to libtool itself. The only workaround I can think of is to force the path as you have described below.
Show
Mike Jerris added a comment - I have looked at this a bit more. The tr usage is internal to libtool and there is not much I can do to force a path as it is not used based on a var. tr MUST be in your path in order for libtool to work properly. Correcting this would require a patch to libtool itself. The only workaround I can think of is to force the path as you have described below.
Hide
Permalink
Mike Jerris added a comment -
there is no good way to fix this in the build system as it is an issue internal to libtool and they don't use a var for tr. I added a note to the install docs.
Show
Mike Jerris added a comment - there is no good way to fix this in the build system as it is an issue internal to libtool and they don't use a var for tr. I added a note to the install docs.
Hide
Permalink
Michal Bielicki added a comment -
Fixing that with a different libedit version.
Please recheck
Show
Michal Bielicki added a comment - Fixing that with a different libedit version. Please recheck
Hide
Permalink
Stefan Knoblich added a comment -
That's not a libtool issue, it's cause by /usr/bin/tr not being able to cope with [:lower:] [:upper:] conversion in multibyte locale environments (= utf8):

-bash-3.2$ echo $LANG
de_DE.UTF-8

-bash-3.2$ echo foo | tr "[:lower:]" "[:upper:]"
Bad string

-bash-3.2$ echo foo | LANG=C tr "[:lower:]" "[:upper:]"
FOO


this breaks libedit's "sh makelist -fh vi.h emacs.h common.h > fcns.h" command which generates a nearly empty (compared to e.g. fedora)
fcns.h which normally contains those ED_ #defines.

the final fix in svn is to force LANG=C for the tr call: sort | LANG=C tr '[:lower:]' '[:upper:]' | $AWK

Show
Stefan Knoblich added a comment - That's not a libtool issue, it's cause by /usr/bin/tr not being able to cope with [:lower:] [:upper:] conversion in multibyte locale environments (= utf8): -bash-3.2$ echo $LANG de_DE.UTF-8 -bash-3.2$ echo foo | tr "[:lower:]" "[:upper:]" Bad string -bash-3.2$ echo foo | LANG=C tr "[:lower:]" "[:upper:]" FOO this breaks libedit's "sh makelist -fh vi.h emacs.h common.h > fcns.h" command which generates a nearly empty (compared to e.g. fedora) fcns.h which normally contains those ED_ #defines. the final fix in svn is to force LANG=C for the tr call: sort | LANG=C tr '[:lower:]' '[:upper:]' | $AWK
Hide
Permalink
Mike Jerris added a comment -
fixed in svn r8390
Show
Mike Jerris added a comment - fixed in svn r8390

People

  • Assignee:
    Jay Fenton
    Reporter:
    Jay Fenton
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: