On Sun, Aug 22, 2021 at 7:01 AM Bob Friesenhahn <
bfrie...@simple.dallas.tx.us> wrote:
> On Sat, 21 Aug 2021, Oleg Smolsky wrote:
> >>
> >> So, if libtool does not believe that /usr/lib/x86_64-linux-gnu is in
> >> the default search path, it adds it.
> >>
> > Right, and my compiler is in /opt/gcc-
On Sat, 21 Aug 2021, Oleg Smolsky wrote:
So, if libtool does not believe that /usr/lib/x86_64-linux-gnu is in
the default search path, it adds it.
Right, and my compiler is in /opt/gcc-11/ and so that addition to
LD_LIBRARY_PATH is wrong. The system's compiler is older than what we use
and the
>>> Hello there! We have an autotools-based build system setup with a
>>> custom GCC where we take all build- and run-time dependencies
>>> (except for glibc) from /opt. [...]
>
> So far the cleanest hack I've found is to patch the generated
> "libtool" script so that the generated test wrappers
On Sat, Aug 21, 2021 at 4:25 PM Bob Friesenhahn <
bfrie...@simple.dallas.tx.us> wrote:
> On Sat, 21 Aug 2021, Oleg Smolsky wrote:
>
> >
> > Hello there! We have an autotools-based build system setup with a custom
> GCC where we take all build- and run-time dependencies (except for glibc)
> > from
On Sat, 21 Aug 2021, Oleg Smolsky wrote:
Hello there! We have an autotools-based build system setup with a custom GCC
where we take all build- and run-time dependencies (except for glibc)
from /opt. Things have worked well on Ubuntu 16, yet I'm hitting a funky issue
when building on Ubuntu20
On 2021-08-21 07:56, Oleg Smolsky
wrote:
Hello there! We have an autotools-based
build system setup with a custom GCC where we take all build-
and run-time dependencies (except for glibc) from /opt. Things
have worked well on Ubu
Hello there! We have an autotools-based
build system setup with a custom GCC where we take all build-
and run-time dependencies (except for glibc) from /opt. Things
have worked well on Ubuntu 16, yet I'm hitting a funky issue
when building on Ubuntu20 (lib
On Sat, Nov 10, 2012 at 11:28 AM, Poor Yorick
wrote:
>> > On Nov 8, 2012 6:38 PM, "Poor Yorick"
>> >
> [SNIP]
>>
>> the culprit turns out to be "/path/to/software/collection/lib/libffi.la",
>> which was included in "dependency_libs" of
>> /path/to/src/glib-2.32.4/glib-2.32.4/gobject/libgobjec
> > On Nov 8, 2012 6:38 PM, "Poor Yorick"
[SNIP]
>
> the culprit turns out to be "/path/to/software/collection/lib/libffi.la",
> which was included in "dependency_libs" of
> /path/to/src/glib-2.32.4/glib-2.32.4/gobject/libgobject-2.0.la. If I remove
> that, the error disappears.
>
> Here's
On Fri, Nov 09, 2012 at 07:12:10AM -0800, Dan Nicholson wrote:
> On Nov 8, 2012 6:38 PM, "Poor Yorick"
> wrote:
> >
> > Hi,
> >
> > Attempting to build glib-2.32.4, the "make check" stage, produces this
> result:
> >
> > /path/to/src/glib-2.32.4/glib-2.32.4/gobject/tests/.libs/boxed: symbol
> look
On Nov 8, 2012 6:38 PM, "Poor Yorick"
wrote:
>
> Hi,
>
> Attempting to build glib-2.32.4, the "make check" stage, produces this
result:
>
> /path/to/src/glib-2.32.4/glib-2.32.4/gobject/tests/.libs/boxed: symbol
lookup error:
/path/to/glib-2.32.4/glib-2.32.4/gobject/.libs/libgobject-2.0.so.0:
undef
Hi,
Attempting to build glib-2.32.4, the "make check" stage, produces this result:
/path/to/src/glib-2.32.4/glib-2.32.4/gobject/tests/.libs/boxed: symbol lookup
error: /path/to/glib-2.32.4/glib-2.32.4/gobject/.libs/libgobject-2.0.so.0:
undefined symbol: g_key_file_unref
looking at .../gobject
12 matches
Mail list logo
