Missing Library Symlinks with new2dir

[OscarTalks]

When compiling and installing and creating a .pet package I am finding this problem with newer Puppies such as BionicPup32, ScPup32 and BusterPup (32bit).

Although the full set of dynamic libraries (including the symlinks) are installed into the system, the symlinks are NOT copied into the new directory tree. This means that they will be missing from the .pet package unless you are aware and add them manually.

Are others experiencing this or just me?
Does anyone have an idea of where to look for a fix?

As an example, see below the images of libraries when installing libwavpack.
Compare DpupStretch with BionicPup32
Using configure; make; new2dir make install
Note the missing symlinks in the "new dir" in BionicPup32

[watchdog]

I beg your pardon for my ignorance. I have noticed that slackware packages have install scripts which create those symlinks. So I ask: is it a new2dir's issue or a dir2pet's issue?

[OscarTalks]

Hello watchdog,

I am observing the missing symlinks in the new directory tree after running new2dir make install, before running dir2pet, so this is a change of behaviour of new2dir I think, although maybe the new2dir script itself is not the issue, perhaps some function that new2dir is calling? This is just using autotools, GNU make, gcc and Puppy scripts to compile from source, not involving any Slackware scripts. I have tried a few substitutions but no success yet.

[watchdog]

I have googled and I have understood that symlinks are a product of the make file. The needed symlinks must be created at the packaging of the software stage if they are not already created. Slackware txz packages have a doinstall script for this. Debian packages already have the symlinks in the right dirs so they are only copied at the installing time. I think that all depends on the source of software you are compiling. A source file for debian is different from a source file for slackware. So I have understood.

[OscarTalks]

The origin of the symlinks probably is in the Makefile and they are being created and installed in the system correctly by "make install"

The new2dir script is a BK Puppy-specific script and what it should do (using installwatch I think) is monitor and observe all files and directories installed by "make install" and then make copies of all of them within the new directory tree which can then be used to create the .pet package.

All I am doing is following the standard Puppy steps for compiling (most are generic in fact). It all works as it has done for years and through several Puppies, but now if I try to repeat the exact same steps in a very new Puppy the symlinks are missing from the new dir. It is the switch to a very recent WoofCE build that is introducing the problem.

In the past, new2dir observed that these symlinks were being installed, now new2dir appears to be failing to make this observation and I don't know why.

There is this section of code in new2dir:-

Code: Select all

sync
#pick up created symlinks...
cat /tmp/pkginstall.list | grep '#success$' | tr -s '\t' | tr '&' ' ' | tr '\t' '&' | grep '^0&symlink&' | grep --extended-regexp -v '&/dev/tty&|&/dev/null&|&/root/\.packages/|&/tmp/|&/root/\.icewm/|&/proc/|&/sys/|DotPupTmpDir|/\.myownmenuerc' | grep -E -v '&/initrd|&/mnt/' | cut -f 4 -d '&' >> ${RELPATH}/${EXE_PKGNAME}.files

which may have some connection, not sure.

[watchdog]

I can confirm the bug. I have compiled WavPack-git2019 in stretch: "new2dir make install" makes the symlinks. Then I have compiled the same source in ScPup 19.09+3: "new2dir make install" does not make the symlinks. I tried to install installwatch from stretch: same result.

[peebee]

Github Woof-CE history shows there haven't been any changes to new2dir itself since Sept 2018.....

https://github.com/puppylinux-woof-CE/w ... in/new2dir

[watchdog]

I have found:

https://bug-coreutils.gnu.narkive.com/y ... k-symlinks

In ScPup 19.09+3 reverting to coreutils from slackware 14.2 the problem is solved.

[peebee]

I have found:

https://bug-coreutils.gnu.narkive.com/y ... k-symlinks

In ScPup 19.09+3 reverting to coreutils from slackware 14.2 the problem is solved.

That bug report is 10 years old!!!!

[watchdog]

I repeat:

reverting to coreutils from slackware 14.2 the problem is solved in ScPup 19.09+3. I haven't done more tests. When compiling I have to install a coreutils compatible with installwatch in a dedicated savefile. The bug reported by OscarTalks is true. I have tried to compile installwatch-0.7.0beta7 from:

https://github.com/lunar-linux/installwatch

But no success.

[peebee]

We don't seem to have gotten anywhere with this..... I did report it and the discussion was:

