On Mon, 2013-06-03 at 17:06 -0400, Paul Smith wrote:
> I can't think of any reason why adding those flags would cause this to
> happen. Indeed, I can't think of any reason why ld-linux.so would NOT
> be linked with your application before these flags were added. I would
> have thought that any ex
On Mon, 2013-06-03 at 13:37 -0700, Kip Warner wrote:
> Another thing, I see the the libstdc++.so.6 and libgcc_s.so.1 removed
> from its dependencies according to objdump, but I did note the addition
> of a new one, ld-linux-x86-64.so.2. Do you think that will be a problem?
I can't think of any rea
On Sun, 2013-06-02 at 10:45 -0400, Paul Smith wrote:
> I'm removing automake from this thread as I'm getting two copies of
> every mail. Hope no one minds.
No problem. I'll try to remember to do the same.
> This is because GCC has some of its internal functionality implemented
> in libraries, wh
On Sun, 2013-06-02 at 03:06 -0400, Mike Frysinger wrote:
> people who do binary releases often times find an old distro that works and
> then upgrade packages as need be. then they keep that image around forever.
>
> either that or they just do a build for the last two RHEL or Ubuntu releases
I'm removing automake from this thread as I'm getting two copies of
every mail. Hope no one minds.
On Sun, 2013-06-02 at 03:06 -0400, Mike Frysinger wrote:
> On Sunday 02 June 2013 01:10:36 Kip Warner wrote:
> > On Sat, 2013-06-01 at 23:14 -0400, Mike Frysinger wrote:
> > > be aware that what eve
On Sunday 02 June 2013 01:10:36 Kip Warner wrote:
> On Sat, 2013-06-01 at 23:14 -0400, Mike Frysinger wrote:
> > be aware that what ever version of glibc & gcc you use to build, the end
> > user cannot have a version older than that or it'll fail to start
>
> Do you mean in the case of dynamic lin
On Sat, 2013-06-01 at 23:14 -0400, Mike Frysinger wrote:
> be aware that what ever version of glibc & gcc you use to build, the end user
> cannot have a version older than that or it'll fail to start
Do you mean in the case of dynamic linking? If so, that's awful. But
strange because I've seen m
On Saturday 01 June 2013 19:27:46 Kip Warner wrote:
> On Fri, 2013-05-31 at 08:31 -0500, Robert Boehne wrote:
> > I don't quite understand why you think you need the rest linked
> > statically,
>
> Libraries like the following may not be present on the end user's system
> already:
be aware that w
On Fri, 2013-05-31 at 07:37 -0700, Dan Kegel wrote:
> You have
> > PKG_CHECK_MODULES([libzzip], [zziplib], [have_zzip=yes], [have_zzip=no])
> Have you seen
> https://bugs.freedesktop.org/show_bug.cgi?id=19541
> ? Maybe try PKG_CHECK_MODULES_STATIC
By the way, outside of that upstream bug report,
On Sat, 2013-06-01 at 17:17 -0700, Dan Kegel wrote:
> Aw, foo. I was under the misapprehention that --static would cause
> pkgconfig to reference the .a files. I've clearly been spending
> too much time in cmake-land.
No worries ;)
> I don't suppose you've tried passing absolute paths to the .a
On Sat, Jun 1, 2013 at 4:42 PM, Kip Warner wrote:
> $ pkg-config --libs zziplib
> -Wl,-Bsymbolic-functions -Wl,-z,relro -lzzip -lz
>
> $ pkg-config --static --libs zziplib
> -Wl,-Bsymbolic-functions -Wl,-z,relro -lzzip -lz
Aw, foo. I was under the misapprehention
On Fri, 2013-05-31 at 07:37 -0700, Dan Kegel wrote:
> You have
> > PKG_CHECK_MODULES([libzzip], [zziplib], [have_zzip=yes], [have_zzip=no])
> Have you seen
> https://bugs.freedesktop.org/show_bug.cgi?id=19541
> ? Maybe try PKG_CHECK_MODULES_STATIC
> or PKG_CONFIG="pkg-config --static"
Hey Dan. I'
On Fri, 2013-05-31 at 14:57 +0100, Diego Elio Pettenò wrote:
> What you're thinking of is -Wl,-Bstatic and -Wl,-Bdynamic — for the GNU
> linker at least, but this is not portable.
>
> Seriously, it sounds to me like something else is wrong, you should never
> have the need to statically link stuff
On Fri, 2013-05-31 at 08:31 -0500, Robert Boehne wrote:
> Statically linking libc is a recipe for disaster, so either read and
> understand why, or just take my word for it.
I'm in agreement and standard libraries are something I'm fine with not
statically linking against, although it's not unus
On Thu, May 30, 2013 at 10:30 PM, Kip Warner wrote:
> The ones for certain I know I should be able to statically link against are
> at least libzzip and libpng.
You have
> PKG_CHECK_MODULES([libzzip], [zziplib], [have_zzip=yes], [have_zzip=no])
Have you seen
https://bugs.freedesktop.org/show_bug.
On Fri, May 31, 2013 at 2:31 PM, Robert Boehne wrote:
> -Wl,-static -lzzip -Wl,call_shared
>
> I don't have a computer in front of me, so YMMV, you should man ld to make
> sure those flags are correct.
>
What you're thinking of is -Wl,-Bstatic and -Wl,-Bdynamic — for the GNU
linker at least, but
Statically linking libc is a recipe for disaster, so either read and
understand why, or just take my word for it.
I don't quite understand why you think you need the rest linked statically, BUT
the easiest way to do that would be to add LT_INIT to configure.ac to use
Libtool, and add --static-
Hey lists,
Sorry for posting on both autoconf and automake lists. I wasn't sure
which one would be more appropriate for this problem.
I know this has come up before, judging by the archives, but I cannot
figure out the best way to have my executable statically link against
certain dependencies. T
18 matches
Mail list logo
