Thanks for your patience
Alexis Papadopoulos
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ge in this case.
It doesn't, and the modification isn't very important so it isn't a problem. But
that was only an example, but the body of g can be modified in a way where it
could lead to a failure (because of the use of templates), therefore the SONAME
muste be changed
the .so library but in prgm itself.
According to the upstream author, since the template (class T) isn't known, we
cannot insert the code of g into the library (which seems normal).
My programming skills are limited, therefore I'm doing my best to explain
myself, hope it was clear enough.
> Is this shared library actually used by other programs? Or only
> within the internal use of this particular project? If the latter
> then I would avoid packaging it as a shared library at all. If the
> shared library is not used by other programs then I would covert the
> build to link the pr
een made to the library's source files,
SONAME is increased, sources version is always incremented. The SONAME
will be (as inspired from libginac) in the following form :
lib*-X.Y.so.0.0.0 (the ending 0.0.0 because of libtool's usage)
or maybe lib*.so.XY (format that is used today by the upst
It's a single headache for the one library developer/packager, as
opposed to headaches for _every user_ of the library.
Yes indeed, but it's still a headache for one person ;).
You might want to have a look at the debian-mentors archives, too. I believe
this sort of thing gets discussed th
have to see with him in order to find a solution because
I think that having a (in libtool's vocabulary) current version of 513
isn't really acceptable...
Alexis Papadopoulos
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
und and only the link libname.so is updated. What
happens now if I update this shared library without recompiling the
software that was linked agains the old version ?
Thanks in advance for your comments
Alexis Papadopoulos
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of &qu
Hello again,
I changed the debian/rules of the flac source package, adding a
--disable-fast-install at the parameters passed to the configure script
and it fails! Well, fails, it doesn't link the libraries as expected. So
that's good news, I found the solution to my first problem.
The weird
Hello,
I unfortunately deleted all my control files in an attempt to make a
"fresh" start, but created a very simple debian/rules so as to test if
the --enable-fast-install solved my problem, here it is :
#!/usr/bin/make -f
# -*- makefile -*-
# Sample debian/rules that uses debhelper.
# This
While looking for a solution I realized that it had something to do with
the libtool that was generated in the top_builddir. If I used
/usr/bin/libtool the -rpath was correct. So with some help from `diff` I
found out what seemed to be a cause, enable-fast-install must be enabled.
I'm trying n
ve it but with no luck, I could only append
a second --rpath to the end of the command, which was of course ignored.
I'm not quite sure what to do now, I'll try to use flac sources to find
a way out...
Thanks for helping...
Alexis Papadopoulos
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
hor sources are available at :
https://gna.org/projects/rheolef
I will give you a link with the control files I'm using by tomorrow.
Thanks for helping me out.
Alexis Papadopoulos
-
envoyé via Webmail/IMAG !
--
To UNSUBSCRIBE, email
would like to know if it's possible to avoid this method, by using
'libtool install' and just forcing it to link against /usr/lib/lib*.so
Hope I was clear enough, thanks in advance
Alexis Papadopoulos
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
14 matches
Mail list logo
