[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