http://wmsgs.boards.net/thread/27/coreu ... nks?page=1

[Dry Falls]

I repeat:

reverting to coreutils from slackware 14.2 the problem is solved in ScPup 19.09+3. I haven't done more tests. When compiling I have to install a coreutils compatible with installwatch in a dedicated savefile. The bug reported by OscarTalks is true. I have tried to compile installwatch-0.7.0beta7 from:

https://github.com/lunar-linux/installwatch

But no success.

I compiled the same installwatch under Lighthouse (slackware64-current and same source) and, although it compiled fine, the script was no good. I slipped in the installwatch script from slacko64-700 to /usr/local/bin/installwatch and the old (jemimah 2012-13) new2dir works fine. This is with the new/current core-utils.

df

[BarryK]

The problem of missing symlinks is ancient history, you should not be getting that problem now.

The latest versions of EasyOS, Pyro 1.2.7 and Buster 2.1.7 (latter built with Debian 10 DEBs) have installwatch 0.7.0beta7 with patches, see here:

https://github.com/bkauler/oe-qky-src/t ... stallwatch

new2dir works ok.

Note, the new2dir in EasyOS is old, last modified in 2015, and the one in woof-CE has diverged considerably.

If you want to try my installwatch, here is a binary, x86_64:

http://distro.ibiblio.org/easyos/amd64/ ... -64.tar.xz

i686 binary:

http://distro.ibiblio.org/easyos/x86/pa ... 686.tar.xz

[BarryK]

I repeat:

reverting to coreutils from slackware 14.2 the problem is solved in ScPup 19.09+3. I haven't done more tests. When compiling I have to install a coreutils compatible with installwatch in a dedicated savefile. The bug reported by OscarTalks is true. I have tried to compile installwatch-0.7.0beta7 from:

https://github.com/lunar-linux/installwatch

But no success.

I compiled the same installwatch under Lighthouse (slackware64-current and same source) and, although it compiled fine, the script was no good. I slipped in the installwatch script from slacko64-700 to /usr/local/bin/installwatch and the old (jemimah 2012-13) new2dir works fine. This is with the new/current core-utils.

df

For comparison, here is the new2dir that I have in EasyOS, see attached. Remove the false .gz, set permissions to executable, and place at /usr/bin

As I mentioned, it is old, last change in 2015, but continues to work fine for me.

Not suggesting that you use it ongoing, just posting it for comparison, so you can narrow down how the symlinks are getting lost.

[Dry Falls]

Thanks Barry. This is the diff in new2dir. I see the improvement... I'm going to use it.

Code: Select all

12a13,14
> #150111 improve dev, nls split for qt4.
> #151003 detect cpu type.
78a81,84
> #151003
> CPUHOST="$(uname -m)"
> [ "$CPUHOST" == "x86_64" ] && CPUHOST='amd64'
> 
86,87c92,93
< echo "If you have compiled for a i486, just press ENTER key."
< echo "Otherwise, enter the CPU type, examples: i386 i486 i686 (the i is required)."
---
> echo "If you have compiled for a ${CPUHOST}, just press ENTER key." #151003
> echo "Otherwise, enter the CPU type, examples: i386 i486 i686 amd64"
90c96
< [ "$CPUTYPE" = "" ] && CPUTYPE="i486"
---
> [ "$CPUTYPE" = "" ] && CPUTYPE="${CPUHOST}"
242a249,255
>   #150111 qt4:
>   if [ "`echo -n "$ONEFILE" | grep '/translations/'`" != "" ];then
>    mkdir -p "${NLS_TARGETDIR}/${ONEPATH}"
>    cp -af "$ONEFILE" "${NLS_TARGETDIR}/${ONEPATH}/" 2>/dev/null
>    [ $? -ne 0 ] && fixfilelistfunc "$ONEFILE"
>    continue
>   fi
285c298,305
<   fi  
---
>   fi
>   #150111 qt4:
>   if [ "`echo -n "$ONEFILE" | grep '/mkspecs/'`" != "" ];then
>    mkdir -p "${DEV_TARGETDIR}/${ONEPATH}"
>    cp -af "$ONEFILE" "${DEV_TARGETDIR}/${ONEPATH}/" 2>/dev/null
>    [ $? -ne 0 ] && fixfilelistfunc "$ONEFILE"
>    continue
>   fi

df