Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: stdcxx-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <434C126C.10506@roguewave.com>
Date: Tue, 11 Oct 2005 13:28:44 -0600
From: Martin Sebor <sebor@roguewave.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050716
MIME-Version: 1.0
To: stdcxx-dev@incubator.apache.org
Subject: Re: [PATCH] ---[Cygwin] messages.cpp needs catopen, catgets etc
References: <200510082203.j98M30Gg012578@ms-smtp-02.rdc-nyc.rr.com>
In-Reply-To: <200510082203.j98M30Gg012578@ms-smtp-02.rdc-nyc.rr.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Lance Diduck wrote:
> This wasn't meant to be permanent. I just wanted to get everything at least
> buildable and tested, and then migrate to using gettext. 

Gotcha! I think the patch will work as a workaround but I agree that
we need a longer term solution. Here's how I think we might want to
handle this general type of problems:

1. Introduce a new make variable, say LDSOLIBS, that the stdcxx shared
library (but not necessarily any other component) should be linked with,
and define it to -lcatgets on CygWin.

2. Add -liconv to LDLIBS for CygWin.

3. When linking with an archive version of stdcxx, add the value of
LDSOLIBS to LDLIBS, probably in makefile.common.

Note that the above assumes there are only two types of components
that the stdcxx infrastructure is capable of building: (1) the stdcxx
library, and (2), stdcxx executables such as examples, utilities, and
tests. The last class of components are a little different since they
also link with the test suite driver. The test suite driver is
a special case since we only build an archive version of it,
regardless of whether the stdcxx library is built as an archive or
as a shared library.

Eventually, I would like to see this generalized so as to make it
possible to specify in a consistent way the sets of compiler and
linker options for (1) the stdcxx library, (2) other libraries that
depend on the stdcxx library, (3) executables that depend on any or
all of the libraries in (1) and (2).

One way of implementing this would be to add a suffix containing
the name of the relevant component to the name of each variable in
the sets currently defined in the config files like so:

For example, for CPPFLAGS we would have:
     CPPFLAGS.stdcxx   -- preprocessor options for the stdcxx library
     CPPFLAGS.rwtest   -- ... for the test suite driver library
     CPPFLAGS.util     -- ... for the locale utilities
     CPPFLAGS.examples -- ... for the example programs
     CPPFLAGS.tests    -- ... for the test programs

The makefile for each class of components would add the CPPFLAGS.*
variable with the appropriate suffix to CPPFLAGS (which could still
be defined to be a set of options common to all components, such as
-D_RWSTDDEBUG). This way, we could easily affect the set of compiler
or linker options for existing components or add new classes of
components to the infrastructure.

> But it appears that my account was finally created.

That's great news! Don't forget to set up your HOME including your
.forward file. See http://apache.org/dev/user-email.html.

Martin

> 
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com] 
> Sent: Thursday, October 06, 2005 11:57 AM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: [PATCH] ---[Cygwin] messages.cpp needs catopen, catgets etc
> 
> Lance Diduck wrote:
> 
>>OK this is it . Nothing fancy. This email has the same attachment (as a
>>test)
>>Index: gcc.config
>>===================================================================
>>--- gcc.config	(revision 291401)
>>+++ gcc.config	(working copy)
>>@@ -141,7 +141,9 @@
>>   MULTI_LDFLAGS_POSIX  = -mthreads
>> 
>>   # set the assembler file suffix to .s
>>-  AS_EXT = .s
>>+  AS_EXT = .s
>>+   LDLIBS += -liconv -lcatgets
> 
> 
> I don't think this is quite what we want. AFAIK, libiconv is only
> necessary to link the locale utilities but not for anything else.
> OTOH, libcatgets is only needed to link the library but not anything
> else.
> 
> I'm not sure we have a variable for these two sets of options right
> now but we probably should to accommodate this, especially to avoid
> introducing a dependency of the library on one that's not necessary
> (libiconv).
> 
> Martin
>