Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 2 Sep 1998 12:37:08 +1000
From:      David Dawes <dawes@rf900.physics.usyd.edu.au>
To:        Joachim Kuebart <joki@kuebart.stuttgart.netsurf.de>, Ollivier Robert <roberto@keltia.freenix.fr>
Cc:        freebsd-current@FreeBSD.ORG
Subject:   Re: XFree86 and ELF
Message-ID:  <19980902123708.A21469@rf900.physics.usyd.edu.au>
In-Reply-To: <199809012148.XAA06237@yacht.domestic.de>; from Joachim Kuebart on Tue, Sep 01, 1998 at 11:48:57PM %2B0200
References:  <19980901204155.A18859@keltia.freenix.fr> <199809012148.XAA06237@yacht.domestic.de>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Sep 01, 1998 at 11:48:57PM +0200, Joachim Kuebart wrote:
>Ollivier Robert wrote:
>> According to Joachim Kuebart:
>> > --- config/cf/bsdLib.rules.orig	Mon Aug 31 18:03:14 1998
>> > +++ config/cf/bsdLib.rules	Tue Sep  1 01:15:44 1998
>> > @@ -153,7 +153,7 @@
>> >  #define ShLibIncludeFile <bsdLib.tmpl>
>> >  #endif
>> >  #ifndef SharedLibraryLoadFlags
>> > -#define SharedLibraryLoadFlags -shared -Wl,-rpath,$(USRLIBDIR)
>> > +#define SharedLibraryLoadFlags -shared -rpath $(USRLIBDIR)
>> 
>> ...and...
>> 
>> >  #ifndef PositionIndependentCFlags
>> >  #define PositionIndependentCFlags -fPIC
>> > @@ -213,7 +213,7 @@
>> >  Concat(lib,libname.so.rev):  solist					@@\
>> >  	$(RM) $@~							@@\
>> >  	SONAME=`echo $@ | sed 's/\.[^\.]*$$//'`; \			@@\
>> > -		(cd down; $(CC) -o up/$@~ $(SHLIBLDFLAGS) -Wl,-soname,$$SONAME solist $(REQUIREDLIBS) BaseShLibReqs); \ @@\
>> > +		(cd down; $(LD) -o up/$@~ $(SHLIBLDFLAGS) -soname $$SONAME solist $(REQUIREDLIBS) BaseShLibReqs); \ @@\
>> 
>> Why ? Using "gcc" to build the shared lib should work the same as using
>> "ld". I don't understand the reason...
>
>This isn't the only place where SharedLibraryLoadFlags aka.
>SHLIBLDFLAGS get used. In most places they are used with $(LD) which
>barf on the -Wl construction. I changed this one usage instead of
>changing three other places.

Can I ask a naive question?  Is there any reason the FreeBSD/ELF rules
need to be different from those used for Linux/ELF (see lnxLib.cf)?  Also,
please keep in mind that bsdLib.rules is used for NetBSD and OpenBSD too.

>> > -#if defined(Lynx) || (defined(SYSV) || defined(SVR4)) && !defined(ACK_ASSEMBLER) || (defined(linux) || defined(__OS2ELF__)) && defined(__ELF__)
>> > +#if defined(Lynx) || (defined(SYSV) || defined(SVR4)) && !defined(ACK_ASSEMBLER) || (defined(__FreeBSD__) || defined(linux) || defined(__OS2ELF__)) && defined(__ELF__)
>> >  #define GLNAME(a)       a
>> >  #else
>> >  #define GLNAME(a)       CONCAT(_,a)
>> 
>> Should not be necessary if you modify GccAsmFlags to include -D__ELF__ in
>> FreeBSD.cf.
>
>If you look at the condition you will see that __ELF__ only gets
>checked on specific operating systems. I made FreeBSD one of the
>operating systems where __ELF__ is considered relevant.

My preference here is to remove the OS checks, which should simplify that
#ifdef a bit.

>> >  #if defined(__GNUC__) && defined(__i386__)
>> >  static __inline__ unsigned int reverse_bitorder(data) {
>> > -#if defined(Lynx) || (defined(SYSV) || defined(SVR4)) && !defined(ACK_ASSEMBLER) || (defined(linux) || defined (__OS2ELF__)) && defined(__ELF__)
>> > +#if defined(Lynx) || (defined(SYSV) || defined(SVR4)) && !defined(ACK_ASSEMBLER) || (defined(__FreeBSD__) || defined(linux) || defined (__OS2ELF__)) && defined(__ELF__)
>> >  	__asm__(
>> >  		"movl $0,%%ecx\n"
>> >  		"movb %%al,%%cl\n"
>> 
>> Same here. gcc already defines __ELF__.
>
>gcc does define __ELF__, but the XFree86 makefiles use the following
>sequence to assemble .s files:
>
>	$(RM) -f $(name).o
>	$(CPP) -D__ELF__ $(name).s > $(name).i
>	$(AS) -o $(name).o $(name).i
>
>Because cpp gets called "manually", __ELF__ needs to be set manually,
>too. :-(

Right.

I see you submitted a patch to XFree86 -- thanks.  Maybe it would be a good
idea to wait a little while until everything is resolved, then send another
patch?  I don't have a box running 3.0 ELF yet, but I'm planning to set one
up in the next week or two.

David

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980902123708.A21469>