gcc on different platforms

gcc on different platforms

[Daniel Schnell]

Hi everybody,

I've got a question concerning gcc as a cross-compiler for the same
TARGET platform but compiling on different HOST-platforms. (2 gcc's !)

Maybe this is a silly question, but for me it is extremely important to
know.

If the version of gcc is the same on both host platforms, does it
produce the same output (i.e. object files) on different host platforms
if you always use the same source and header files and do not turn on
debugging informations ??

If not, where and what are the differences ??

Thanks in advance,

Daniel Schnell.

Re: gcc on different platforms

[Tim Prince]

>If the version of gcc is the same on both host platforms, does it
>produce the same output (i.e. object files) on different host platforms
>if you always use the same source and header files

>If not, where and what are the differences ??
>
>Thanks in advance,
>

The code block alignments depend on the assembler, and how the compiler is
configured to it.  For example, i686 code may be using .p2align 4,,7 in one
configuration, and unconditional 128-bit alignments in another.
Tim Prince
tprince@computer.org

Re: gcc on different platforms

[Tim Prince]

>If the version of gcc is the same on both host platforms, does it
>produce the same output (i.e. object files) on different host platforms
>if you always use the same source and header files

>If not, where and what are the differences ??
>
>Thanks in advance,
>

The code block alignments depend on the assembler, and how the compiler is
configured to it.  For example, i686 code may be using .p2align 4,,7 in one
configuration, and unconditional 128-bit alignments in another.
Tim Prince
tprince@computer.org

libstdc++.so

[Dave Topham]

I am trying to compile and link my c++ program using g++ (gcc) on one unix
machine (SunOS) then ftp the executable to another unix machine (also
SunOS). When I do that I get this error msg:
ld .so.1 : pgmname : fatal libstdc++.so.2.8.1 "can't open file error-2"

With the help of my sysadmin I figured out that there is a run-time lib
needed to run c++ programs on unix!
(Got to learn sometime)
Anyway, I can set LD_LIBRARY_PATH to the directory where libstdc++.so.2.8.1
resides and then it's OK.

What I want to do instead is to link with the lib path included in the
program itself. I found some info
that seemed to indicate that I can compile/link with options such as -R  or
-rpath  or to set the environment
variable LD_RUN_PATH to force that to be used as run-time lib path, but
none of these option seem to work for me yet.
Has anyone tried to do this using GNU c++ compiler/linker?

I think if I can do this, then when I move my program to the new machine
(which does not have the stdlibc++.so in the same path as it is on the
linking machine),
I can get it to run OK without setting LD_LIBRARY_PATH.

I have tried several attempts:
1) env LD_RUN_PATH=   (the path on the target machine where libstdc++.so
resides)
   then compiling with no options    (seemed to have no effect)
2) using -R option
3) using -rpath option
   (these don't seem to be supported under GNU c++?)

The reason for not wanting to set LD_LIBRARY_PATH is because that can only
be done per user, but I want to invoke my program remotely from a cgi bin
via the web server -- and it doesn't have the path to the lib

Thanks for any suggestions, I appreciate it very much, -Dave

libstdc++.so

[Dave Topham]

I am trying to compile and link my c++ program using g++ (gcc) on one unix
machine (SunOS) then ftp the executable to another unix machine (also
SunOS). When I do that I get this error msg:
ld .so.1 : pgmname : fatal libstdc++.so.2.8.1 "can't open file error-2"

With the help of my sysadmin I figured out that there is a run-time lib
needed to run c++ programs on unix!
(Got to learn sometime)
Anyway, I can set LD_LIBRARY_PATH to the directory where libstdc++.so.2.8.1
resides and then it's OK.

What I want to do instead is to link with the lib path included in the
program itself. I found some info
that seemed to indicate that I can compile/link with options such as -R  or
-rpath  or to set the environment
variable LD_RUN_PATH to force that to be used as run-time lib path, but
none of these option seem to work for me yet.
Has anyone tried to do this using GNU c++ compiler/linker?

I think if I can do this, then when I move my program to the new machine
(which does not have the stdlibc++.so in the same path as it is on the
linking machine),
I can get it to run OK without setting LD_LIBRARY_PATH.

I have tried several attempts:
1) env LD_RUN_PATH=   (the path on the target machine where libstdc++.so
resides)
   then compiling with no options    (seemed to have no effect)
2) using -R option
3) using -rpath option
   (these don't seem to be supported under GNU c++?)

The reason for not wanting to set LD_LIBRARY_PATH is because that can only
be done per user, but I want to invoke my program remotely from a cgi bin
via the web server -- and it doesn't have the path to the lib

Thanks for any suggestions, I appreciate it very much, -Dave

libstdc++.so

[Dave Topham]

I am trying to compile and link my c++ program using g++ (gcc) on one unix
machine (SunOS) then ftp the executable to another unix machine (also
SunOS). When I do that I get this error msg:
ld .so.1 : pgmname : fatal libstdc++.so.2.8.1 "can't open file error-2"

With the help of my sysadmin I figured out that there is a run-time lib
needed to run c++ programs on unix!
(Got to learn sometime)
Anyway, I can set LD_LIBRARY_PATH to the directory where libstdc++.so.2.8.1
resides and then it's OK.

What I want to do instead is to link with the lib path included in the
program itself. I found some info
that seemed to indicate that I can compile/link with options such as -R  or
-rpath  or to set the environment
variable LD_RUN_PATH to force that to be used as run-time lib path, but
none of these option seem to work for me yet.
Has anyone tried to do this using GNU c++ compiler/linker?

I think if I can do this, then when I move my program to the new machine
(which does not have the stdlibc++.so in the same path as it is on the
linking machine),
I can get it to run OK without setting LD_LIBRARY_PATH.

I have tried several attempts:
1) env LD_RUN_PATH=   (the path on the target machine where libstdc++.so
resides)
   then compiling with no options    (seemed to have no effect)
