Hi, On Fri, Dec 13, 2013, [email protected] wrote: > > Sorry I did not provide details: > > Building environment: Microsoft XP SP3 (Japanese Home Edition) > > Fetech http://win-builds.org/stable/win-builds-bundle-1.3-beta3.zip > Into local download dir: ..some_path/win-builds > > Started cmd.exe > Changed directory the ..some_path/win-builds > > #did > set YYPREFIX=C:/win-builds-32 > yypkg -init > yypkg -config -setpreds host="i686-w64-mingw32" > yypkg -config -setpreds target="i686-w64-mingw32" > sherpa -set-mirror http://win-builds.org/1.3-beta3/packages/windows_32 > sherpa -install all > > ################################# the below is what I earlier sent > cat fa wrote: > > When I did sherpa -install all, nothong was downloaded. > > When I ran: > $ sherpa -install all > > It installed nearly everthing I think. Hoever, it aborted with the followi= > ng error message. > -------- #1 > Installing gtk+2-2.24.20-1-i686-w64-mingw32.txz...mklink > ... external command ( original was in Japanese char set so I added english ) > ... not recognized as an executable or batch file. > Fatal error: exception Failure(""mklink /J > \"doc/gtk+-2.24.20/gail-libgail-util\ > " \"doc\\gtk+-2.24.20/../../share/gtk-doc/html/gail-libgail-util\"" returned 1 > .") > -------- > > Also there were numerous messages related to "skipping" symbolic links whic= > h I don't > know if these are important or not. There presence did not halt the insta= > ll process. > --------#2=20=20 > Installing fontconfig-2.10.93-1-i686-w64-mingw32.txz...Skipping symlink > "etc/fon > ts/conf.d/10-scale-bitmap-fonts.conf" -> > "../../../../../../../opt/windows_32/et > c/fonts/conf.avail/10-scale-bitmap-fonts.conf": ENOENT > Skipping symlink "share/fontconfig/conf.avail" -> > "../../../../../../opt/windows > _32/etc/fonts/conf.avail": ENOENT > DONE > --------
There are two issues here: - symlink fallback on windows - Windows XP and symlink fallback tl;dr: don't mind the warnings, they're harmless; Windows XP support is an issue (but at least read the last paragraph) Full explanation below. Since the package is a *native* windows executable, it cannot do POSIX symlinks. Win32 symlinks are slightly different and also have several issues which make them not usable. The approach to provide something equivalent to how symlinks are used inside packages is: - build on linux - before building the package, build a list of symlinks and store the filetype of the target: directory, regular file or unknown (unhandled) - build the package with the symlinks excluded - when installing, extract the files from the package - if on windows, emulate symlinks with: - hardlinks for links to regular files - directory junctions for links to directories - skip and print a message for unknown ones The "Skipping symlink" line is because of that last case. The additional ENOENT means that the type of the target is unknown because the symlink was broken when creating the package (it might be not-broken when actually installed but it's not something that is handled yet). I've checked again all of the "unhandled" symlinks and I see none that break functionality. The breakdown is roughly: - gfortran-related symlinks which shouldn't exist reported as http://win-builds.org/bugs/index.php?do=details&task_id=15 - symlinks inside "share/doc" - the fontconfig ones you've seen above; I'm not sure they matter but I'll check - a symlink from /lib/cpp to /usr/bin/cpp which probably only matters to linux distributions Currently, symlinks to directories are handled through a tool named "mklink.exe". It is a command-line tool to create hardlinks, symlinks and directory junctions but it is not on Windows XP. The quick-and-easy solution is to copy that file from another machine but it's not something I can redistribute myself. The other solution is that yypkg stops using mklink.exe. This wasn't done before because writing some C (yypkg isn't written in C) is required in order to access some very win32-specific APIs to both create and delete directory junctions. It's not very difficult; it's simply something that hasn't been done yet. This is actually also required because calling unlink() on directory junctions fails with EPERM (cmd.exe's del and msys1's rm happen to also fail removing directory junctions; explorer does it fine). The corresponding item in the bug tracker is: http://win-builds.org/bugs/index.php?do=details&task_id=13&project=2 (NB: version "1.7" and "1.8" are yypkg versions, not win-builds one) With that said, I don't know how much attention should be given to Windows XP nowadays. It's going to not be updated by MS anymore in 4 months and I wasn't really expecting someone on this mailing-list to still use Windows XP on a daily basis to be honest. I'm going to fix the aforementionned issue. However I don't know how much attention should be given to this OS and that's because I don't know how many people are still using it _and_ also using newly-built software on it. If you use XP or if you have people using your software and still using XP, please let me know. -- Adrien Nader ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
