Re: [gentoo-portage-dev] RFC: Binary dependency tracking

Re: [gentoo-portage-dev] RFC: Binary dependency tracking

[Jeremy Huddleston]

[-- Attachment #1.1: Type: text/plain, Size: 694 bytes --]

Well, I've glossed over the dlopen() issues for now as I'm not sure the
best way to handle that or even if it needs to be addressed.  How often
does something dlopen() a file if it doesn't know the exact filename at
compile time?  It seems unlikely to me that this kind of dependency
would be introduced which wouldn't be uniquely satisfied by the RDEPEND.
Does anyone know of a case where we'd do something like:

#define LIBPNG_SONAME libpng.so.3 /* set by configure */
dlopen(LIBPNG_SONAME)


In any event, here's a patch to portage which creates the
soname.{PROVIDE,DEPEND} files as well as a small script to create them
where missing.

Please comment.

Thanks,
Jeremy


[-- Attachment #1.2: bindeps.patch --]
[-- Type: text/x-patch, Size: 2921 bytes --]

? ebuild.sh-multilib-pkg
Index: ebuild.sh
===================================================================
RCS file: /var/cvsroot/gentoo-src/portage/bin/ebuild.sh,v
retrieving revision 1.201.2.24
diff -p -u -4 -r1.201.2.24 ebuild.sh
--- ebuild.sh	26 Feb 2005 11:22:37 -0000	1.201.2.24
+++ ebuild.sh	5 Apr 2005 22:21:35 -0000
@@ -1034,26 +1034,49 @@ dyn_install() {
 		UNSAFE=$(($UNSAFE + 1))
 		echo "UNSAFE SetUID: $i"
 	done
 	
-	if [ -x /usr/bin/readelf -a -x /usr/bin/file ]; then
-		for x in $(find "${D}/" -type f \( -perm -04000 -o -perm -02000 \) ); do
-			f=$(file "${x}")
-			if [ -z "${f/*SB executable*/}" -o -z "${f/*SB shared object*/}" ]; then
-				/usr/bin/readelf -d "${x}" | egrep '\(FLAGS(.*)NOW' > /dev/null
-				if [ $? != 0 ]; then
-					if [ ! -z "${f/*statically linked*/}" ]; then
-						#uncomment this line out after developers have had ample time to fix pkgs.
-						#UNSAFE=$(($UNSAFE + 1))
-						echo -ne '\a'
-						echo "QA Notice: ${x:${#D}:${#x}} is setXid, dynamically linked and using lazy bindings."
-						echo "This combination is generally discouraged. Try: CFLAGS='-Wl,-z,now' emerge ${PN}"
-						echo -ne '\a'
-						sleep 1
+	if [[ -x /usr/bin/readelf ]] ; then
+		if [[ -x /usr/bin/file ]] ; then
+			for x in $(find "${D}/" -type f \( -perm -04000 -o -perm -02000 \) ); do
+				f=$(file "${x}")
+				if [[ -z "${f/*SB executable*/}" || -z "${f/*SB shared object*/}" ]]; then
+					if ! /usr/bin/readelf -d "${x}" | egrep '\(FLAGS(.*)NOW' > /dev/null ; then
+						if [[ ! -z "${f/*statically linked*/}" ]] ; then
+							#uncomment this line out after developers have had ample time to fix pkgs.
+							#UNSAFE=$(($UNSAFE + 1))
+							echo -ne '\a'
+							echo "QA Notice: ${x:${#D}:${#x}} is setXid, dynamically linked and using lazy bindings."
+							echo "This combination is generally discouraged. Try: CFLAGS='-Wl,-z,now' emerge ${PN}"
+							echo -ne '\a'
+							sleep 1
+						fi
 					fi
 				fi
-			fi
-		done
+			done
+		fi
+		
+		if hasq bindeps ${FEATURES} ; then
+			> ${BUILDDIR}/build-info/soname.DEPEND
+			> ${BUILDDIR}/build-info/soname.PROVIDE
+			for file in $(find "${D}/" -type f) ; do
+				local f=$(file ${file})
+
+				if [[ -z "${f/*SB executable*/}" || -z "${f/*SB shared object*/}" ]]; then
+					local soname=$(readelf -d ${file} | grep SONAME | sed 's/^.*\[\(.*\)\].*$/\1/')
+					local depend=$(readelf -d ${file} | grep NEEDED | sed 's/^.*\[\(.*\)\].*$/\1/')
+					
+					if [[ -n ${soname} ]] ; then
+						echo "${soname} ${file/${D}/}" >> ${BUILDDIR}/build-info/soname.PROVIDE
+					fi
+
+					local dep=
+					for dep in ${depend} ; do
+						echo "${dep} ${file/${D}/}" >> ${BUILDDIR}/build-info/soname.DEPEND
+					done
+				fi
+			done
+		fi
 	fi
 
 	if [[ $UNSAFE > 0 ]]; then
 		die "There are ${UNSAFE} unsafe files. Portage will not install them."

[-- Attachment #1.3: mkbindeps.sh --]
[-- Type: application/x-shellscript, Size: 834 bytes --]

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] RFC: Binary dependency tracking

[Brian Harring]

On Tue, Apr 05, 2005 at 03:38:24PM -0700, Jeremy Huddleston wrote:
> Well, I've glossed over the dlopen() issues for now as I'm not sure the
> best way to handle that or even if it needs to be addressed.  How often
> does something dlopen() a file if it doesn't know the exact filename at
> compile time?
>  It seems unlikely to me that this kind of dependency
> would be introduced which wouldn't be uniquely satisfied by the RDEPEND.
> Does anyone know of a case where we'd do something like:
> 
> #define LIBPNG_SONAME libpng.so.3 /* set by configure */
> dlopen(LIBPNG_SONAME)
kdelibs apps abuse it afaik.
rekall, fex, loads all drivers dependant on config files, all at 
runtime via abstracted dlopen trickery....

> 
> In any event, here's a patch to portage which creates the
> soname.{PROVIDE,DEPEND} files as well as a small script to create them
> where missing.
> 
> Please comment.
Not liking it in bash personally, but that's me (already implemented 
code akin to this in dblink.treewalk).

What about the resolver mods?
~brian
--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] RFC: Binary dependency tracking

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1452 bytes --]

On Wednesday 06 April 2005 00:38, Jeremy Huddleston wrote:
> Well, I've glossed over the dlopen() issues for now as I'm not sure the
> best way to handle that or even if it needs to be addressed.  How often
> does something dlopen() a file if it doesn't know the exact filename at
> compile time?  It seems unlikely to me that this kind of dependency
> would be introduced which wouldn't be uniquely satisfied by the
> RDEPEND. Does anyone know of a case where we'd do something like:

In general dlopen is used for plugins. Dlopen allows to define library 
requirements at runtime. Often these requirements are optional in the 
case of plugins and the like. With plugins the name of the plugin is 
often unknown. For required dependencies where the name is allready known 
in advance it doesn't really make sense to use dlopen which is a lot more 
complex than a normal link.

If you look at kde it massively uses plugins. One of the tricks that is 
played is caused by the fact that the kde and qt libraries are massive 
(take quite a time to load) and shared by most kde applications. The 
trick is then to run a process (kdeinit) that is allready loaded and have 
this process fork and let the fork load the actual application as plugin. 
This result in faster load times even (especially) in absense of 
prelinking.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]