On Tue, Oct 03, 2000 at 05:29:07AM -0200, Alexandre Oliva wrote:
> I recall having had trouble on SunOS 4 when adding some PIC flag to
> the command line that I used to create shared libraries. But that was
> long before libtool existed, and I no longer have access to SunOS 4
> boxes to test aga
On Oct 3, 2000, Marc Espie <[EMAIL PROTECTED]> wrote:
> ??? I'm advocating adding $pic_flag to the gcc that gets used to
> link. Considering that the SAME $pic_flag gets used to build the
> object files in the first place, I have trouble understanding how
> this breaks multi-libbed ABI.
Err...
On Tue, Oct 03, 2000 at 04:33:55AM -0200, Alexandre Oliva wrote:
> On Oct 2, 2000, Marc Espie <[EMAIL PROTECTED]> wrote:
>
> > * when invoking gcc to produce shared libraries, always pass pic_flag
> > around.
>
> This can't be done on all platforms. IIRC, on SunOS4, -fPIC or -fpic
> (I don't r
On Oct 2, 2000, Marc Espie <[EMAIL PROTECTED]> wrote:
> * when invoking gcc to produce shared libraries, always pass pic_flag
> around.
This can't be done on all platforms. IIRC, on SunOS4, -fPIC or -fpic
(I don't recall which one) change the ABI, so libgcc and libstdc++
(and all other GCC lib
Hi Marc,
On Mon, Oct 02, 2000 at 10:41:12AM +0200, Marc Espie wrote:
> * the link lines output by libtool are ludicrously long. Since our linker
> does NOT prune excess libraries, but reloads the symbols each time, this
> is a fairly large problem... Observe:
I thought that we fixed this proble
I've noticed these problems with kde2 (beta 1.94), I'm not sure these are
solved in current. At least one isn't.
* when invoking gcc to produce shared libraries, always pass pic_flag
around. On some a.out systems, gcc goes through collect2 before attacking
ld, and collect2 does create stub code
