Passing -r to the linker

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Passing -r to the linker

David Chisnall-2
Hi,

I have a problem with a few projects that pass -r as a link flag to clang - this isn't passed to the linker, so there end up being a large number of unresolved reference errors.  Apparently it is correctly passed on some platforms, but not others (FreeBSD in this case).  

David

-- Sent from my Apple II


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Passing -r to the linker

Dimitry Andric
On 2010-08-13 14:18, David Chisnall wrote:
> I have a problem with a few projects that pass -r as a link flag to clang - this isn't passed to the linker, so there end up being a large number of unresolved reference errors.  Apparently it is correctly passed on some platforms, but not others (FreeBSD in this case).  

Yes, this is a real difference in command line option processing between
gcc and clang.  Probably for old-time compatibility's sake, gcc just
passes unknown options through to the linker, while clang seems to just
swallow them. :)

As a workaround, you can use "-Wl,-r", if that is possible for your
projects.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Passing -r to the linker

Daniel Dunbar-2
On Aug 13, 2010, at 7:25, Dimitry Andric <[hidden email]> wrote:

> On 2010-08-13 14:18, David Chisnall wrote:
>> I have a problem with a few projects that pass -r as a link flag to clang - this isn't passed to the linker, so there end up being a large number of unresolved reference errors.  Apparently it is correctly passed on some platforms, but not others (FreeBSD in this case).
>
> Yes, this is a real difference in command line option processing between
> gcc and clang.  Probably for old-time compatibility's sake, gcc just
> passes unknown options through to the linker, while clang seems to just
> swallow them. :)

I don't believe this to be correct. GCC passes *a lot* of options
through to the linker, buy certainly not all unrecognized options.

You just need to updater the toolchain definition for your platform to
pass -r through.

 - Daniel

> As a workaround, you can use "-Wl,-r", if that is possible for your
> projects.
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Passing -r to the linker

Dale Johannesen

On Aug 15, 2010, at 9:15 AM, Daniel Dunbar wrote:

> On Aug 13, 2010, at 7:25, Dimitry Andric <[hidden email]> wrote:
>>
>> Yes, this is a real difference in command line option processing  
>> between
>> gcc and clang.  Probably for old-time compatibility's sake, gcc just
>> passes unknown options through to the linker, while clang seems to  
>> just
>> swallow them. :)
>
> I don't believe this to be correct. GCC passes *a lot* of options
> through to the linker, buy certainly not all unrecognized options.

Can it be that nobody has tried this yet?

now what? gcc-4.2 -v hello.c -qxysuz
Using built-in specs.
Target: i686-apple-darwin11
Configured with: /var/tmp/gcc/gcc-5666~31/src/configure --disable-
checking --enable-werror --prefix=/usr --mandir=/share/man --enable-
languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/
$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin11 --program-
prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-
apple-darwin11 --with-gxx-include-dir=/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5666)
  /usr/libexec/gcc/i686-apple-darwin11/4.2.1/cc1 -quiet -v -imultilib  
x86_64 -D__DYNAMIC__ hello.c -fPIC -quiet -dumpbase hello.c -mmacosx-
version-min=10.7.0 -m64 -mtune=core2 -auxbase hello -version -o /var/
folders/7r/qp6k51002kk8q66xv3dq29=w+++26j/T//ccZ6surA.s
ignoring nonexistent directory "/usr/lib/gcc/i686-apple-
darwin11/4.2.1/../../../../i686-apple-darwin11/include"
#include "..." search starts here:
#include <...> search starts here:
  /usr/local/include
  /usr/lib/gcc/i686-apple-darwin11/4.2.1/include
  /usr/include
  /System/Library/Frameworks (framework directory)
  /Library/Frameworks (framework directory)
End of search list.
GNU C version 4.2.1 (Apple Inc. build 5666) (i686-apple-darwin11)
        compiled by GNU C version 4.2.1 (Apple Inc. build 5666).
GGC heuristics: --param ggc-min-expand=150 --param ggc-min-
heapsize=65536
Compiler executable checksum: 0493e38a981908552b45ec7d6d053909
hello.c: In function 'main':
hello.c:1: warning: incompatible implicit declaration of built-in  
function 'printf'
  /usr/libexec/gcc/i686-apple-darwin11/4.2.1/as -arch x86_64 -
force_cpusubtype_ALL -o /var/folders/7r/qp6k51002kk8q66xv3dq29=w+++26j/
T//ccA6bE21.o /var/folders/7r/qp6k51002kk8q66xv3dq29=w+++26j/T//
ccZ6surA.s
  /usr/libexec/gcc/i686-apple-darwin11/4.2.1/collect2 -dynamic -arch  
x86_64 -macosx_version_min 10.7.0 -weak_reference_mismatches non-weak -
o a.out -lcrt1.10.6.o -L/usr/lib/gcc/i686-apple-darwin11/4.2.1/x86_64 -
L/usr/lib/gcc/i686-apple-darwin11/4.2.1/x86_64 -L/usr/lib/i686-apple-
darwin11/4.2.1 -L/usr/lib/gcc/i686-apple-darwin11/4.2.1 -L/usr/lib/gcc/
i686-apple-darwin11/4.2.1 -L/usr/lib/gcc/i686-apple-
darwin11/4.2.1/../../../i686-apple-darwin11/4.2.1 -L/usr/lib/gcc/i686-
apple-darwin11/4.2.1/../../.. /var/folders/7r/qp6k51002kk8q66xv3dq29=w+
++26j/T//ccA6bE21.o -lSystem -lgcc -lSystem
now what?

So Daniel is correct, at least on Darwin.

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Passing -r to the linker

Daniel Dunbar
In reply to this post by Daniel Dunbar-2
See lib/Driver/Tools.cpp, freebsd::Link::ConstructJob, and compare it
to darwin::Link::ConstructJob.

The original derivation of these things should come from the "gcc
specs", if you want to really match gcc. See gcc -dumpspecs and look
for link_command. I encouraged people to use this information when
creating the tool definition for their platform, but I'm not sure they
payed attention. :)

 - Daniel

On Sun, Aug 15, 2010 at 9:57 AM, David Chisnall <[hidden email]> wrote:

> On 15 Aug 2010, at 17:15, Daniel Dunbar wrote:
>
>> You just need to updater the toolchain definition for your platform to
>> pass -r through.
>
>
> Where does this definition live?
>
> David
>
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev