From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17701 invoked by alias); 29 Dec 2004 08:36:28 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 17404 invoked from network); 29 Dec 2004 08:36:16 -0000 Received: from unknown (HELO pluton.ispras.ru) (83.149.199.253) by sourceware.org with SMTP; 29 Dec 2004 08:36:16 -0000 Received: (qmail 46292 invoked from network); 29 Dec 2004 08:37:02 -0000 Received: from unknown (HELO truba.ispras.ru) (83.149.198.41) by pluton.ispras.ru with SMTP; 29 Dec 2004 08:37:02 -0000 Received: from truba.ispras.ru (root@localhost) by truba.ispras.ru (8.13.1/8.13.1) with SMTP id iBT8TZaw030361 for ; Wed, 29 Dec 2004 11:29:35 +0300 Received: from ispserv.ispras.ru (ispserv [83.149.198.72]) by truba.ispras.ru (8.13.1/8.13.1) with ESMTP id iBT8TZv4030352; Wed, 29 Dec 2004 11:29:35 +0300 Received: from vault (vault.ispras.ru [83.149.198.168]) by ispserv.ispras.ru (8.12.8/8.12.8) with SMTP id iBT8YTDA026636; Wed, 29 Dec 2004 11:34:29 +0300 From: "Andrey Fomichev" To: "Andrey Fomichev" , Subject: RE: Strange behavior of my program linked with -static option Date: Wed, 29 Dec 2004 08:36:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit In-Reply-To: X-SpamTest-Info: Pass through X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [0125], KAS/Release SMTP-Filter Version 2.0.0 [0125], KAS/Release X-SW-Source: 2004-12/txt/msg00251.txt.bz2 Exactly the same problem exists with GCC 3.4.3! I have no idea what to do... > Hello! > > I have a pretty big program written in C++. It is complicated enough and > it uses C++ exceptions, pthreads and a set of 3-d party libraries. As far > as I compile it with dynamic linking with gcc libraries, I have > no problems. > It works fine. Problem arises when I add '-static' option to the linker. > The program is able to run, but it works in a very strange way. Signal > handlers do not handle signals. When I run it in background mode (the > program > then forks and the parent dies, but the child continues its execution) > I accidentally get 9 instances instead of 1. > > I have to say that I'm not very familiar with gcc and its huge set of > compiler > options, so it's possible that I missed something... But I suspect that it > may > be a problem with gcc itself (when I use dynamic linking everything works > fine!). > > I have looked around and found several links with similar problems (so I'm > not alone) > http://gcc.gnu.org/ml/gcc-help/2002-01/msg00199.html > http://www.monkey.org/openbsd/archive/bugs/0103/msg00129.html > > But examples at these links work fine for me because (I suspect) > I use other > version of gcc (3.2.2 comparing with 2.9x.x and 3.0.x). And note > that nobody > proposed a solution to the problem discussed... > > My environment: > gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) > Red Hat Linux 9, kernel 2.4.20-8 > > Flags: > CFLAGS = -DC_NO_PIC_NO_DLL -O3 -Wall -Wno-deprecated > $(INCLUDE_DIRECTIVES_GCC) -DEL_DEBUG=$(EL_DEBUG) > -fomit-frame-pointer -fno-s > trict-aliasing -Wno-unused -Wno-uninitialized -DHAVE_ALLOCA_H > -DC_STACK_GROW > S_DOWNWARD=1 -DC_USE_C_DEFAULTS -DC_EMBEDDED > CPPFLAGS = -O3 -Wall -Wno-deprecated $(INCLUDE_DIRECTIVES_GCC) > LFLAGS > > > = -O3 -L$(PP)/libs/pg -L$(PP)/libs/expat -L$(PP)/libs/chicken > -L$(PP)/libs/b > oost -static -lpccts -lpthread -lnsl -lcurses -lexpat -lchicken > -lstuffed-ch > icken -lsrfi-chicken -lboost_regex-gcc-1_31 > > > I hope somebody can guide me to the solution of the problem. Is there any > magic > with gcc options that might help? > > P.S. Now I'm trying to switch to the latest gcc release. I'll let you know > about results. > > Thanks in advance, > Andrey > >