233234 - cannot build in Xcode (can't open library libJapaneseConverter.dylib)

Status: RESOLVED INVALID

(Camino Graveyard :: General, defect)

Description

[Hiro]

User-Agent:       
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7a) Gecko/20040205 Firebird/0.8.0+

The new build procedure using xcode was tried yesterday.
But the error of a summary occurs in the following portions.
　1.When a /Developer/Tools/Rez command is executed.(e.g. widget/src/cocoa)
  2.When a Darwin7.2.0_OPT.OBJ/shlibsign is executed.
    The shlibsign command is called from a sign.sh script by the
mozilla/security subordinate.

Error message:
 can't open library:  
/Developer/SDKs/MacOSX10.2.8.sdk/System/Library/CoreServices/Encodings/ 
libJapaneseConverter.dylib  (No such file or directory, errno = 2)

When a direct Rez command was executed in a terminal, it was completed normally.
(The shlibsign command was NG.)
And libJapaneseConverter.dylib exists only in
/System/Library/CoreServices/Encodings/.
Does build of camino by xcode become possible in the following machine environments?

Environment where it had built normally in PB until now:
  1.OS X 10.3 clean & install
  2.Xcode 1.0 install.
  3. Fink install
  4. Update of OS by the software update, and Xcode.
       OS X 10.3 --> 10.3.2
       Xcode1.0  --> Xcode1.1

Environment added in order to build using xcode:
  5. Install 10.2SDk from Xcode1.0CD.
  6. Create symlink /Developer/SDKs/MacOSX10.2.8.sdk to
/Developer/SDKs/MacOSX10.2.7.sdk
  7. Create symlink SharedMenusCocoa.framework.
     (The updated camino build procedure is followed)


Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Comment 1

[Hiro]

The error was avoidable by making symlink as follows.

  cd /Developer/SDKs/MacOSX10.2.8.sdk/System/Library
  sudo ln -s /System/Library/CoreServices .

I do not know whether this is the right method.
However, it may be necessary to add to a build procedure depending on the case.

Comment 2

[Mike Pinkerton (not reading bugmail)]

hrm, nobody i know has this problem. are you on a non-us system?

Comment 3

[Hiro]

The OS environment used now is Japan.
When OS was installed, the language of Japan and US was indispensable. The other
language was able to carry out arbitrary selection.

Only US and Japan installed me (indispensable item).
Probably, the language and US of their own country are indispensable in other
countries, and I think that it is at what can be chosen arbitrary except it.
And I think that default language environment is its own country.

Comment 4

[Hiro]

I was taught, when this error occurred, since the NEXT_ROOT variable was effective.

A setup which repeals NEXT_ROOT by the next Makefile may be necessity.
  xpfe/bootstrap/appleevents/Makefile.in
  widget/src/cocoa/Makefile.in 

I think that it probably adds like the next Makefile.
http://lxr.mozilla.org/mozilla/source/xpcom/typelib/xpidl/Makefile.in#82

It may be that there is possibly Makefile which must still be added to others.

Comment 5

[Josh Aas]

Can somebody other than crot0 confirm this? crot0: is this still a problem?

Comment 6

[Hiro]

(In reply to comment #5)
> Can somebody other than crot0 confirm this? crot0: is this still a problem?
yes, It still reproduces. 
OS and the developer tool have been updated to 10.3.8 and Xcode1.5+Nov2004 GCC
update respectively. 

The build error is as follows. 

../../../dist/bin/xpt_link _xpidlgen/widget_cocoa.xpt
_xpidlgen/nsIChangeManager.xpt _xpidlgen/nsIMenuCommandDispatcher.xpt
_xpidlgen/nsIDragHelperService.xpt 
/Users/sek/Documents/mozilla-current/test/mozilla/config/nsinstall -L
/Users/sek/Documents/mozilla-current/test/mozilla/widget/src/cocoa -m 644
_xpidlgen/widget_cocoa.xpt ../../../dist/gre/components
/Users/sek/Documents/mozilla-current/test/mozilla/config/nsinstall -L
/Users/sek/Documents/mozilla-current/test/mozilla/widget/src/cocoa -m 644
_xpidlgen/widget_cocoa.xpt ../../../dist/bin/components
/Developer/Tools/Rez -i /Developer/Headers/FlatCarbon -useDF nsMacWidget.r -o
../../../dist/bin/libwidget.rsrc
dyld: /Developer/Tools/Rez can't open library:
/Developer/SDKs/MacOSX10.2.8.sdk/System/Library/CoreServices/Encodings/libJapaneseConverter.dylib
 (No such file or directory, errno = 2)
make[5]: *** [../../../dist/bin/libwidget.rsrc] Trace/BPT trap
make[4]: *** [libs] Error 2
make[3]: *** [libs] Error 2
make[2]: *** [tier_9] Error 2
make[1]: *** [default] Error 2
make: *** [build] Error 2

Comment 7

[Hiro]

By the way, the following libraries are in /System/Library/CoreServices/Encodings/. 
Will be brought up of the same problem, except when the linguistic 
environment of OS is English?

$ls /System/Library/CoreServices/Encodings/
./                                      libLatin2Converter.dylib*
../                                     libLatin5Converter.dylib*
libArabicConverter.dylib*               libLatinSuppConverter.dylib*
libCyrillicConverter.dylib*             libSimplifiedChineseConverter.dylib*
libGreekConverter.dylib*                libSymbolConverter.dylib*
libHebrewConverter.dylib*               libThaiConverter.dylib*
libJapaneseConverter.dylib*             libTraditionalChineseConverter.dylib*
libKoreanConverter.dylib*               libVietnameseConverter.dylib*

Comment 8

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Is this still a problem?  If so, why is it unconfirmed?  It's obviously a build
issue, but I don't understand build issues :-(

Comment 9

[Hiro]

(In reply to comment #8)
> Is this still a problem?
Yes.
This problem exists for a long time. 
I think that it should change NEXT_ROOT ? when the command under the control of
perhaps /Developer/Tools/ is used in Makefile. 

Comment 10

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Mark, since you've been doing all of the awesome build-wrangling lately, could
you have a look at this bug, too, when you get a chance?  I think it's Camino's
oldest UNCO.

Comment 11

[Mark Mentovai]

I can confirm.  Simulate a Japanese environment by setting
__CF_USER_TEXT_ENCODING=0x1F6:1:14.

This is Apple's bug.  There's no reason Rez should be using NEXT_ROOT as a
runtime library search path, SDKs contain stub libraries only suitable for
linking.  It's fixed in the Rez that shipped with Xcode 2.1 and probably 2.0 as
well.

Given this and the fact that the bug apparently only affected one person in over
a year, I'm marking INVALID.  crot0, if you're not using Tiger, edit the two
Makefiles you mentioned in comment 4 so that they have a NEXT_ROOT= line. 
Alternatively, simulate a generic build environment by removing
__CF_USER_TEXT_ENCODING from the environment or setting it empty during a make.
 For example:

bash$ __CF_USER_TEXT_ENCODING= make -w -f client.mk