On Tue, 18 Dec 2012 12:40:39 + (UTC)
Walter Hurry wrote:
> 9.1 RC3 (started out as 9.0 RELEASE)
>
> Over time, as ports have been upgraded, I seem to have accumulated a
> number of obsolete shared libraries - a recent example being /usr/local/
> lib/libpcre.so.1, which appea
9.1 RC3 (started out as 9.0 RELEASE)
Over time, as ports have been upgraded, I seem to have accumulated a
number of obsolete shared libraries - a recent example being /usr/local/
lib/libpcre.so.1, which appears no longer to be linked in by anything,
having been replaced by libpcre.so.3.
Is
ls ./src/libslatec.so.1
> > ./src/libslatec.so.1
> > %
> >
> > Now I'd like to test shared libraries, so I do
> >
> > % gfortran45 -o test01.x test01.o qc6a.o -L./src/ -lslatec
> > % ./test01.x
> > /libexec/ld-elf.so.1: Shared object &qu
On Monday 29 November 2010 14:50:59 Anton Shterenlikht wrote:
> I compiled some numerical libraries under my home
> directory, including static and shared libs. The
> shared lib is
>
> % ls ./src/libslatec.so.1
> ./src/libslatec.so.1
> %
>
> Now I'd like t
On Mon, 29 Nov 2010, Anton Shterenlikht wrote:
|I compiled some numerical libraries under my home
|directory, including static and shared libs. The
|shared lib is
|
|% ls ./src/libslatec.so.1
|./src/libslatec.so.1
|%
|
|Now I'd like to test shared libraries, so I do
|
|% gfortran45 -o tes
On Mon, 29 Nov 2010, Anton Shterenlikht wrote:
|I compiled some numerical libraries under my home
|directory, including static and shared libs. The
|shared lib is
|
|% ls ./src/libslatec.so.1
|./src/libslatec.so.1
|%
|
|Now I'd like to test shared libraries, so I do
|
|% gfortran45 -o tes
I compiled some numerical libraries under my home
directory, including static and shared libs. The
shared lib is
% ls ./src/libslatec.so.1
./src/libslatec.so.1
%
Now I'd like to test shared libraries, so I do
% gfortran45 -o test01.x test01.o qc6a.o -L./src/ -lslatec
% ./test01.x
/libex
huge shared
libraries.
Link your program statically and bypass the dynamic linker completely.
Then my binary would be more than 200MB and it wouldn't load that fast
either.
Besides I have several binaries using the same libraries and linking
them all statically would take up a lot more
In the last episode (Aug 31), Andrea Venturoli said:
> Suppose I have an executable which I need to invoke repeatedly (e.g. to
> run tests in a makefile). This executables spend most of its time loading
> (rather than processing), due to the need of several huge shared
> libraries
Ivan Voras wrote:
On 08/31/10 14:44, Andrea Venturoli wrote:
Hello.
Suppose I have an executable which I need to invoke repeatedly (e.g. to
run tests in a makefile).
This executables spend most of its time loading (rather than
processing), due to the need of several huge shared libraries.
I
On 08/31/10 14:44, Andrea Venturoli wrote:
Hello.
Suppose I have an executable which I need to invoke repeatedly (e.g. to
run tests in a makefile).
This executables spend most of its time loading (rather than
processing), due to the need of several huge shared libraries.
I'd welcome an hi
On Tue Aug 31 10, Andrea Venturoli wrote:
> Hello.
>
> Suppose I have an executable which I need to invoke repeatedly (e.g. to
> run tests in a makefile).
> This executables spend most of its time loading (rather than
> processing), due to the need of several huge shared l
Hello.
Suppose I have an executable which I need to invoke repeatedly (e.g. to
run tests in a makefile).
This executables spend most of its time loading (rather than
processing), due to the need of several huge shared libraries.
I'd welcome an hint on how to speed this up.
Possible
300] [Job 29] Samsung_CLP-310_Series: error while
loading shared libraries: /usr/lib/libcups.so.2: ELF file OS ABI invalid
[...]
D [28/Aug/2010:11:44:14 +0300] [Job 29]
printer-state-message="/usr/local/libexec/cups/filter/rastertosamsungsplc
failed"
[...]
So I have 2 problems.
1) /usr/l
On Mon, Dec 21, 2009 at 03:00:27PM -0800, Matthew Fleming wrote:
> We have a bunch of libraries to support our product and as far as I know
> we only link to the shared library version. I'd like to skip the build
> of the static version of our libraries to speed up our builds and save
> on disk sp
We have a bunch of libraries to support our product and as far as I know
we only link to the shared library version. I'd like to skip the build
of the static version of our libraries to speed up our builds and save
on disk space, but I don't see any way to do that via directives in the
Makefiles.
Hi Oliver,
On Fri, 25 May 2007 09:23:11 +0700 (ICT) Olivier Nicole wrote:
> > However you may try to install the port I wrote:
> > ftp://ftp.ipt.ru/pub/download/linux-qt3.tar.bz2
> >
> > # cp linux-qt3.tar.bz2 /usr/ports/x11-toolkits
> > # cd /usr/ports/x11-toolkits
> > # tar xyf linux-qt3.tar.b
Hi Boris,
> However you may try to install the port I wrote:
> ftp://ftp.ipt.ru/pub/download/linux-qt3.tar.bz2
>
> # cp linux-qt3.tar.bz2 /usr/ports/x11-toolkits
> # cd /usr/ports/x11-toolkits
> # tar xyf linux-qt3.tar.bz2
> # cd linux-qt3
> # make install clean
>
> I've tested the port at tinde
On Thu, 24 May 2007 12:26:47 +0700 (ICT) Olivier Nicole wrote:
> $ ldconfig -r | grep libqt-mt.so.3
> 102:-lqt-mt.3 => /usr/X11R6/lib/libqt-mt.so.3
> $ ldd colorseg
> colorseg:
> libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x28279000)
> libjpeg.so.62 => /usr/lib/libjpeg.
Hi,
I have the two following problems:
1)
$ ldconfig -r | grep libqt-mt.so.3
102:-lqt-mt.3 => /usr/X11R6/lib/libqt-mt.so.3
$ ldd colorseg
colorseg:
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x28279000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x282e2000)
libp
In the last episode (Jun 24), Simeon Nifos said:
> Does anybody know how to convert a shared object compiled in Linux
> foo-linux.so to a shared object compiled for FreeBSD freebsd-foo.so?
> I mean a freebsd-foo.so to which I can link with objects compiled by
> a native FreeBSD compiler. Or equival
Does anybody know how to convert a shared object
compiled in Linux foo-linux.so to a shared object
compiled for FreeBSD freebsd-foo.so? I mean
a freebsd-foo.so to which I can link with objects
compiled by a native FreeBSD compiler. Or
equivalently how to create a FreeBSD foo.so from
a linux foo.so
2006/6/20, Simeon Nifos <[EMAIL PROTECTED]>:
Does anybody know how to convert a shared object
compiled in Linux foo-linux.so to a shared object
compiled for FreeBSD freebsd-foo.so? I mean
a freebsd-foo.so to which I can link with objects
compiled by a native FreeBSD compiler. Or
equivalently how
Does anybody know how to convert a shared object
compiled in Linux foo-linux.so to a shared object
compiled for FreeBSD freebsd-foo.so? I mean
a freebsd-foo.so to which I can link with objects
compiled by a native FreeBSD compiler. Or
equivalently how to create a FreeBSD foo.so from
a linux fo
rror while loading shared
> libraries: libX11.so.6: cannot open shared object file: No such file or
> directory
>
>
> I googled, but there does not seem to be a fix. Any suggestions for
> fixing are appreciated.
Sounds like you're missing the relevant linux package. Di
I recently upgraded to 6.1 beta3, and am now having a problem with
Realplayer. When I try to start it from the command line, I get the
following:
# realplay
/usr/X11R6/lib/RealPlayer/realplay.bin: error while loading shared
libraries: libX11.so.6: cannot open shared object file: No such file or
On Thu, 2006-01-12 at 16:21 +0100, Kiffin Gish wrote:
> I have some shared libraries blah.so etc. that I want to be available to
> other programs. They are located in a separate directory from the
> default linux compat stuff.
>
> I guess I could create a link using ln -s, but eve
I have some shared libraries blah.so etc. that I want to be available to
other programs. They are located in a separate directory from the
default linux compat stuff.
I guess I could create a link using ln -s, but every time blah.so is
rebuilt the link will not longer be valid.
What'
On Mon, Oct 24, 2005 at 07:13:25PM +0200, Philip Lykke Carlsen wrote:
> Sunday 23 October 2005 18:23 skrev du:
> > Philip Lykke Carlsen wrote:
> > > Hey.. I wondered if it was possible to load a selection of shared
> > > libraies into the cache at boot time.. I figure that it would speed up
> > > s
Sunday 23 October 2005 18:23 skrev du:
> Philip Lykke Carlsen wrote:
> > Hey.. I wondered if it was possible to load a selection of shared
> > libraies into the cache at boot time.. I figure that it would speed up
> > starting things.. like the KDE login manager for instance..
> >
> > hm.. is this
Philip Lykke Carlsen wrote:
Hey.. I wondered if it was possible to load a selection of shared libraies
into the cache at boot time.. I figure that it would speed up starting
things.. like the KDE login manager for instance..
hm.. is this possible? .. and if so.. would it speed up the process o
Hey.. I wondered if it was possible to load a selection of shared libraies
into the cache at boot time.. I figure that it would speed up starting
things.. like the KDE login manager for instance..
hm.. is this possible? .. and if so.. would it speed up the process of
starting stuff at all?..
_
On one of my two 4.11 boxes, kdelibs fails to build. Here's the output:
gmake[3]: Entering directory
`/usr/ports/x11/kdelibs3/work/kdelibs-3.4.0/arts/kde'
/usr/local/bin/mcopidl -I/usr/local/include/arts -t
-I. ../../arts/kde/artskde.idl
/usr/libexec/ld-elf.so.1: Shared object "libgmodule-2.0.so
On Wed, 2 Mar 2005, Dan Nelson wrote:
and the errors I get looks like this:
/usr/local/lib//liballeg.so: undefined reference to `_poly_zbuf_atex_trans8'
/usr/local/lib//liballeg.so: undefined reference to
`_poly_scanline_atex_mask_lit32'
This is the linker saying "there are symbols in liballeg.so
In the last episode (Mar 02), Andreas Davour said:
> On Wed, 2 Mar 2005, Dan Nelson wrote:
> >In the last episode (Mar 02), Andreas Davour said:
> >>I've tried to compile and link a small game written with the
> >>Allegro API. For some odd reason the linker just don't understand
> >>how to resolve
On Wed, 2 Mar 2005, Dan Nelson wrote:
In the last episode (Mar 02), Andreas Davour said:
I've tried to compile and link a small game written with the Allegro
API. For some odd reason the linker just don't understand how to
resolve the symbols in the library. It just can't accept that the
library is
In the last episode (Mar 02), Andreas Davour said:
> I've tried to compile and link a small game written with the Allegro
> API. For some odd reason the linker just don't understand how to
> resolve the symbols in the library. It just can't accept that the
> library is in a ".so" file and not an ".
Hi!
I've tried to compile and link a small game written with the Allegro
API. For some odd reason the linker just don't understand how to resolve
the symbols in the library. It just can't accept that the library is in
a ".so" file and not an ".a" archive, and even when I point it out
explicitly
On Thu, Apr 01, 2004 at 12:44:42PM -0800, paul beard wrote:
> In the course of cleaning up this b*rked port installed, I found that
> popt wouldn't install properly. It would report no errors but ports
> that depended on it would bail out, unable to find shlibs.
Yes, that's the same problem we'v
ystem type... i386-unknown-kfreebsd4.9-gnu <-- what's
that all about?
. . . . .
checking dynamic linker characteristics... no
checking if libtool supports shared libraries... no
checking whether to build shared libraries... no
checking whether to build static libraries... yes
. . . .
Cleaning
this difference is the problem on Reineke. How is LIBICONV
generated during the make process? Which part of Reinekes configuration
is the reason that it does not make the shared libraries?
Burkard
--
Burkard Meyendriesch
Stevern 2
D-48301 Nottuln
_
On Thu, Mar 18, 2004 at 07:58:35AM +0100, Burkard Meyendriesch wrote:
> Are there any differences in making ports between i386 STABLE and amd64
> CURRENT? What is going wrong? What can I do to solve this?
Compare the build logs of the openldap port from i386 and amd64; it's
possible the build is
Hi folks,
on my amd64 CURRENT box I cannot install KDE3; the "make install"
complains about missing shared libraries which should have been made
by the ports dependencies: before compiling kdelibs the "make" installs
openldap-client-2.1.27:
# ls -l /usr/local/lib/libldap
Hello,
First a question.
Are you using the ports system, or are you experimenting with building
from source directly?
If the version you want is in ports, you should try that even if you
have to apply a patch manually before building, because then all of the
libtool mess will be taken care of f
ibtool from the ports as I believe libtool has
something to do with shared libraries. It installs OK but I get this warning
during the install process
==
Warning: the command libtool uses to detect shared libraries,
/usr/bin/file, produces output that libtool cannot recognize.
The result is that l
I posted the question below earlier on. Following further research it seems
that libmysqlclient needs the functions provided by -lz but I don't know how to
get that flag into the make file.
So I tried reinstalling mysql323-client and noticed the following warning:
*** Warning: This library needs
Apparently, On Mon, Jun 16, 2003 at 03:39:19PM -0700,
Joe Kelsey said words to the effect of;
> Has anyone ever come across general-purpose tools for modifying shared
> libraries? What I want to do is to edit the list of "needed" shared
> libraries to correct the c
Stijn Hoop wrote:
On Tue, Jun 17, 2003 at 06:38:29AM -0700, Joe Kelsey wrote:
Basically, what I want to do is remove several entries from the *front*
of the dynamic section. Actually, I would settle for just removing all
of a certain tag (such as DT_NEEDED) from the dynamic section.
I'm very
On Tue, Jun 17, 2003 at 06:38:29AM -0700, Joe Kelsey wrote:
> Basically, what I want to do is remove several entries from the *front*
> of the dynamic section. Actually, I would settle for just removing all
> of a certain tag (such as DT_NEEDED) from the dynamic section.
I'm very interested, ha
On Tue, Jun 17, 2003 at 01:02:36PM -0400, Alexander Kabaev wrote:
> On Tue, 17 Jun 2003 09:01:41 -0700
> Marcel Moolenaar <[EMAIL PROTECTED]> wrote:
>
> > On Tue, Jun 17, 2003 at 08:49:23AM -0700, Joe Kelsey wrote:
> > Linux uses the same linker (GNU ld). Fixing the linker will have the
> > same e
In the last episode (Jun 17), Marcel Moolenaar said:
> On Tue, Jun 17, 2003 at 01:02:36PM -0400, Alexander Kabaev wrote:
> > On Tue, 17 Jun 2003 09:01:41 -0700
> > Marcel Moolenaar <[EMAIL PROTECTED]> wrote:
> > > On Tue, Jun 17, 2003 at 08:49:23AM -0700, Joe Kelsey wrote: Linux
> > > uses the same
On Tue, 17 Jun 2003 09:01:41 -0700
Marcel Moolenaar <[EMAIL PROTECTED]> wrote:
> On Tue, Jun 17, 2003 at 08:49:23AM -0700, Joe Kelsey wrote:
> Linux uses the same linker (GNU ld). Fixing the linker will have the
> same effect on Linux as it will have on FreeBSD and hence will prevent
> unnecessary
end to give it
> >and keep the libraries that actually contributed to the link.
> >
>
> I know of no way to do this in the case of shared libraries. When
> linking shared libraries, the linker *cannot* resolve any references to
> other shared libraries other than list them
do this in the case of shared libraries. When
linking shared libraries, the linker *cannot* resolve any references to
other shared libraries other than list them in the .dynamic section with
some sort of tag such as DT_NEEDED. Please explain to me how the linker
can prune the shared library
On Tue, Jun 17, 2003 at 09:13:04AM -0700, Joe Kelsey wrote:
> >>>It's more constructive to fix the linker than it is to patch the
> >>>ELF files created by it. The linker knows which libraries are
> >>>really needed and should be able to create the minimal list of
> >>>(true) dependencies.
> >>
> >
programs using
the library do not have the same requirements. Most often, clueless
programmers reference every single library ever known to them on their
linker command lines in the off-chance that it *might* make a difference
at load time. However, this leads to shared libraries containing
On Tue, Jun 17, 2003 at 08:49:23AM -0700, Joe Kelsey wrote:
> Marcel Moolenaar wrote:
> >On Tue, Jun 17, 2003 at 06:38:29AM -0700, Joe Kelsey wrote:
> >
> >>Basically, what I want to do is remove several entries from the *front*
> >>of the dynamic section. Actually, I would settle for just removi
use a *linux* shared library in a native application.
Have you ever lookad at the flashpluginwarpper port? It provides a
library to perload which intercepts the linux syscalls and translates
them to bsd syscalls to allow linux shared libraries (specifically, the
linux flash library) in n
On Tue, Jun 17, 2003 at 06:38:29AM -0700, Joe Kelsey wrote:
>
> Basically, what I want to do is remove several entries from the *front*
> of the dynamic section. Actually, I would settle for just removing all
> of a certain tag (such as DT_NEEDED) from the dynamic section.
It's more constructi
Brandon S. Allbery KF8NH wrote:
On Mon, 2003-06-16 at 18:39, Joe Kelsey wrote:
Has anyone ever come across general-purpose tools for modifying shared
libraries? What I want to do is to edit the list of "needed" shared
libraries to correct the common mistakes that developers make in
On Mon, 2003-06-16 at 18:39, Joe Kelsey wrote:
> Has anyone ever come across general-purpose tools for modifying shared
> libraries? What I want to do is to edit the list of "needed" shared
> libraries to correct the common mistakes that developers make in
> creating sha
Has anyone ever come across general-purpose tools for modifying shared
libraries? What I want to do is to edit the list of "needed" shared
libraries to correct the common mistakes that developers make in
creating shared objects with large lists of shared libraries.
Specifically,
Is it possible to combine 2 shared libraries into
a single library? I've read the ld(1) man page,
but it isn't clear whether this is possible.
I would like to do
ld -Bsharable -o libX.so libY.so libZ.so
where libY.so are libZ.so are combined into
libX.so.
--
Steve
To Unsubsc
63 matches
Mail list logo