public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* gcc on different platforms
@ 1999-12-10 21:48 Daniel Schnell
  1999-12-11 11:10 ` Tim Prince
                   ` (4 more replies)
  0 siblings, 5 replies; 10+ messages in thread
From: Daniel Schnell @ 1999-12-10 21:48 UTC (permalink / raw)
  To: help-gcc

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.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: gcc on different platforms
  1999-12-10 21:48 gcc on different platforms Daniel Schnell
@ 1999-12-11 11:10 ` Tim Prince
  1999-12-31 22:24   ` Tim Prince
  1999-12-11 12:50 ` libstdc++.so Dave Topham
                   ` (3 subsequent siblings)
  4 siblings, 1 reply; 10+ messages in thread
From: Tim Prince @ 1999-12-11 11:10 UTC (permalink / raw)
  To: help-gcc

>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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* libstdc++.so
  1999-12-10 21:48 gcc on different platforms Daniel Schnell
  1999-12-11 11:10 ` Tim Prince
  1999-12-11 12:50 ` libstdc++.so Dave Topham
@ 1999-12-11 12:50 ` Dave Topham
  1999-12-31 22:24   ` libstdc++.so Dave Topham
  1999-12-11 12:50 ` libstdc++.so Dave Topham
  1999-12-31 22:24 ` gcc on different platforms Daniel Schnell
  4 siblings, 1 reply; 10+ messages in thread
From: Dave Topham @ 1999-12-11 12:50 UTC (permalink / raw)
  To: help-gcc

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



^ permalink raw reply	[flat|nested] 10+ messages in thread

* libstdc++.so
  1999-12-10 21:48 gcc on different platforms Daniel Schnell
                   ` (2 preceding siblings ...)
  1999-12-11 12:50 ` libstdc++.so Dave Topham
@ 1999-12-11 12:50 ` Dave Topham
  1999-12-31 22:24   ` libstdc++.so Dave Topham
  1999-12-31 22:24 ` gcc on different platforms Daniel Schnell
  4 siblings, 1 reply; 10+ messages in thread
From: Dave Topham @ 1999-12-11 12:50 UTC (permalink / raw)
  To: help-gcc

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



^ permalink raw reply	[flat|nested] 10+ messages in thread

* libstdc++.so
  1999-12-10 21:48 gcc on different platforms Daniel Schnell
  1999-12-11 11:10 ` Tim Prince
@ 1999-12-11 12:50 ` Dave Topham
  1999-12-31 22:24   ` libstdc++.so Dave Topham
  1999-12-11 12:50 ` libstdc++.so Dave Topham
                   ` (2 subsequent siblings)
  4 siblings, 1 reply; 10+ messages in thread
From: Dave Topham @ 1999-12-11 12:50 UTC (permalink / raw)
  To: help-gcc

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



^ permalink raw reply	[flat|nested] 10+ messages in thread

* gcc on different platforms
  1999-12-10 21:48 gcc on different platforms Daniel Schnell
                   ` (3 preceding siblings ...)
  1999-12-11 12:50 ` libstdc++.so Dave Topham
@ 1999-12-31 22:24 ` Daniel Schnell
  4 siblings, 0 replies; 10+ messages in thread
From: Daniel Schnell @ 1999-12-31 22:24 UTC (permalink / raw)
  To: help-gcc

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.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* libstdc++.so
  1999-12-11 12:50 ` libstdc++.so Dave Topham
@ 1999-12-31 22:24   ` Dave Topham
  0 siblings, 0 replies; 10+ messages in thread
From: Dave Topham @ 1999-12-31 22:24 UTC (permalink / raw)
  To: help-gcc

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



^ permalink raw reply	[flat|nested] 10+ messages in thread

* libstdc++.so
  1999-12-11 12:50 ` libstdc++.so Dave Topham
@ 1999-12-31 22:24   ` Dave Topham
  0 siblings, 0 replies; 10+ messages in thread
From: Dave Topham @ 1999-12-31 22:24 UTC (permalink / raw)
  To: help-gcc

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



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: gcc on different platforms
  1999-12-11 11:10 ` Tim Prince
@ 1999-12-31 22:24   ` Tim Prince
  0 siblings, 0 replies; 10+ messages in thread
From: Tim Prince @ 1999-12-31 22:24 UTC (permalink / raw)
  To: help-gcc

>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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* libstdc++.so
  1999-12-11 12:50 ` libstdc++.so Dave Topham
@ 1999-12-31 22:24   ` Dave Topham
  0 siblings, 0 replies; 10+ messages in thread
From: Dave Topham @ 1999-12-31 22:24 UTC (permalink / raw)
  To: help-gcc

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



^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~1999-12-31 22:24 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-12-10 21:48 gcc on different platforms Daniel Schnell
1999-12-11 11:10 ` Tim Prince
1999-12-31 22:24   ` Tim Prince
1999-12-11 12:50 ` libstdc++.so Dave Topham
1999-12-31 22:24   ` libstdc++.so Dave Topham
1999-12-11 12:50 ` libstdc++.so Dave Topham
1999-12-31 22:24   ` libstdc++.so Dave Topham
1999-12-11 12:50 ` libstdc++.so Dave Topham
1999-12-31 22:24   ` libstdc++.so Dave Topham
1999-12-31 22:24 ` gcc on different platforms Daniel Schnell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).