[csw-maintainers] GAR: isaexec symlink loop

Maciej (Matchek) Blizinski maciej at opencsw.org
Mon Dec 28 17:05:24 CET 2009


I ran a MySQL 5.0 build and I've taken a look at the symlink/isaexec structure.

> grep mysqlimport work/solaris8-sparc/build-global/CSWmysql5client.prototype-sparc
s none /opt/csw/bin/mysqlimport=../mysql5/bin/mysqlimport
l none /opt/csw/mysql5/bin/mysqlimport=/opt/csw/bin/isaexec 0755 root bin
f none /opt/csw/mysql5/bin/sparcv8/mysqlimport=/opt/csw/mysql5/bin/mysqlimport
0755 root bin
f none /opt/csw/mysql5/bin/sparcv9/mysqlimport 0755 root bin
f none /opt/csw/mysql5/share/man/man1/mysqlimport.1 0644 root bin

Let's consider a sparcv8 system.  We want to execute "mysqlimport".
/opt/csw/bin/mysqlimport is a symlink to
/opt/csw/mysql5/bin/mysqlimport, which is a symlink to
/opt/csw/bin/isaexec, which will attempt to execute
/opt/csw/mysql5/bin/sparcv8/mysqlimport.  All would be good if
/opt/csw/mysql5/bin/sparcv8/mysqlimport was a binary, but it's a
symlink to /opt/csw/mysql5/bin/mysqlimport (which is a symlink to
isaexec).  It looks to me as if there was a circle of symlinks.
Isaexec would basically try to run itself.

The sparcv9 binary runs fine, because
/opt/csw/mysql5/bin/sparcv9/mysqlimport is an actual binary, not a
symlink.

Dago, what do you think?  Is there a problem during merge?

The code is at https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/mysql5/branches/mysql-5.0.x

Maciej



More information about the maintainers mailing list