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
On Tue, 18 Dec 2012 12:40:39 + (UTC)
Walter Hurry walterhu...@gmail.com 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
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
/libexec/ld
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 test01.x
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 test01.x
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 to test shared libraries, so I do
% gfortran45
.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 libslatec.so.1 not found, required by
test01.x
%
How can I tell the executable to look for a shared library
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 thing
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 libraries.
I'd welcome
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 hint
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'd
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.
Link your program
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 time
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/lib/libcups.so.2
# ldd /usr/lib/libcups.so.2
/usr/lib
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
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.
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.so.62
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 tinderbox
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.bz2
# cd
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)
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
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
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
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
On Thu, Mar 16, 2006 at 03:16:57AM -0500, [EMAIL PROTECTED] wrote:
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
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's
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
starting
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 possible?
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?..
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
On one of my two 4.11 boxes, kdelibs fails to build. Here's the output:
snip
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
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 it
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 .a
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
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 the symbols
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
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 out the work
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've
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
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo
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*
-rw-r--r-- 1 root wheel
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
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
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
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 libtool may fail
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,
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
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 common mistakes
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
creating
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 constructive
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 native
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 removing all
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
references
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.
This cannot be
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 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
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 in the .dynamic section with
some sort of tag
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
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 linker (GNU
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 effect on
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, I want
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 shared objects with large lists
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 Unsubscribe: send
62 matches
Mail list logo
