Re: compile error: /usr/bin/ld: cannot find -lAddressView

[Yen-Ju Chen]

On 6/26/07, Zhang Weiwu <zhangweiwu@realss.com> wrote:
> On Tue, 2007-06-26 at 22:34 -0700, Yen-Ju Chen wrote:
> >   I use Ubuntu/PPC and build GNUstep from source.
> >   I have never had this problem though.
>
> I do have an iBook running Ubuntu 7.04 and I wish/can/will get GNUStep
> running there by compile from source, because that way at least I am in
> the same environment as a gnustep developer or frequent user. The
> platform independent feature of gnustep systems are also IMHO a problem
> of gnustep systems, that is if what you want is truly a system working
> as problem-free as possible, you don't get a "recommended tested
> environment". Such "recommended, tested, stable, working environment" is
> a vital requirement for working people like me who wish to experiment or
> use GNUStep for work. And as long as people don't use it for daily work
> (kind of "work" independent of GNUStep development), GNUStep is going to
> keep being an opensource developer's toy. With people using it for real
> work is a real big difference that makes an opensource project
> outstanding and successful (that's my understanding as an End user).

 Sorry for the confusion. I am not saying the "recommended platform"
 is Ubuntu/PPC. I just mentioned it since you said you use Ubuntu.
 I believe most of the developers and probably users are using i386 machine
 or other Unix.
 Actually I believe not many people have PPC machine now.
 GNUstep is designed to be cross-platform.
 If it doesn't, it is a bug. You can report it and it will get fixed.
 I think the reason users get confused is because they don't know
 which applications are stable and which are not.
 I usually go to their websites to see when is its last release and
play it a little bit.
 You may notice that not many GNUstep application has a release
number beyond 1.0.
 It somehow indicates they are not finished yet.

> One idea or possibility of bringing GUNStep systems into working
> environment is to expand and further test the GNUStep live CD project to
> make it an installable distribution or a sub-project of a certain
> distribution (GNUStep-ubuntu?). Just if people think this can be a good
> idea and there are people willing to work on it.

 Well, it is nice to have, but I guess we don't have enough man power to do so.
 MidnightBSD has intention to use GNUstep as default desktop environment.
 (http://www.midnightbsd.org/about/index.html).
 Maybe you can take a look of it.
 It is not official released yet.

> Another question in case you have time and in case you are Chinese: did
> you try to use one of the opensource Chinese font in GNUStep or even
> further make some effort to make GNUStep-in-Chinese easy-to-install and
> usable? e.g. fonts like wenquanyi (or GNU Unifont) might be equipped
> with GNUStep to make I18N/L10N easier. Later when I have Ubuntu + PPC +
> GNUStep-compiled-from-source environment I'll try it myself when I got
> time.

 Again, you don't need to use PPC. Any i386 machine should work fine.
 I haven't try any new open-source Chinese font yet.
 (By the way, I need Traditional Chinese font).
 I do notice some of the fonts has wrong TTF matrix inside.
 Chinese font should have the same size for all glyphs.
 I think the biggest problem is not the font, but the text system and
input system.
 There is a SoC project to improve the text system this summer
 and I am pretty eager to see that.
 Another thing is that GNUstep has no font fallback mechanism as far
as I remember.
 So if the current font do not cover the glyphs, it will not show.
 It is annoying because it happens frequently in CJK environment.

 GNUstep is theoretical i18n/i10n ready.
 It uses USC2 internally and uses glyph for text rendering instead of
characters.
 Most of the problems are actually on the applications side
 where some developers assume one character map to one glyph.
 It usually generates exception say "out of range".
 But I have to say, the last time I tried years ago,
 basic input and output of Chinese has no major problem.

 Yen-Ju
>