2) using -R option
3) using -rpath option
   (these don't seem to be supported under GNU c++?)

The reason for not wanting to set LD_LIBRARY_PATH is because that can only
be done per user, but I want to invoke my program remotely from a cgi bin
via the web server -- and it doesn't have the path to the lib

Thanks for any suggestions, I appreciate it very much, -Dave

libstdc++.so

[Dave Topham]

I am trying to compile and link my c++ program using g++ (gcc) on one unix
machine (SunOS) then ftp the executable to another unix machine (also
SunOS). When I do that I get this error msg:
ld .so.1 : pgmname : fatal libstdc++.so.2.8.1 "can't open file error-2"

With the help of my sysadmin I figured out that there is a run-time lib
needed to run c++ programs on unix!
(Got to learn sometime)
Anyway, I can set LD_LIBRARY_PATH to the directory where libstdc++.so.2.8.1
resides and then it's OK.

What I want to do instead is to link with the lib path included in the
program itself. I found some info
that seemed to indicate that I can compile/link with options such as -R  or
-rpath  or to set the environment
variable LD_RUN_PATH to force that to be used as run-time lib path, but
none of these option seem to work for me yet.
Has anyone tried to do this using GNU c++ compiler/linker?

I think if I can do this, then when I move my program to the new machine
(which does not have the stdlibc++.so in the same path as it is on the
linking machine),
I can get it to run OK without setting LD_LIBRARY_PATH.

I have tried several attempts:
1) env LD_RUN_PATH=   (the path on the target machine where libstdc++.so
resides)
   then compiling with no options    (seemed to have no effect)
2) using -R option
3) using -rpath option
   (these don't seem to be supported under GNU c++?)

The reason for not wanting to set LD_LIBRARY_PATH is because that can only
be done per user, but I want to invoke my program remotely from a cgi bin
via the web server -- and it doesn't have the path to the lib

Thanks for any suggestions, I appreciate it very much, -Dave

libstdc++.so

[Dave Topham]

I am trying to compile and link my c++ program using g++ (gcc) on one unix
machine (SunOS) then ftp the executable to another unix machine (also
SunOS). When I do that I get this error msg:
ld .so.1 : pgmname : fatal libstdc++.so.2.8.1 "can't open file error-2"

With the help of my sysadmin I figured out that there is a run-time lib
needed to run c++ programs on unix!
(Got to learn sometime)
Anyway, I can set LD_LIBRARY_PATH to the directory where libstdc++.so.2.8.1
resides and then it's OK.

What I want to do instead is to link with the lib path included in the
program itself. I found some info
that seemed to indicate that I can compile/link with options such as -R  or
-rpath  or to set the environment
variable LD_RUN_PATH to force that to be used as run-time lib path, but
none of these option seem to work for me yet.
Has anyone tried to do this using GNU c++ compiler/linker?

I think if I can do this, then when I move my program to the new machine
(which does not have the stdlibc++.so in the same path as it is on the
linking machine),
I can get it to run OK without setting LD_LIBRARY_PATH.

I have tried several attempts:
1) env LD_RUN_PATH=   (the path on the target machine where libstdc++.so
resides)
   then compiling with no options    (seemed to have no effect)
2) using -R option
3) using -rpath option
   (these don't seem to be supported under GNU c++?)

The reason for not wanting to set LD_LIBRARY_PATH is because that can only
be done per user, but I want to invoke my program remotely from a cgi bin
via the web server -- and it doesn't have the path to the lib

Thanks for any suggestions, I appreciate it very much, -Dave

libstdc++.so

[Dave Topham]

I am trying to compile and link my c++ program using g++ (gcc) on one unix
machine (SunOS) then ftp the executable to another unix machine (also
SunOS). When I do that I get this error msg:
ld .so.1 : pgmname : fatal libstdc++.so.2.8.1 "can't open file error-2"

With the help of my sysadmin I figured out that there is a run-time lib
needed to run c++ programs on unix!
(Got to learn sometime)
Anyway, I can set LD_LIBRARY_PATH to the directory where libstdc++.so.2.8.1
resides and then it's OK.

What I want to do instead is to link with the lib path included in the
program itself. I found some info
that seemed to indicate that I can compile/link with options such as -R  or
-rpath  or to set the environment
variable LD_RUN_PATH to force that to be used as run-time lib path, but
none of these option seem to work for me yet.
Has anyone tried to do this using GNU c++ compiler/linker?

I think if I can do this, then when I move my program to the new machine
(which does not have the stdlibc++.so in the same path as it is on the
linking machine),
I can get it to run OK without setting LD_LIBRARY_PATH.

I have tried several attempts:
1) env LD_RUN_PATH=   (the path on the target machine where libstdc++.so
resides)
   then compiling with no options    (seemed to have no effect)
2) using -R option
3) using -rpath option
   (these don't seem to be supported under GNU c++?)

The reason for not wanting to set LD_LIBRARY_PATH is because that can only
be done per user, but I want to invoke my program remotely from a cgi bin
via the web server -- and it doesn't have the path to the lib

Thanks for any suggestions, I appreciate it very much, -Dave

gcc on different platforms

[Daniel Schnell]

Hi everybody,

I've got a question concerning gcc as a cross-compiler for the same
TARGET platform but compiling on different HOST-platforms. (2 gcc's !)

Maybe this is a silly question, but for me it is extremely important to
know.

If the version of gcc is the same on both host platforms, does it
produce the same output (i.e. object files) on different host platforms
if you always use the same source and header files and do not turn on
debugging informations ??

If not, where and what are the differences ??

Thanks in advance,

Daniel Schnell.