Re: gcc 3.2 stringwchar_t link problem
Hi there,
See my post few weeks ago (29/10/2002)
subject : conflicting types for `typedef struct mbstate_t`(was link troubles
with wcslen)
also the one from zhang le on 27/10/2002
missing wcsncmp,wcscpy,wcsncpy and more...
or a search in the archives on wcslen
no one on the list acknowledged the pb (cfg ?) and i noticed that gcc-3.2-2
probably solved issue 2) of my post because it had the following comment
(msg [ANNOUNCEMENT] Updated: gcc-3.2-2 10/11/2002):
'However, the only noticeable change from the last release was an attempt to
correctly define mbstate_t.'
I'm positive that wcslen is in newlib but i'm not sure for
wcsncmp,wcscpy,wcsncpy as i didn't needed them a that time.
Xavier
Nigel Stewart Fiona Smith [EMAIL PROTECTED] a écrit dans le message
news: [EMAIL PROTECTED]
Hello all,
Having happily upgraded my Cygwin to include gcc 3.2, I've
encountered a show-stopper: The linker can't resolve symbols
involving wide C++ strings. Here is an example:
#include string
#include iostream
using namespace std;
int main(int argc,char *argv[])
{
std::stringwchar_t test;
}
-
$ g++ test.cpp
/cygdrive/c/DOCUME~1/nigels/LOCALS~1/Temp/ccHP4AMl.o(.text+0x25):test.cpp:
undefined reference to `std::basic_stringwch
ar_t, std::char_traitswchar_t, std::allocatorwchar_t
::basic_string[in-charge]()'
/cygdrive/c/DOCUME~1/nigels/LOCALS~1/Temp/ccHP4AMl.o(.text+0x30):test.cpp:
undefined reference to `std::basic_stringwch
ar_t, std::char_traitswchar_t, std::allocatorwchar_t
::~basic_string [in-charge]()'
collect2: ld returned 1 exit status
---
Any hints, suggestions, or duh-read-the FAQ responses, appreciated.
Note that the following compiles links:
int main(int argc,char *argv[])
{
std::stringdouble test;
}
$ gcc -v
Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/3.2/specs
Configured with: /netrel/src/gcc-3.2-3/configure
--enable-languages=c,c++,f77,java --enable-libgcj --enable-threads=posi
x --with-system-zlib --enable-nls --without-included-gettext
--enable-interpreter --disable-sjlj-exceptions --disable-ve
rsion-specific-runtime-libs --enable-shared --build=i686-pc-linux
--host=i686-pc-cygwin --target=i686-pc-cygwin --enable
-haifa --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc
--libdir=/usr/lib --includedir=/nonexistent/include --libexecd
ir=/usr/sbin
Thread model: posix
gcc version 3.2 20020927 (prerelease)
Cheers,
Nigel Stewart
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: compilng problems, wcslen and langinfo
Hi there Arno Waschk [EMAIL PROTECTED] a écrit dans le message news: [EMAIL PROTECTED] Dear list, Trying to compile wxGTK I am stuck.. What might here be going wrong? I thought langinfo and wcslen are supported (and configure thinks that too) and the wcslen error looks strange...? Am I missing something like a library? Can I help you with further information? Have a look at the message i wrote on th 29/10 : conflicting types for `typedef struct mbstate_t`(was link troubles with wcslen) it should solve at least the wcslen pb. After days of head bashing i managed to get wxWindows compile as a dll under cygwin the trick was mainly (after the wcslen pb) to add the compile option -Wl,--export-all-symbols in the building of the dll (g++ -shared ) For reasons i still can't explain some symbols are not exported in the .dll.a file i think it is a bug in dlltool but i can't get a small example to reproduce the problem this weekend will be for wxPython... Xavier -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: problem with dlltools / gcc -shared
Arno Waschk [EMAIL PROTECTED] a écrit dans le message news: [EMAIL PROTECTED] Am 29.10.2002 13:08:00, schrieb Xavier [EMAIL PROTECTED]: Hi there I try to compile a dll that exports 17000+ symbols during the creation of the .lib archive it creates those temporary .o files but it looks like it goes over the allowed number of files in the same directory or somethings around thoses lines (the / tree is on an NTFS partition) dlltool -d wxmsw233.def -l libwxmsw233.dll.a dlltool: bfd_open failure while opening stub file : ds10732.o ls -l | wc -l 17041 gcc -shared generates a core dump in this particular case I had something similar with that project. If I remember correctly, I was helped by using ld (binutils) from fresh CVS... But this never happened here with older ld on other platform! Arno I just did that and it worked just fine (fresh CVS binutils) Thanks -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
conflicting types for `typedef struct mbstate_t`(was link troubles with wcslen)
Hi there It seems there is a pb in some include files in cygwin1.3.13/1.3.14+gcc3.2 1) first of all /usr/include/wchar.h lacks of _BEGIN_STD_C ... _END_STD_C in function declarations. (same goes for wctypes.h) adding them solved the link problem i had with 'wcslen' in previous post (thanks to Shankar for the pointer) 2) including cwchar and wchar.h generates a conflicting type for struct mbstate_t because it is defined both in sys/_types.h included from wchar.h and cwchar I found a way to solve thoses pbs but i'm not sure this is the right way: added the _BEGIN_STD_C / _END_STD_C in wchar.h and wctypes.h modified /usr/include/c++/3.2/i686-pc-cygwin/bits/c++config.h the following way: // line 115 added #define _GLIBCPP_HAVE_MBSTATE_T 1 // line 824 added #define _GLIBCPP_HAVE_WCHAR_H 1 // line 828 added #define _GLIBCPP_HAVE_WCTYPE_H 1 there is one more flag i didn't set but still wonder whether or not i should do it (line 114) // Define if code specialized for wchar_t should be used. /* #undef _GLIBCPP_USE_WCHAR_T */ System used : /home uname -a CYGWIN_NT-5.0 TEMPO7 1.3.13(0.62/3/2) 2002-10-13 23:15 i686 unknown (same pbs with a 1.3.14-1) /home gcc -v Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/3.2/specs Configured with: /netrel/src/gcc-3.2-1/configure --enable-languages=c,c++,f77,ja va --enable-libgcj --enable-threads=posix --with-system-zlib --enable-nls -- with out-included-gettext --enable-interpreter --disable-sjlj-exceptions --disabl e-ve rsion-specific-runtime-libs --enable-shared --build=i686-pc-linux --host=i68 6-pc -cygwin --target=i686-pc-cygwin --enable-haifa --prefix=/usr --exec-prefix=/ usr --sysconfdir=/etc --libdir=/usr/lib --includedir=/nonexistent/include --libe xecd ir=/usr/sbin Thread model: posix gcc version 3.2 20020818 (prerelease) Xavier -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
just compiled .exe will crash before first instruction
Hi,
I'm porting a large application from linux to cygwin.
The app is made of several static libraries and an exe that link to all =
of them.
the build process goes smoothly and the libs/exe are built with no =
trouble.
But the if i try to run the new exe i get (sory in french):
VOTRE APPLICATION A PROVOQUE UNE CORRUPTION MEMOIRE
AX :
Aborted (core dumped)
(something like YOUR APP CORRUPTED THE MEMORY)
if i try the same under gdb and put a breakpoint in main :
This GDB was configured as i686-pc-cygwin...
(gdb) b main
Breakpoint 1 at 0x401ef4: file tg_main_src/tg_mainStartup.cxx, line 49.
(gdb) r
Starting program: /TANGO/tg_disp_03.00/bin/cygwin/tg_disp.exe
Breakpoint 1, main (argc=3D1, argv=3D0xa011870)
at tg_main_src/tg_mainStartup.cxx:49
49 {
Current language: auto; currently c++
(gdb) s
VOTRE APPLICATION A PROVOQUE UNE CORRUPTION MEMOIRE
AX :
187 [sig] tg_disp 1184 open_stackdumpfile: Dumping stack trace to =
tg_disp.ex
e.stackdump
Program exited with code 0303000.
So it looks like i can't event go to the first line of real code...
PS : a simple hello_world.c compiles and runs OK, same for a =
hello_world.cxx
the compile options are :
for each .o of static libraries=20
g++ -g -D__unix__ -Wall -Wmissing-prototypes -pipe -D_THREAD_SAFE =
-I./include -c tg_bus/divers.cxx -o tmp/cygwin/divers.o
ar -rc lib/cygwin/static_lib.a tmp/cygwin/divers.o
for exe
g++ -g -D__unix__ -Wall -Wmissing-prototypes -pipe -D_THREAD_SAFE -o =
tg_disp tg_disp.cxx -L./lib/cygwin -L/usr/local/lib -Lstaticlibs -ltgsys =
-ltgloaddic -ltgbus -ltgdisp
What am i doint wrong ?
stack trace :
Stack trace:
Frame Function Args
0022F0D4 77E73B5B (, 78499DA7, 0022F174, 6105A669)
0022F124 6105A99E (, 0056BF2C, FFFC, 005A765C)
0022F164 61058105 (04A0, 0006, , 00560400)
0022F1A4 61058342 (04A0, 0006, 0022F204, 61058789)
0022F1C4 610581CA (0006, , 0022F204, 61058754)
0022F204 6105879F (0022F2F8, 0002, 0022F34C, 0022F234)
0022F224 00402DD7 (, 0055B55D, FFA8, 005A6CFC)
0022F254 0056C7DD (0022F350, , 0022F2A4, 0055B98E)
0022F2A4 0056B555 (0022F2F4, 0002, , 0040DBAF)
0022F384 0040DCE1 (006E32C0, , , )
0022F6E4 0040C21C (006E32C0, , , )
0022F704 00487E85 (0001, , 0022F7CC, 77E82D15)
0022F724 00488295 (0004, 610A0368, 04A0, 04FC)
0022F744 61002A7F (005C65A4, , 0022F764, 00566C79)
0022F764 6100431E (0004, 610A0368, , 0022F7B4)
0022FD64 00401F0A (0001, 0A011870, 0A010278, )
End of stack trace (more stack frames may be present)
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
