X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f X-Recipient: djgpp AT delorie DOT com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=kvncw19TiRPTiJ4Y+VqM/c7g3Qn4oa56md56dTwsZRo=; b=pesF4pj4vvkKgbthw3JFC8TNbapH5OgzApEupOncDm7YYF0DTm0E5ia/39oUUTmgOa pEVRUlk6nlReAG0fzPP+6d2urSXNDSw35c0Ssr/GGomunVx49eG8q03uve99lCjlal5r /l/VwspeYcPbgajCjjMauywjSjTnzPAXvHi8E= MIME-Version: 1.0 In-Reply-To: <83k47tc9u2.fsf@gnu.org> References: <4ce51722-c2fd-4fe0-8cb9-ebae498c3271 AT r1g2000yqm DOT googlegroups DOT com> <83k47tc9u2 DOT fsf AT gnu DOT org> Date: Tue, 25 Oct 2011 19:33:13 +0300 Message-ID: Subject: Re: _rdtsc(void) inline function in time.h - cause problem with multiple definition during linking From: Ozkan Sezer To: djgpp AT delorie DOT com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id p9PGtdto019706 Reply-To: djgpp AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Tue, Oct 25, 2011 at 7:30 PM, Eli Zaretskii wrote: >> From: RayeR >> Date: Tue, 25 Oct 2011 04:02:09 -0700 (PDT) >> >> during compiling large sources I run into troubles with multiple >> _rdtsc(void) definition during linking. The problem is caused when in >> 1st stage is compiled a library that includes time.h and then in 2nd >> stage is compiled main app that also includes time.h Because there is >> _rdtsc() code already in library linker got confused what to use. >> >> Do you think it should be fixed DJGPP time.h header to redefine >> >> extern __inline__ unsigned long long >> _rdtsc(void) >> { >>   unsigned long long result; >>   __asm__ __volatile__ ("rdtsc" : "=A"(result) ); >>   return result; >> } >> >> to static? > > Can you show the error messages you get? > > It is strange that you should get any errors at all: an inline > function is like a macro, it disappears without a trace in the > compiled object code, so the linker should not complain, because > there's no symbol corresponding to the function for it to see any > multiple definitions.  There simply should not be any definition at > all. > > Did you perhaps disable inlining, or compiled with some headers that > define away __inline__? > BTW, is the issue with 2.03 or 2.04? IIRC, 2.04 had fix applied for this. -- O.S.