headers
Peter Weilbacher | 24 May 2006 19:45

Linking with -lsocket

I am not sure if this is the group to also post GCC (as opposed to LIBC)
questions. If not, tell me where to go.

I was trying to build GnuPG 1.4.3 with the current GCC 3.3.5 the other 
day. following the instructions on Tobias Hürlimann's webpage
   http://www.tobiashuerlimann.de/software/GnuPG/?id=building&lang=en
When linking keyserver/gpgkeys_hkp.exe I get the message that several 
symbols cannot be found (see command and output below) because 
/lib/libsocket.a does not exist? Compiling while including 
$GCCDIR2/lib/libsocket.a on the command line works.

What could influence GCC to look for libsocket.a in /lib while it is 
really located in  m:/MOZCOMPILE/GCC335/lib? Why does it still find all 
the other libraries it needs for linking?
--

-- 
Greetings,                                                             ^
   Peter.

----------- output linking gpgkeys_hkp.exe ---------------
1. normal way

$ gcc -v -s -Zexe -Zmt -o gpgkeys_hkp.exe gpgkeys_hkp.o curl-shim.o 
ksutil.o -lsocket  -lbz2 -Le:/Tools ../cipher/libcipher.a 
./mpi/libmpi.a ../util/libutil.a  ../os2/gpgos2.a
Reading specs from 
m:/MozCompile/GCC335/lib/gcc-lib/i386-pc-os2-emx/3.3.5/specs
Configured with: D:/CODING/LIBC/0.6/src/gcc/configure --enable-clh 
--enable-threads=os2 --enable-shared=libgcc,bfd,opcodes --enable-nls 
--without-included-gettext 
--with-local-prefix=D:/CODING/LIBC/0.6/TOOLS/x86.os2/gcc/staged
(Continue reading)

Permalink | Reply | 2 comments |
headers
Knut St. Osmundsen | 26 May 2006 14:56
Favicon

Re: Linking with -lsocket

Peter Weilbacher wrote:
> I am not sure if this is the group to also post GCC (as opposed to LIBC)
> questions. If not, tell me where to go.

It's the right place.

> I was trying to build GnuPG 1.4.3 with the current GCC 3.3.5 the other 
> day. following the instructions on Tobias Hürlimann's webpage
>    http://www.tobiashuerlimann.de/software/GnuPG/?id=building&lang=en
> When linking keyserver/gpgkeys_hkp.exe I get the message that several 
> symbols cannot be found (see command and output below) because 
> /lib/libsocket.a does not exist? Compiling while including 
> $GCCDIR2/lib/libsocket.a on the command line works.
 >
> What could influence GCC to look for libsocket.a in /lib while it is 
> really located in  m:/MOZCOMPILE/GCC335/lib? Why does it still find all 
> the other libraries it needs for linking?

It's really located it m:/MOZCOMPILE/GCC335/lib/tcpipv4 with your 
mozilla setup. I think you are just mixing tcpip v4 and tcpip v4.1+ 
stuff. You should make sure you define TCPV40HDRS when compiling, or not 
include m:/MOZCOMPILE/GCC335/lib/tcpipv4 in the library paths 
(LIBRARY_PATH or LIBS(?)) when linking.

What's with this weird "/lib/libsocket.a" message, I don't really know. 
   You don't by any chance happen to have a /lib directory?

Kind Regards,
  knut
(Continue reading)

Permalink | Reply | 1 comment |
headers
Peter Weilbacher | 26 May 2006 21:14

Re: Linking with -lsocket

On Fri, 26 May 2006 12:56:43 UTC, "Knut St. Osmundsen" wrote:

> It's really located it m:/MOZCOMPILE/GCC335/lib/tcpipv4 with your 
> mozilla setup. I think you are just mixing tcpip v4 and tcpip v4.1+ 
> stuff. You should make sure you define TCPV40HDRS when compiling, or not 
> include m:/MOZCOMPILE/GCC335/lib/tcpipv4 in the library paths 
> (LIBRARY_PATH or LIBS(?)) when linking.

OK, removed that dir from LIBRARY_PATH and now it works. The resulting 
files are using TCPIP32.DLL now, as expected. Thanks for the hint.

Somehow the GnuPG configure is doing something bad, too, because it 
selects the double underscored versions of the TCP/IP functions, even 
though it could also use the ones without underscore. But OK, now that I
have it working I won't waste any more time on that...

> What's with this weird "/lib/libsocket.a" message, I don't really know. 
>    You don't by any chance happen to have a /lib directory?

No.
--

-- 
Greetings,                                                             ^
   Peter.
Permalink | Reply | 0 comments |
headers
Marcel Müller | 27 May 2006 00:56
Favicon

crash in threads with cerr-usage when cin is a pipe (#107)

Hi,

when I run the following program compiled with gcc 3.3.5 CSD1 and a 
input redirection I get SYS1808 with code 0005.

#include <iostream>
using namespace std;

void threadfunc(void*)
{  cerr << "in thread\n";
}

int main()
{  cerr << "before beginthread\n";
    _beginthread(threadfunc, NULL, 65536, NULL);
    cerr << "after beginthread\n";
    return 0;
}

D:\TEMP>gcc test.cpp -lstdc++

D:\TEMP>type test.cpp | test.exe
before beginthread
aifnt etrh rbeeagdi
ntSYS1808:
Der Prozeß wurde gestoppt. Der Softwarediagnosecode
(Fehlercode der Ausnahmebedingung) ist 0005.

Of course, the output to cerr is not serialized, but this does not 
matter. I removed the mutex only for simplicity.
(Continue reading)

Permalink | Reply | 2 comments |
headers
knut st. osmundsen | 29 May 2006 02:03
Favicon

Re: crash in threads with cerr-usage when cin is a pipe (#107)

Hi Marcel,

Thanks for the bugreport and excellent testcase. I've fixed the problem, 
see http://svn.netlabs.org/libc/ticket/109 for details.

I can send you a rebuilt libstdc++.a and libsupc++.a if you need the fix 
immediatly. It will of course be included in the 0.6.2 drop, but I've no 
idea it will be released (1-2 months at least).

Kind Regards,
  knut

Marcel Müller wrote:
> Hi,
> 
> when I run the following program compiled with gcc 3.3.5 CSD1 and a 
> input redirection I get SYS1808 with code 0005.
> 
> #include <iostream>
> using namespace std;
> 
> void threadfunc(void*)
> {  cerr << "in thread\n";
> }
> 
> int main()
> {  cerr << "before beginthread\n";
>    _beginthread(threadfunc, NULL, 65536, NULL);
>    cerr << "after beginthread\n";
>    return 0;
(Continue reading)

Permalink | Reply | 1 comment |

Gmane