symlink() is not supported in Vxworks.
Is there any other way to create a symbolic link in Vxworks ?
Most VxWorks filesystems don't even support symlinks, so VxWorks doesn't provide any means of creating them. If you have a filesystem which does support symlinks (and already contains some), then VxWorks can read and follow those links.
Related
Is it possible to compile mod_go.c successfully and produce the Apache module (mod_go.so) for GOLANG in Windows environment?
Unfortunately i can not find any detailed instructions such as type of C++ compiler, apache version etc as well as what steps i have to follow?
Regards
Probably that is not possible, but I leave you to check.
Go plugins are only supported on Linux. So if you absolutely need to code Apache modules in Go (which requires dynamic loading of shared object produced by the Go compiler, that is a plugin coded in Go), you'll better switch to Linux. BTW the linker model of Windows is very different from Linux, so it won't change easily and I won't be surprised that Go won't have plugin on Windows for a few years.
Linux dlopen(3) (actually a POSIX feature) and its shared libraries (ELF shared objects, containing position-independent code) are very different from Windows LoadLibrary and DLLs.
Read Levine's Linkers and Loaders book and (for Linux) Drepper's paper How To Write Shared Libraries
So if you badly need to write this year (e.g. before the end of 2018) a plugin in Go to be used by Apache, I strongly recommend switching your Apache server machine to Linux.
BTW, it looks like your mod_go don't use Go plugins (but communicate with some external process, I leave you to study its source code, I only glanced into it) Perhaps using FastCGI could be simpler, since Go has FastCGI support. Probably Windows' Apache could be configured to talk to some FastCGI application (notice that FastCGI is not CGI).
(I don't know Windows, never used it, but read a few things about its weird -and IMHO inferior to Unix- linking model)
In my experience, most software for OS X that installs cli components installs to /usr/local/ and then creates symbolic links to executables in /usr/local/bin/, as not to modify my $PATH. However, the Go installer differs in approach by creating a new entry in /etc/paths.d/ for path_helper to read and then modify my $PATH. Can someone please explain the thinking behind this design decision? Is it more common on Linux to have a lot of path additions instead of symbolic links to executables in an existing directory?
I'd love to get a better understanding of why this choice. I have never seen another software take this approach.
From this thread, the path_helper (source) is:
because automatic software installation (and what's more important UNinstallation) is much easier this way. Many Linux distros switch to .d directories for many configuration files (Apache 2.0 was AFAIK the first program to support this kind of stuff) because it makes administration much easier.
The Uninstall Go section does mention:
If you installed Go with the Mac OS X package then you should remove the /etc/paths.d/go file.
Those files in /etc/paths.d are processed in order (so you can manage PATH order as opposed to symlinks in /usr/local/bin).
Note that path_helper is only called by login shells, not by non-interactive shells.
Sorry for using an answer; I don't have enough reputation points to comment. ((which seems backwards to me))
#jsejksn says "I have never seen another software take this approach."
My /etc/paths.d contains entries for Xquartz, CrossPack-AVR, aria2c and go. From reading google'd articles about /etc/paths.d, I see that ImageMagik also adds an entry to /etc/paths.d.
I'd guess that it's an easy way to let users run binaries without having to mess around with amending the PATH in their own profile scripts, or lose track of symlinks, or whatever.
Maybe sym-links is more of a Gnu thing, while /etc/paths.d is more of a BSD thing?
Personally, I like it.
I can open, close, create files and directories using the Zw* functions available for Windows Kernel services. I can even open the underlying symbolic link object using ZwOpenSymbolicLinkObject, but I can't seem to actually make symbolic links.
It seems this level of the API is not aware of symbolic links, so how would I go about using this (filesystem!) feature without the Win32 API?
There isn't direct API to create reparse points.
You need to use ZwFsControlFileZwFsControlFile() to send FSCTL_SET_REPARSE_POINT ioctl with appropriate input buffers and parameters.
Don't have example though!
I am asking here because I have no idea where to find any information about this problem. If you could recommend me a book or an article about it, I would be pleased.
Where can I find any information about correlation between Linux kernel and GLIBC's version? I know that, the kernel itself contains implementation of libc's functions, but I do not know, how they are delivered to it.
For example:
Recently I had to build the kernel for an old PowerPC processor. It came with libc's dynamic library files in version 2.3.6 out-of-the-box. In /lib/ path there are files with names like librt.so-2.3.6.
What is the simplest way to update this lib to a newer version?
Is it possible to configure kernel's build system to make it generating uImage file with a newer GLIBC version or an alternative one (ex. EGLIBC)?
There is little correlation, the same kernel should work with a wide range of glibc versions, and viceversa. The library finds out what the kernel handles, and uses that. For the gory details of what has changed in glibc (this is what you interact with, including support for new kernel features), you should look at the upstream changelog. For new features in the Linux kernel, perhaps the best source are the periodical "What's new in..." articles the kernel section of LWN
I'm porting C/C++ code from Unix to Windows that makes use of the symlink() function.
From what I understand, recent Windows file systems have a equivalent of symbolic links.
What would be the best / most portable way replace the symlink() function, so the same code works on both platforms ?
Since Windows Vista there's a function to create true symbolic links: CreateSymbolicLink
Note that Junctions as mentioned in the other answers only support directories, and even with the newer feature, windows symbolic links require you to specify whether the target is a directory or a file. So you won't necessarily be able to get a trivial "drop-in replacement" symlink() function.
The underlying technology on Windows is called Junction points. The Boost Filesystem Library is cross platform and can make symlinks:
http://www.boost.org/doc/libs/1_46_1/libs/filesystem/v3/doc/reference.html#create_symlink
Junctions seem to be the answer from similar questions .