Date: Sat, 18 Dec 1999 01:01:36 -0500 (EST) From: "Andrew Atrens" <atrens@nortelnetworks.com> To: Doug White <dwhite@resnet.uoregon.edu> Cc: current@FreeBSD.ORG Subject: Re: framemaker for linux Message-ID: <Pine.BSF.4.21.9912180054430.8440-100000@hcarp00g.ca.nortel.com> In-Reply-To: <Pine.BSF.4.21.9912172044510.59061-100000@resnet.uoregon.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 17 Dec 1999, Doug White wrote:
> Date: Fri, 17 Dec 1999 20:45:40 -0800 (PST)
> From: Doug White <dwhite@resnet.uoregon.edu>
> To: "Atrens, Andrew (A.B.) [EXCHANGE:SKY:1U33]"
> <atrens@americasm01.nt.com>
> Cc: current@FreeBSD.ORG
> Subject: Re: framemaker for linux
>
> On Thu, 16 Dec 1999, Andrew Atrens wrote:
>
> >
> > All,
> >
> > This might be a linux ABI question, or it might be an `ld.so' question,
> > so arguably I could have sent this to emulation, questions or since I run
> > -current, current, or perhaps hackers, at any rate here goes -
> >
> >
> > I've got `framemaker for linux' and am getting -
> >
> > # maker5X.exe
> > maker5X.exe: error in loading shared libraries
> > : undefined symbol: __register_frame_info
> >
>
> I believe this is a libc issue. I remember running into this before,
> although on the FreeBSD ABI (I _think_).
Quite possibly since at the root of it, it's a gcc/egcs incompatibility.
The problem is described quite nicely in the glibc FAQ -
| 2.8. When I run an executable on one system which I compiled on
| another, I get dynamic linker errors. Both systems have the same
| version of glibc installed. What's wrong?
|
| {ZW} Glibc on one of these systems was compiled with gcc 2.7 or 2.8, the
| other with egcs (any version). Egcs has functions in its internal
| `libgcc.a' to support exception handling with C++. They are linked into
| any program or dynamic library compiled with egcs, whether it needs them
| or
| not. Dynamic libraries then turn around and export those functions again
| unless special steps are taken to prevent them.
|
| When you link your program, it resolves its references to the exception
| functions to the ones exported accidentally by libc.so. That works fine
| as
| long as libc has those functions. On the other system, libc doesn't have
| those functions because it was compiled by gcc 2.8, and you get undefined
| symbol errors. The symbols in question are named things like
| `__register_frame_info'.
The best thing to do is get the glibc-2.1.2-11.i386.rpm from redhat and
install it with -
rpm --ignoreos --root=/usr/compat/linux --nodeps -i glibc-2.1.2-11.i386.rpm
This version apparently has stubs for __register_frame_info and friends
and so will work irregardless of which gcc it was built with.
Andrew.
--
+--
| Andrew Atrens Nortel Networks, Ottawa, Canada. |
| All opinions expressed are my own, not those of any employer. |
--+
Heller's Law: The first myth of management is that it exists.
Johnson's Corollary: Nobody really knows what is going on
anywhere within the organization.
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?Pine.BSF.4.21.9912180054430.8440-100000>