From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25123 invoked by alias); 30 Jan 2004 19:18:19 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 24705 invoked from network); 30 Jan 2004 19:18:02 -0000 Received: from unknown (HELO tomts22-srv.bellnexxia.net) (209.226.175.184) by sources.redhat.com with SMTP; 30 Jan 2004 19:18:02 -0000 Received: from [192.168.0.3] ([65.93.110.52]) by tomts22-srv.bellnexxia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040130191800.YMHO26187.tomts22-srv.bellnexxia.net@[192.168.0.3]>; Fri, 30 Jan 2004 14:18:00 -0500 Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: gcc@gcc.gnu.org From: Kevin B. Hendricks Subject: Re: [Darwin] Patch, take 2: enable linkonce support for Darwin Date: Fri, 30 Jan 2004 19:27:00 -0000 To: Matt Austern X-SW-Source: 2004-01/txt/msg02274.txt.bz2 Hi Matt, A quick general question about this patch, the OpenOffice.org porters to MacOSX ran into serious problems with "coalesced" symbols that were not fixed until the most recent Apple version of GCC 3.3. The problem was most easily seen when linking in libstlport (STL) and finding that depending on the mix of the compiler optimization levels used we generated strange linker failures related to coalesced symbols not being present in each linker section (or only in the wrong section?) For example, rebuilding one library with -O0 -g for debugging purposes seemed to create problems when trying to link with other libraries that typically did not exist if everything was compiled at -O2 or higher. Typically the error message looked like the following: > ./STLport-4.5/lib/libstlport_gcc.dylib) > ld: huh.o illegal reference for -dynamic code (section difference > reference from section (__TEXT,__eh_frame) relocation entry (82) to > symbol: _STL::__node_alloc<(bool)1, (int)0>::allocate(unsigned long) > defined in dylib: ./STLport-4.5/lib/libstlport_gcc.dylib) The GNU Darwin compiler gcc 3.3 *never* seemed to have the same problems at that time that the Apple compiler had until the August gcc 3.3 update (but it did have problems with static objects in templates and other issues). Has this problem of mixing optimization levels and potentially missing related coalesced been tested in the new Darwin build with your patch in place to make sure the same problem that existed until recently in Apple's gcc 3.3 is not being introduced mistakenly into Darwin? I guess I am just being paranoid but that problem held up progress for us almost 2 years. :-) Now if we could just get the C++ static initialization to work reliably (I have a test case in case anyone is interested which shows static initialization of an object being re-entered in a single threaded app unless -bind_at_load or -single-module is used which horribly slows down the startup time of OpenOffice.org). Please see the following url if interested. http://porting.openoffice.org/servlets/ReadMsg?list=dev&msgId=916562 Thanks, Kevin