You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by Mark Brown <mb...@inbox.com> on 2007/03/02 07:15:11 UTC
Cygwin cannot find -lstd12d
Hi again,
Sorry about all the emails tonight. I'm sending them out as I run into things. Hopefully they'll be useful. After the library built all examples are now getting the same error. Looks like the Cygwin linker can't find the library even though it's there (I checked :)
$ make
gcc -c -I/home/mbrown/stdcxx/include/ansi -mthreads -D_RWSTD_USE_CONFIG -I/home/mbrown/stdcxx/include -I/home/mbrown/stdcxx-12d/include -I/home/mbrown/stdcxx/examples/include -pedantic -nostdinc++ -O2 -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align /home/mbrown/stdcxx/examples/manual/accumulate.cpp
(...lots of warnings about failed inlining...)
gcc accumulate.o -o accumulate -mthreads -L/home/mbrown/stdcxx-12d/lib -lstd12d -lsupc++ -lcatgets -liconv -lm
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot find -lstd12d
collect2: ld returned 1 exit status
make: *** [accumulate] Error 1
-- Mark
Re: Cygwin cannot find -lstd12d
Posted by Martin Sebor <se...@roguewave.com>.
Martin Sebor wrote:
> Mark Brown wrote:
[...]
>> $ make
>> gcc -c -I/home/mbrown/stdcxx/include/ansi -mthreads
>> -D_RWSTD_USE_CONFIG -I/home/mbrown/stdcxx/include
>> -I/home/mbrown/stdcxx-12d/include
>> -I/home/mbrown/stdcxx/examples/include -pedantic -nostdinc++ -O2 -W
>> -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long
>> -Wcast-align /home/mbrown/stdcxx/examples/manual/accumulate.cpp
>>
>> (...lots of warnings about failed inlining...)
>
> I'm guessing these are the same warnings we get with gcc 3.4.4
> on Linux (see below). I don't think we have an issue for them
> in Jira and we probably should. They make builds excessively
> noisy. I suspect the only way to deal with them is to disable
> them completely. IIRC, we looked into restructuring our code
> some time ago to help the inliner (or avoid trying to inline
> those that looked unreasonably big) but discovered it wasn't
> really feasible. I think the gcc maintainers must have realized
> the warnings weren't useful and removed them (or fixed the
> feature) in a later version of the compiler.
I was wrong about the inliner warnings having been removed
from the latest gcc. They're still there and can be seen in
the latest nightly build results with gcc 4.1.1, e.g.:
http://people.apache.org/~sebor/stdcxx/results/redhat_as-5.0-em64t-gcc-32b-4.1.1-8s-log.gz.txt
We need to do something about them, either clean them up or
remove the -Winline option from the command line.
Martin
Re: Cygwin cannot find -lstd12d
Posted by Martin Sebor <se...@roguewave.com>.
Mark Brown wrote:
> Hi again,
>
> Sorry about all the emails tonight. I'm sending them out as I run into things. Hopefully they'll be useful. After the library built all examples are now getting the same error. Looks like the Cygwin linker can't find the library even though it's there (I checked :)
That's odd. Please go ahead and open an issue for this as well.
>
> $ make
> gcc -c -I/home/mbrown/stdcxx/include/ansi -mthreads -D_RWSTD_USE_CONFIG -I/home/mbrown/stdcxx/include -I/home/mbrown/stdcxx-12d/include -I/home/mbrown/stdcxx/examples/include -pedantic -nostdinc++ -O2 -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align /home/mbrown/stdcxx/examples/manual/accumulate.cpp
>
> (...lots of warnings about failed inlining...)
I'm guessing these are the same warnings we get with gcc 3.4.4
on Linux (see below). I don't think we have an issue for them
in Jira and we probably should. They make builds excessively
noisy. I suspect the only way to deal with them is to disable
them completely. IIRC, we looked into restructuring our code
some time ago to help the inliner (or avoid trying to inline
those that looked unreasonably big) but discovered it wasn't
really feasible. I think the gcc maintainers must have realized
the warnings weren't useful and removed them (or fixed the
feature) in a later version of the compiler.
gmake: Entering directory `$(BUILDDIR)/examples'
gcc -c -I$(TOPDIR)/include/ansi -pthread -D_RWSTD_USE_CONFIG
-I$(TOPDIR)/include -I$(BUILDDIR)/include -I$(TOPDIR)/examples/include
-pedantic -nostdinc++ -O2 -W -Wall -Wcast-qual -Winline -Wshadow
-Wwrite-strings -Wno-long-long -Wcast-align
$(TOPDIR)/examples/manual/accumulate.cpp
In file included from $(TOPDIR)/examples/manual/accumulate.cpp:698:
$(TOPDIR)/include/vector: In member function `void std::vector<_TypeT,
_Allocator>::_C_insert_range(typename _Allocator::pointer, _FwdIter,
_FwdIter, std::forward_iterator_tag) [with _FwdIter = int*, _TypeT =
int, _Allocator = std::allocator<int>]':
$(TOPDIR)/include/vector:634: warning: inlining failed in call to 'void
std::vector<_TypeT, _Allocator>::swap(std::vector<_TypeT, _Allocator>&)
[with _TypeT = int, _Allocator = std::allocator<int>]': function not
considered for inlining
$(TOPDIR)/include/vector:654: warning: called from here
Martin
>
> gcc accumulate.o -o accumulate -mthreads -L/home/mbrown/stdcxx-12d/lib -lstd12d -lsupc++ -lcatgets -liconv -lm
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot find -lstd12d
> collect2: ld returned 1 exit status
> make: *** [accumulate] Error 1
>
>
> -- Mark
Re: [PATCH] RE: Cygwin cannot find -lstd12d
Posted by Martin Sebor <se...@roguewave.com>.
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:sebor@roguewave.com]
>> Sent: Tuesday, March 13, 2007 9:36 PM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: [PATCH] RE: Cygwin cannot find -lstd12d
>>
>> Farid Zaripov wrote:
>>>> -----Original Message-----
>>>> From: Martin Sebor [mailto:sebor@roguewave.com]
>>>> Sent: Monday, March 12, 2007 6:29 PM
>>>> To: stdcxx-dev@incubator.apache.org
>>>> Subject: Re: [PATCH] RE: Cygwin cannot find -lstd12d
>>>>
>> I have one fundamental issue with this new patch and that is
>> the introduction of the OSNAME variable and platform-specific
>> code into the makefiles. The reason why the OSNAME variable
>> isn't already there is because the makefiles are designed to
>> be platform-agnostic and as general as possible. So I would
>> like to try to find a way to express what we need to do using
>> a general-purpose mechanism (including introducing new
>> variable if necessary).
>
> I found that ld can link to shared library without the import library
> (but the extension of the shared library should be .dll or .dll.a).
> So we can leave the GNUmakefile.lib and GNUmakefile as is.
Okay, good. I'll wait for a new patch then.
>
>>> What else can be improved: the ld on Cygwin appends .exe
>> suffix to
>>> the built executable name if that name is not contain '.'.
>> As a result
>>> we have the /examples and /bin executables with .exe suffix, and
>>> /tests executables without that suffix.
>> As was noted yesterday, the periods in file names are the
>> (likely) cause of some problems. Is the missing .exe suffix a
>> problem when invoking the executables or are you simply
>> pointing out an inconsistency between the tests and the rest
>> of our executables?
>
> No problems with invoking, just the inconsistency.
Good. I agree it would be nice for the names to be consistent.
Could you create a low severity issue and copy your analysis
into it in case someone ever wonders why they're inconsistent?
Martin
RE: [PATCH] RE: Cygwin cannot find -lstd12d
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com]
> Sent: Tuesday, March 13, 2007 9:36 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: [PATCH] RE: Cygwin cannot find -lstd12d
>
> Farid Zaripov wrote:
> >> -----Original Message-----
> >> From: Martin Sebor [mailto:sebor@roguewave.com]
> >> Sent: Monday, March 12, 2007 6:29 PM
> >> To: stdcxx-dev@incubator.apache.org
> >> Subject: Re: [PATCH] RE: Cygwin cannot find -lstd12d
> >>
> I have one fundamental issue with this new patch and that is
> the introduction of the OSNAME variable and platform-specific
> code into the makefiles. The reason why the OSNAME variable
> isn't already there is because the makefiles are designed to
> be platform-agnostic and as general as possible. So I would
> like to try to find a way to express what we need to do using
> a general-purpose mechanism (including introducing new
> variable if necessary).
I found that ld can link to shared library without the import library
(but the extension of the shared library should be .dll or .dll.a).
So we can leave the GNUmakefile.lib and GNUmakefile as is.
> > What else can be improved: the ld on Cygwin appends .exe
> suffix to
> > the built executable name if that name is not contain '.'.
> As a result
> > we have the /examples and /bin executables with .exe suffix, and
> > /tests executables without that suffix.
>
> As was noted yesterday, the periods in file names are the
> (likely) cause of some problems. Is the missing .exe suffix a
> problem when invoking the executables or are you simply
> pointing out an inconsistency between the tests and the rest
> of our executables?
No problems with invoking, just the inconsistency.
Farid.
Re: [PATCH] RE: Cygwin cannot find -lstd12d
Posted by Martin Sebor <se...@roguewave.com>.
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:sebor@roguewave.com]
>> Sent: Monday, March 12, 2007 6:29 PM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: [PATCH] RE: Cygwin cannot find -lstd12d
>>
>> Martin Sebor wrote:
>> [...]
>>> If you've successfully tested your patch with at least a few of the
>>> stdcxx example programs please go ahead and commit it.
>>> We can deal with the suffix later.
>> Farid, what's the status of this patch?
>
> Here it is.
I have one fundamental issue with this new patch and that is
the introduction of the OSNAME variable and platform-specific
code into the makefiles. The reason why the OSNAME variable
isn't already there is because the makefiles are designed to
be platform-agnostic and as general as possible. So I would
like to try to find a way to express what we need to do using
a general-purpose mechanism (including introducing new
variable if necessary).
>
> What else can be improved: the ld on Cygwin appends .exe suffix to the
> built executable name if that
> name is not contain '.'. As a result we have the /examples and /bin
> executables with .exe suffix, and
> /tests executables without that suffix.
As was noted yesterday, the periods in file names are the
(likely) cause of some problems. Is the missing .exe suffix
a problem when invoking the executables or are you simply
pointing out an inconsistency between the tests and the
rest of our executables?
Martin
>
> ChangeLog:
> * gcc.config: Set SHARED_SUFFIX = .dll on Cygwin
> * GNUmakefile.lib: Added statements to build the import library
> instead of symbolic link on Cygwin
> * makefile.common: Corrected condition to get worked on Cygwin
> * makefile.rules: Added $(LIBDIR) to PATH environment variable to run
> examples and tests
> without copying the libstd.dll to the executable folder
> * GNUmakefile: Export $(OSNAME) variable to the makefile.in
>
> =================================
> Index: etc/config/gcc.config
> ===================================================================
> --- etc/config/gcc.config (revision 517637)
> +++ etc/config/gcc.config (working copy)
> @@ -184,6 +184,10 @@
> SHARED_SUFFIX = .dylib
> endif
>
> +ifneq ($(findstring CYGWIN,$(OSNAME)),)
> + SHARED_SUFFIX = .dll
> +endif
> +
> STATIC_CXXFLAGS =
> STATIC_CPPFLAGS =
> STATIC_LDFLAGS =
> Index: etc/config/GNUmakefile.lib
> ===================================================================
> --- etc/config/GNUmakefile.lib (revision 517637)
> +++ etc/config/GNUmakefile.lib (working copy)
> @@ -17,11 +17,22 @@
> # the name of the library to build (and in shared builds,
> # the name of the symbolic link pointing to it, for library
> # versioning)
> -LIBLINK := $(LIBNAME)
> +# on Cygwin LIBLINK is the name of the import library
> +ifeq ($(findstring CYGWIN,$(OSNAME)),)
> + LIBLINK := $(LIBNAME)
> +else
> + LIBLINK := $(LIBNAME).a
> +endif
>
> +# do not use LIBLINK as TARGET on Cygwin
> ifeq ($(findstring shared,$(BUILDMODE)),shared)
> - LIB := $(LIBLINK).$(LIBVER)
> - TARGET := $(LIB) $(LIBLINK)
> + ifeq ($(findstring CYGWIN,$(OSNAME)),)
> + LIB := $(LIBLINK).$(LIBVER)
> + TARGET := $(LIB) $(LIBLINK)
> + else
> + LIB := $(basename $(LIBNAME)).$(LIBVER)$(LIBSUFFIX)
> + TARGET := $(LIB)
> + endif
> else
> LIB := $(LIBLINK)
> TARGET := $(LIB)
> @@ -39,6 +50,11 @@
> ONE_REPOSITORY = 1
> include ../makefile.common
>
> +# generate import library on Cygwin
> +ifneq ($(findstring CYGWIN,$(OSNAME)),)
> + LDSOFLAGS += -Wl,--out-implib,$(LIBLINK)
> +endif
> +
> CXXFLAGS += $(PICFLAGS)
> LDFLAGS += $(LDSOFLAGS) $(MAPFLAGS) $(MAPFILE)
>
> Index: etc/config/makefile.common
> ===================================================================
> --- etc/config/makefile.common (revision 517637)
> +++ etc/config/makefile.common (working copy)
> @@ -126,7 +126,7 @@
>
> # link with the produced library and the math library
> # (take care not to try to link the library with itself)
> -ifeq ($(findstring $(LIBNAME),$(TARGET)),)
> +ifeq ($(findstring $(basename $(LIBNAME)),$(TARGET)),)
> LDFLAGS += -L$(LIBDIR)
> # set the GNU make variable LDLIBS to the names of the libraries
> # to link with (make puts $(LDLIBS) last on the link line in
> Index: etc/config/makefile.rules
> ===================================================================
> --- etc/config/makefile.rules (revision 517637)
> +++ etc/config/makefile.rules (working copy)
> @@ -110,7 +110,7 @@
> # subtests (the little tests the main test consists of)
> run runall run_all: $(BINDIR)/exec
> @(LD_LIBRARY_PATH=$$LD_LIBRARY_PATH:$(LIBDIR);
> \
> - PATH=$$PATH:.;
> \
> + PATH=$$PATH:$(LIBDIR):.;
> \
> TOPDIR=$(TOPDIR);
> \
> export LD_LIBRARY_PATH PATH TOPDIR;
> \
> ./run $(RUNFLAGS) $(RUNTARGET);
> \
> Index: GNUmakefile
> ===================================================================
> --- GNUmakefile (revision 517637)
> +++ GNUmakefile (working copy)
> @@ -612,6 +612,7 @@
> && echo "OMIT_EXM_SRCS = $(OMIT_EXM_SRCS)" >>
> $(MAKEFILE_IN) \
> && echo "OMIT_TST_SRCS = $(OMIT_TST_SRCS)" >>
> $(MAKEFILE_IN) \
> && echo "BUILDTAG = $(BUILDTAG)" >>
> $(MAKEFILE_IN) \
> + && echo "OSNAME = $(OSNAME)" >>
> $(MAKEFILE_IN) \
> && echo "PLATFORM = $(PLATFORM)" >>
> $(MAKEFILE_IN) \
> && echo "DEFAULT_SHROBJ = $(DEFAULT_SHROBJ)" >>
> $(MAKEFILE_IN) \
> && echo "CXX_REPOSITORY = $(CXX_REPOSITORY)" >>
> $(MAKEFILE_IN));
> =================================
>
>
> Farid.
Re: [PATCH] RE: Cygwin cannot find -lstd12d
Posted by Martin Sebor <se...@roguewave.com>.
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Andrew Black [mailto:ablack@roguewave.com]
>> Sent: Tuesday, March 13, 2007 9:44 PM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: [PATCH] RE: Cygwin cannot find -lstd12d
>>
>> I have concerns about the change to makefile.rules.
>> Including $(LIBDIR) in the PATH variable on all platforms
>> creates the potential for mishaps on other platforms, though
>> the probability of such mishaps is small.
>>
>> Could you try setting the RPATH makefile variable to
>> '-Wl,-rpath,' and see if that accomplishes the same result?
>> The logic chain used to set this variable for the GCC
>> compiler can be found around lines 135 through
>> 161 of the gcc.config file.
>
> I have tried to use -rpath option, but it doesn't work.
> The ld doesn't show any error's, but also has no effect.
My guess is that the Windows dynamic loader is too dumb
to support the equivalent of -rpath. The MSDN page on
the Dynamic-Link Library Search Order seems to confirm
this:
http://msdn2.microsoft.com/en-us/library/ms682586.aspx
I'm not sure if we should bother to look at Dynamic-Link
Library Redirection as a possible solution:
http://msdn2.microsoft.com/en-us/library/ms682600.aspx
Martin
RE: [PATCH] RE: Cygwin cannot find -lstd12d
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Andrew Black [mailto:ablack@roguewave.com]
> Sent: Tuesday, March 13, 2007 9:44 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: [PATCH] RE: Cygwin cannot find -lstd12d
>
> I have concerns about the change to makefile.rules.
> Including $(LIBDIR) in the PATH variable on all platforms
> creates the potential for mishaps on other platforms, though
> the probability of such mishaps is small.
>
> Could you try setting the RPATH makefile variable to
> '-Wl,-rpath,' and see if that accomplishes the same result?
> The logic chain used to set this variable for the GCC
> compiler can be found around lines 135 through
> 161 of the gcc.config file.
I have tried to use -rpath option, but it doesn't work.
The ld doesn't show any error's, but also has no effect.
Farid.
Re: [PATCH] RE: Cygwin cannot find -lstd12d
Posted by Andrew Black <ab...@roguewave.com>.
Greetings Farid
I have concerns about the change to makefile.rules. Including $(LIBDIR)
in the PATH variable on all platforms creates the potential for mishaps
on other platforms, though the probability of such mishaps is small.
Could you try setting the RPATH makefile variable to '-Wl,-rpath,' and
see if that accomplishes the same result? The logic chain used to set
this variable for the GCC compiler can be found around lines 135 through
161 of the gcc.config file.
--Andrew Black
Farid Zaripov wrote:
> Index: etc/config/makefile.rules
> ===================================================================
> --- etc/config/makefile.rules (revision 517637)
> +++ etc/config/makefile.rules (working copy)
> @@ -110,7 +110,7 @@
> # subtests (the little tests the main test consists of)
> run runall run_all: $(BINDIR)/exec
> @(LD_LIBRARY_PATH=$$LD_LIBRARY_PATH:$(LIBDIR);
> \
> - PATH=$$PATH:.;
> \
> + PATH=$$PATH:$(LIBDIR):.;
> \
> TOPDIR=$(TOPDIR);
> \
> export LD_LIBRARY_PATH PATH TOPDIR;
> \
> ./run $(RUNFLAGS) $(RUNTARGET);
> \
[PATCH] RE: Cygwin cannot find -lstd12d
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com]
> Sent: Monday, March 12, 2007 6:29 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: [PATCH] RE: Cygwin cannot find -lstd12d
>
> Martin Sebor wrote:
> [...]
> > If you've successfully tested your patch with at least a few of the
> > stdcxx example programs please go ahead and commit it.
> > We can deal with the suffix later.
>
> Farid, what's the status of this patch?
Here it is.
What else can be improved: the ld on Cygwin appends .exe suffix to the
built executable name if that
name is not contain '.'. As a result we have the /examples and /bin
executables with .exe suffix, and
/tests executables without that suffix.
ChangeLog:
* gcc.config: Set SHARED_SUFFIX = .dll on Cygwin
* GNUmakefile.lib: Added statements to build the import library
instead of symbolic link on Cygwin
* makefile.common: Corrected condition to get worked on Cygwin
* makefile.rules: Added $(LIBDIR) to PATH environment variable to run
examples and tests
without copying the libstd.dll to the executable folder
* GNUmakefile: Export $(OSNAME) variable to the makefile.in
=================================
Index: etc/config/gcc.config
===================================================================
--- etc/config/gcc.config (revision 517637)
+++ etc/config/gcc.config (working copy)
@@ -184,6 +184,10 @@
SHARED_SUFFIX = .dylib
endif
+ifneq ($(findstring CYGWIN,$(OSNAME)),)
+ SHARED_SUFFIX = .dll
+endif
+
STATIC_CXXFLAGS =
STATIC_CPPFLAGS =
STATIC_LDFLAGS =
Index: etc/config/GNUmakefile.lib
===================================================================
--- etc/config/GNUmakefile.lib (revision 517637)
+++ etc/config/GNUmakefile.lib (working copy)
@@ -17,11 +17,22 @@
# the name of the library to build (and in shared builds,
# the name of the symbolic link pointing to it, for library
# versioning)
-LIBLINK := $(LIBNAME)
+# on Cygwin LIBLINK is the name of the import library
+ifeq ($(findstring CYGWIN,$(OSNAME)),)
+ LIBLINK := $(LIBNAME)
+else
+ LIBLINK := $(LIBNAME).a
+endif
+# do not use LIBLINK as TARGET on Cygwin
ifeq ($(findstring shared,$(BUILDMODE)),shared)
- LIB := $(LIBLINK).$(LIBVER)
- TARGET := $(LIB) $(LIBLINK)
+ ifeq ($(findstring CYGWIN,$(OSNAME)),)
+ LIB := $(LIBLINK).$(LIBVER)
+ TARGET := $(LIB) $(LIBLINK)
+ else
+ LIB := $(basename $(LIBNAME)).$(LIBVER)$(LIBSUFFIX)
+ TARGET := $(LIB)
+ endif
else
LIB := $(LIBLINK)
TARGET := $(LIB)
@@ -39,6 +50,11 @@
ONE_REPOSITORY = 1
include ../makefile.common
+# generate import library on Cygwin
+ifneq ($(findstring CYGWIN,$(OSNAME)),)
+ LDSOFLAGS += -Wl,--out-implib,$(LIBLINK)
+endif
+
CXXFLAGS += $(PICFLAGS)
LDFLAGS += $(LDSOFLAGS) $(MAPFLAGS) $(MAPFILE)
Index: etc/config/makefile.common
===================================================================
--- etc/config/makefile.common (revision 517637)
+++ etc/config/makefile.common (working copy)
@@ -126,7 +126,7 @@
# link with the produced library and the math library
# (take care not to try to link the library with itself)
-ifeq ($(findstring $(LIBNAME),$(TARGET)),)
+ifeq ($(findstring $(basename $(LIBNAME)),$(TARGET)),)
LDFLAGS += -L$(LIBDIR)
# set the GNU make variable LDLIBS to the names of the libraries
# to link with (make puts $(LDLIBS) last on the link line in
Index: etc/config/makefile.rules
===================================================================
--- etc/config/makefile.rules (revision 517637)
+++ etc/config/makefile.rules (working copy)
@@ -110,7 +110,7 @@
# subtests (the little tests the main test consists of)
run runall run_all: $(BINDIR)/exec
@(LD_LIBRARY_PATH=$$LD_LIBRARY_PATH:$(LIBDIR);
\
- PATH=$$PATH:.;
\
+ PATH=$$PATH:$(LIBDIR):.;
\
TOPDIR=$(TOPDIR);
\
export LD_LIBRARY_PATH PATH TOPDIR;
\
./run $(RUNFLAGS) $(RUNTARGET);
\
Index: GNUmakefile
===================================================================
--- GNUmakefile (revision 517637)
+++ GNUmakefile (working copy)
@@ -612,6 +612,7 @@
&& echo "OMIT_EXM_SRCS = $(OMIT_EXM_SRCS)" >>
$(MAKEFILE_IN) \
&& echo "OMIT_TST_SRCS = $(OMIT_TST_SRCS)" >>
$(MAKEFILE_IN) \
&& echo "BUILDTAG = $(BUILDTAG)" >>
$(MAKEFILE_IN) \
+ && echo "OSNAME = $(OSNAME)" >>
$(MAKEFILE_IN) \
&& echo "PLATFORM = $(PLATFORM)" >>
$(MAKEFILE_IN) \
&& echo "DEFAULT_SHROBJ = $(DEFAULT_SHROBJ)" >>
$(MAKEFILE_IN) \
&& echo "CXX_REPOSITORY = $(CXX_REPOSITORY)" >>
$(MAKEFILE_IN));
=================================
Farid.
Re: [PATCH] RE: Cygwin cannot find -lstd12d
Posted by Martin Sebor <se...@roguewave.com>.
Martin Sebor wrote:
[...]
> If you've successfully tested your patch with at least a few
> of the stdcxx example programs please go ahead and commit it.
> We can deal with the suffix later.
Farid, what's the status of this patch?
Martin
>
> Martin
>
>>
>> The corrected patch:
>>
>> Index: GNUmakefile.lib
>> ===================================================================
>> --- GNUmakefile.lib (revision 514746)
>> +++ GNUmakefile.lib (working copy)
>> @@ -39,6 +39,11 @@
>> ONE_REPOSITORY = 1
>> include ../makefile.common
>>
>> +# generate import library on Cygwin
>> +#ifneq ($(findstring CYGWIN,$(OSNAME)),)
>> + LDSOFLAGS += -Wl,--out-implib,lib$(LIBBASE).a
>> +#endif
>> +
>> CXXFLAGS += $(PICFLAGS)
>> LDFLAGS += $(LDSOFLAGS) $(MAPFLAGS) $(MAPFILE)
>>
>>
>> Farid.
>
Re: [PATCH] RE: Cygwin cannot find -lstd12d
Posted by Martin Sebor <se...@roguewave.com>.
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:sebor@roguewave.com]
>> Sent: Tuesday, March 06, 2007 7:55 PM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: [PATCH] RE: Cygwin cannot find -lstd12d
>>
>>> But in this case using both variables have the same
>> effect because
>>> the linker used only when shared library built.
>> Okay, so --out-implib is only needed/allowed when creating
>> the library. http://www.mingw.org/docs.shtml has an example
>> of how to create a shared library on MinGW. It uses the .dll
>> suffix rather than .so for the name of the library. We have
>> .so. Should the name of our library be changed to .dll or
>> does it matter?
>
> It doesn't' matter. Dll is just an extension of the file.
I thought Windows understands the .dll suffix as meaning
something special. Just like it does .exe and, AFAIK, will
refuse to execute files with no extension (as silly as that
is).
>
>> (I'm sure it would matter if the user wanted
>> to link the shared library in a program using MSVC.)
>
> In my opinion it is bad thing to link a program with library built on
> Cygwin
> using MSVC. The config.h files are different.
You're right, it could be risky and hard to get right. But
it is possible to do nonetheless (for example, by exposing
a C API to a library implemented in C++).
Looking through the lib/ directories in a Cygwin installation
I see .a files and .dll.a files, and also a few .la files, but
no .so's. We should probably follow their example and give our
shared library a suffix that corresponds to the shared library
suffix Cygwin uses. I'm guessing it's .dll.a?
> And also the library,
> build on
> cygwin, depends on cygwin1.dll and that library (size 1.8Mb) should be
> distributed with the program.
True.
Martin
RE: [PATCH] RE: Cygwin cannot find -lstd12d
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com]
> Sent: Tuesday, March 06, 2007 7:55 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: [PATCH] RE: Cygwin cannot find -lstd12d
>
> > But in this case using both variables have the same
> effect because
> > the linker used only when shared library built.
>
> Okay, so --out-implib is only needed/allowed when creating
> the library. http://www.mingw.org/docs.shtml has an example
> of how to create a shared library on MinGW. It uses the .dll
> suffix rather than .so for the name of the library. We have
> .so. Should the name of our library be changed to .dll or
> does it matter?
It doesn't' matter. Dll is just an extension of the file.
> (I'm sure it would matter if the user wanted
> to link the shared library in a program using MSVC.)
In my opinion it is bad thing to link a program with library built on
Cygwin
using MSVC. The config.h files are different. And also the library,
build on
cygwin, depends on cygwin1.dll and that library (size 1.8Mb) should be
distributed with the program.
Farid.
Re: [PATCH] RE: Cygwin cannot find -lstd12d
Posted by Martin Sebor <se...@roguewave.com>.
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:sebor@roguewave.com]
>> Sent: Tuesday, March 06, 2007 7:23 PM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: [PATCH] RE: Cygwin cannot find -lstd12d
>>
>>> +# generate import library on Cygwin
>>> +#ifneq ($(findstring CYGWIN,$(OSNAME)),)
>>> + LDFLAGS += -Wl,--out-implib,lib$(LIBBASE).a #endif
>> Should this be LDFLAGS (linker flags used when linking
>> programs with the library) or LDSOFLAGS (linker flags used
>> only when linking a shared library)?
>
> Yes, using the LDSOFLAGS is more correctly.
>
> But in this case using both variables have the same effect because the
> linker used only when shared library built.
Okay, so --out-implib is only needed/allowed when creating
the library. http://www.mingw.org/docs.shtml has an example
of how to create a shared library on MinGW. It uses the .dll
suffix rather than .so for the name of the library. We have
.so. Should the name of our library be changed to .dll or
does it matter? (I'm sure it would matter if the user wanted
to link the shared library in a program using MSVC.)
If you've successfully tested your patch with at least a few
of the stdcxx example programs please go ahead and commit it.
We can deal with the suffix later.
Martin
>
> The corrected patch:
>
> Index: GNUmakefile.lib
> ===================================================================
> --- GNUmakefile.lib (revision 514746)
> +++ GNUmakefile.lib (working copy)
> @@ -39,6 +39,11 @@
> ONE_REPOSITORY = 1
> include ../makefile.common
>
> +# generate import library on Cygwin
> +#ifneq ($(findstring CYGWIN,$(OSNAME)),)
> + LDSOFLAGS += -Wl,--out-implib,lib$(LIBBASE).a
> +#endif
> +
> CXXFLAGS += $(PICFLAGS)
> LDFLAGS += $(LDSOFLAGS) $(MAPFLAGS) $(MAPFILE)
>
>
> Farid.
RE: [PATCH] RE: Cygwin cannot find -lstd12d
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com]
> Sent: Tuesday, March 06, 2007 7:23 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: [PATCH] RE: Cygwin cannot find -lstd12d
>
> > +# generate import library on Cygwin
> > +#ifneq ($(findstring CYGWIN,$(OSNAME)),)
> > + LDFLAGS += -Wl,--out-implib,lib$(LIBBASE).a #endif
>
> Should this be LDFLAGS (linker flags used when linking
> programs with the library) or LDSOFLAGS (linker flags used
> only when linking a shared library)?
Yes, using the LDSOFLAGS is more correctly.
But in this case using both variables have the same effect because the
linker used only when shared library built.
The corrected patch:
Index: GNUmakefile.lib
===================================================================
--- GNUmakefile.lib (revision 514746)
+++ GNUmakefile.lib (working copy)
@@ -39,6 +39,11 @@
ONE_REPOSITORY = 1
include ../makefile.common
+# generate import library on Cygwin
+#ifneq ($(findstring CYGWIN,$(OSNAME)),)
+ LDSOFLAGS += -Wl,--out-implib,lib$(LIBBASE).a
+#endif
+
CXXFLAGS += $(PICFLAGS)
LDFLAGS += $(LDSOFLAGS) $(MAPFLAGS) $(MAPFILE)
Farid.
Re: [PATCH] RE: Cygwin cannot find -lstd12d
Posted by Martin Sebor <se...@roguewave.com>.
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:sebor@roguewave.com]
>> Sent: Tuesday, March 06, 2007 5:55 PM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: Cygwin cannot find -lstd12d
>>
>>> There exist libstd12d.so which is DLL file, but linker
>> requires the
>>> libstd12d.a file (import library).
>> So how do we create it and how is it different from an
>> ordinary archive library?
>
> We need to use an additional linker parameter --out-implib.
I see.
> The proposed patch:
>
> Index: config/GNUmakefile.lib
> ===================================================================
> --- config/GNUmakefile.lib (revision 514746)
> +++ config/GNUmakefile.lib (working copy)
> @@ -42,6 +42,11 @@
> CXXFLAGS += $(PICFLAGS)
> LDFLAGS += $(LDSOFLAGS) $(MAPFLAGS) $(MAPFILE)
>
> +# generate import library on Cygwin
> +#ifneq ($(findstring CYGWIN,$(OSNAME)),)
> + LDFLAGS += -Wl,--out-implib,lib$(LIBBASE).a
> +#endif
Should this be LDFLAGS (linker flags used when linking programs
with the library) or LDSOFLAGS (linker flags used only when
linking a shared library)?
Martin
> +
> # OBJS += $(shell [ -d ./cxx_repository/ ] && echo
> ./cxx_repository/*.o)
>
> # For AIX 5.1 xlC 5.0.2.0
>
> Farid.
[PATCH] RE: Cygwin cannot find -lstd12d
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com]
> Sent: Tuesday, March 06, 2007 5:55 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: Cygwin cannot find -lstd12d
>
> > There exist libstd12d.so which is DLL file, but linker
> requires the
> > libstd12d.a file (import library).
>
> So how do we create it and how is it different from an
> ordinary archive library?
We need to use an additional linker parameter --out-implib.
The proposed patch:
Index: config/GNUmakefile.lib
===================================================================
--- config/GNUmakefile.lib (revision 514746)
+++ config/GNUmakefile.lib (working copy)
@@ -42,6 +42,11 @@
CXXFLAGS += $(PICFLAGS)
LDFLAGS += $(LDSOFLAGS) $(MAPFLAGS) $(MAPFILE)
+# generate import library on Cygwin
+#ifneq ($(findstring CYGWIN,$(OSNAME)),)
+ LDFLAGS += -Wl,--out-implib,lib$(LIBBASE).a
+#endif
+
# OBJS += $(shell [ -d ./cxx_repository/ ] && echo
./cxx_repository/*.o)
# For AIX 5.1 xlC 5.0.2.0
Farid.
Re: Cygwin cannot find -lstd12d
Posted by Martin Sebor <se...@roguewave.com>.
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Mark Brown [mailto:mbrown@inbox.com]
>> Sent: Friday, March 02, 2007 8:15 AM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Cygwin cannot find -lstd12d
>>
>> Sorry about all the emails tonight. I'm sending them out as I
>> run into things. Hopefully they'll be useful. After the
>> library built all examples are now getting the same error.
>> Looks like the Cygwin linker can't find the library even
>> though it's there (I checked :)
>
> There exist libstd12d.so which is DLL file, but linker requires
> the libstd12d.a file (import library).
So how do we create it and how is it different from an ordinary
archive library?
Martin
RE: Cygwin cannot find -lstd12d
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Mark Brown [mailto:mbrown@inbox.com]
> Sent: Friday, March 02, 2007 8:15 AM
> To: stdcxx-dev@incubator.apache.org
> Subject: Cygwin cannot find -lstd12d
>
> Sorry about all the emails tonight. I'm sending them out as I
> run into things. Hopefully they'll be useful. After the
> library built all examples are now getting the same error.
> Looks like the Cygwin linker can't find the library even
> though it's there (I checked :)
There exist libstd12d.so which is DLL file, but linker requires
the libstd12d.a file (import library).
>
> $ make
> gcc -c -I/home/mbrown/stdcxx/include/ansi -mthreads
> -D_RWSTD_USE_CONFIG -I/home/mbrown/stdcxx/include
> -I/home/mbrown/stdcxx-12d/include
> -I/home/mbrown/stdcxx/examples/include -pedantic -nostdinc++
> -O2 -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings
> -Wno-long-long -Wcast-align
> /home/mbrown/stdcxx/examples/manual/accumulate.cpp
>
> (...lots of warnings about failed inlining...)
>
> gcc accumulate.o -o accumulate -mthreads
> -L/home/mbrown/stdcxx-12d/lib -lstd12d -lsupc++ -lcatgets -liconv -lm
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/b
> in/ld: cannot find -lstd12d
> collect2: ld returned 1 exit status
> make: *** [accumulate] Error 1
Farid.