[WORKAROUND] www/seamonkey2 on CURRENT

Daniel Eischen deischen at freebsd.org
Sat Jan 29 19:36:17 UTC 2011

On Sat, 29 Jan 2011, Alexander Kabaev wrote:

> On Sat, 29 Jan 2011 13:21:44 -0500
> Alexander Kabaev <kabaev at gmail.com> wrote:
>> On Sat, 29 Jan 2011 13:02:24 -0500 (EST)
>> Daniel Eischen <deischen at freebsd.org> wrote:
>>> On Sat, 29 Jan 2011, Alexey Shuvaev wrote:
>>>> Hello!
>>>> It seems www/seamonkey2 is broken on CURRENT for at least 1 month
>>>> now [1]. Examining build log and reproducing it locally, the
>>>> problem is in the usage of libiconv in nsNativeCharsetUtils.cpp.
>>>> The linker fails to produce libxpcom_core.so although
>>>> -L/usr/local/lib and -liconv are specified [2]. Examining this
>>>> further I found that nsNativeCharsetUtils.o produced with [3]
>>>> fails to link with libiconv alone too [4] (note still unresolved
>>>> libiconv references). I'm not a compiler/linker guru and do not
>>>> understand what is happening here. As a workaroud I use the
>>>> attached patch which disables the usage of libiconv in
>>>> nsNativeCharsetUtils.cpp.
>>> Yes, I had this problem also on -current.  Does seamonkey build
>>> on recent 8.x?
>>> libxpcomio_s.a is a static library that has unresolved references
>>> to libiconv.  I guess I'd expect those references to be resolved
>>> with a later -L/usr/local/lib -liconv when building the shared
>>> library (libxpcom_core.so), but they are not.
>> My wild guess: seamonkey tries to hide symbols that are coming from
>> different .o file (this time one from libiconv.a) and that fails with
>> our toolchain.
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218
>> --
>> Alexander Kabaev
> Follow-up to myself: Nope, the fix to said bug appears in our compiler.
> Can you make amd64 version of nsNativeCharsetUtils.

My amd64 system is a little out of date, but I'll give it a try.
If it builds, I'll update to a recent -current and try rebuilding


More information about the freebsd-current mailing list