Why clang may not be compatible with gcc for .a file generation?

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

Why clang may not be compatible with gcc for .a file generation?

David Blaikie via cfe-dev
Hi,

I have the following trace.c file compiled with the following command
with clang.

$ clang -Wall -pedantic -c -o trace.o trace.c
$ ar cr  libtrace.a trace.o
$ ranlib libtrace.a

Then, I run configure from a GNU package, which gives the following
error. It asks to recompile the .a with -fPIC. Is it because gcc and
clang has different default on whether -fPIC is enabled? Could anybody
help explain why there is such a difference? Thanks.

configure:3772: gcc -g -finstrument-functions
-L/root/linux/bin/wrappercomposite/src/xplat/llvmxplat/src/mkvar/bin/Linux
conftest.c -ltrace >&5
/usr/bin/ld: /root/linux/bin/wrappercomposite/src/xplat/llvmxplat/src/mkvar/bin/Linux/libtrace.a(trace.o):
relocation R_X86_64_32S against `.bss' can not be used when making a
PIE object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output

//trace.c
#include <stdio.h>
#include <stdlib.h>
//#include <time.h>

static FILE *fp_trace;

void __attribute__ ((constructor)) trace_begin (void) {
    const char *s=getenv("TRACE_OUTFILE");
    if(s) {
        fp_trace = fopen(s, "w");
    } else {
        fputs(
                "\x1b[31;1mThe environment variable TRACE_OUTFILE must
be set.\x1b[m\n"
                , stderr
                );
        exit(1);
    }
}

void __attribute__ ((destructor)) trace_end (void) {
    if(fp_trace != NULL) {
        fclose(fp_trace);
    }
}

void __cyg_profile_func_enter (void *func,  void *caller) {
    if(fp_trace != NULL) {
        //fprintf(fp_trace, "e %p %p %lu\n", func, caller, time(NULL) );
        fprintf(fp_trace, "%p\t%p\n", func, caller);
    }
}

void __cyg_profile_func_exit (void *func, void *caller) { }


--
Regards,
Peng
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Why clang may not be compatible with gcc for .a file generation?

David Blaikie via cfe-dev
Hi,

On Thu, Jan 24, 2019 at 4:00 AM Peng Yu via cfe-dev <[hidden email]> wrote:
Hi,

I have the following trace.c file compiled with the following command
with clang.

$ clang -Wall -pedantic -c -o trace.o trace.c
$ ar cr  libtrace.a trace.o
$ ranlib libtrace.a

Then, I run configure from a GNU package, which gives the following
error. It asks to recompile the .a with -fPIC. Is it because gcc and
clang has different default on whether -fPIC is enabled? Could anybody
help explain why there is such a difference? Thanks.

configure:3772: gcc -g -finstrument-functions
-L/root/linux/bin/wrappercomposite/src/xplat/llvmxplat/src/mkvar/bin/Linux
conftest.c -ltrace >&5
/usr/bin/ld: /root/linux/bin/wrappercomposite/src/xplat/llvmxplat/src/mkvar/bin/Linux/libtrace.a(trace.o):
relocation R_X86_64_32S against `.bss' can not be used when making a
PIE object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output


What happens if you run this command with clang instead of gcc ?

Csaba
--
You can get very substantial performance improvements
by not doing the right thing. - Scott Meyers, An Effective C++11/14 Sampler
So if you're looking for a completely portable, 100% standards-conformat way
to get the wrong information: this is what you want. - Scott Meyers (C++TDaWYK)

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Why clang may not be compatible with gcc for .a file generation?

David Blaikie via cfe-dev
clang works fine.

On Thu, Jan 24, 2019 at 2:45 AM Csaba Raduly <[hidden email]> wrote:
Hi,

On Thu, Jan 24, 2019 at 4:00 AM Peng Yu via cfe-dev <[hidden email]> wrote:
Hi,

I have the following trace.c file compiled with the following command
with clang.

$ clang -Wall -pedantic -c -o trace.o trace.c
$ ar cr  libtrace.a trace.o
$ ranlib libtrace.a

Then, I run configure from a GNU package, which gives the following
error. It asks to recompile the .a with -fPIC. Is it because gcc and
clang has different default on whether -fPIC is enabled? Could anybody
help explain why there is such a difference? Thanks.

configure:3772: gcc -g -finstrument-functions
-L/root/linux/bin/wrappercomposite/src/xplat/llvmxplat/src/mkvar/bin/Linux
conftest.c -ltrace >&5
/usr/bin/ld: /root/linux/bin/wrappercomposite/src/xplat/llvmxplat/src/mkvar/bin/Linux/libtrace.a(trace.o):
relocation R_X86_64_32S against `.bss' can not be used when making a
PIE object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output


What happens if you run this command with clang instead of gcc ?


Csaba
--
You can get very substantial performance improvements
by not doing the right thing. - Scott Meyers, An Effective C++11/14 Sampler
So if you're looking for a completely portable, 100% standards-conformat way
to get the wrong information: this is what you want. - Scott Meyers (C++TDaWYK)
--
Regards,
Peng

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Why clang may not be compatible with gcc for .a file generation?

David Blaikie via cfe-dev
In reply to this post by David Blaikie via cfe-dev
On Wed, Jan 23, 2019 at 09:00:20PM -0600, Peng Yu via cfe-dev wrote:
> Then, I run configure from a GNU package, which gives the following
> error. It asks to recompile the .a with -fPIC. Is it because gcc and
> clang has different default on whether -fPIC is enabled? Could anybody
> help explain why there is such a difference? Thanks.

On some platforms GCC will create PIE by default. If clang doesn't match
that, it would certainly explain what you see. Try to compile your code
with -fPIE.

Joerg
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev