What extension should I use for Golang executable intended to run on OS X?
As far as I understand it is not important because there are user rights as on Linux which make some file executable, but what is the convention if it is not .dmg file, just one executable file, so user knows that it is probably executable?
I don't have OS X. Application is cross-compiled on Linux.
The convention for OSX applications is this: one DMG containing a .app executable and a shortcut to /Applications for the user to drag to. Since you can't do this, I recommend you provide a download to the .app executable directly and instruct users to move it to /Applications on your download site.
This is only true for download-it-run-it applications. For applications which are run via the terminal, simply don't use an extension and use a shebang line to tell what application should be executing the file.
Related
This should be really simple, but I'm having trouble. I want to include some shared Qt libraries with my application in the installation folder so the user doesn't have to download Qt separately. On Windows, this seemed to work fine, but Ubuntu complains about not being to find the Qt libraries when they are in the same folder as the application.
How do I add the installation directory to shared library search path?
I was able to add the installation directory to shared library search path by adding the following lines to the .pro file, which set the rpath of the binary to $ORIGIN (the install folder). I needed to add the location of QT libs on my current machine (/usr/lib/qt5.5 and /usr/lib/qt5.5/lib) so that the project would build in QtCreator.
unix:!macx {
# suppress the default RPATH if you wish
QMAKE_LFLAGS_RPATH=
# add your own with quoting gyrations to make sure $ORIGIN gets to the command line unexpanded
QMAKE_LFLAGS += "-Wl,-rpath,\'\$$ORIGIN\':/usr/lib/qt5.5:/usr/lib/qt5.5/lib"
}
(The unix:!macx line makes it apply to linux only)
Windows, Linux and OSX behave quite differently. Windows is easiest: dump all the dll's in the application dir. OSX is next and Linux is most difficult.
Linux has certain search paths for searching shared objects. These search paths are mainly system libraries and possibly some user libraries. As you do not want to mess around with system files of your user one would prefer to have the shared objects in the application dir. This is possible but you have to tell Linux to read that directory. You can do this with setting the environment variable LD_LIBRARY_PATH. You can do this with a script. See my answer.
My server is Ubuntu Server 12.04, and my clients are all use Windows.
So I want to build some windows installer for them.
Finally, I found that 7z SelF-eXtracting installer is very easy for me. Ubuntu has p7zip, it can make 7z compress file, and can use sfx module to make windows 7z SelF-eXtracting installer by this command: cat 7zSD.sfx installer_config installer.7z > installer.exe
I downloaded the 7zip extra package to use its sfx modules at http://downloads.sourceforge.net/sevenzip/7z920_extra.7z
Everything is OK. The only problem is how to change the exe icon ? I want my installer have some different icons. Use script or some cli software is better because my server have no X and I want batched operation.
Thank you.
Concatenating data together will seldom generate a valid PE executable unless you modify the PE header to consider that extra data. It might actually "work" right now because the Windows version is forgiving in loading the file and the 7z executable loads the payload from disk but the fact remains that your PE executable is invalid and might not work on some Windows versions.
The good news though is that by using a resource compiler you will solve both your problems: Both the icon and the payload are typically resources so you could have an "empty" 7z executable that you add an icon and your data to using a resource compiler.
I never tried compiling windows executables on Unix, but if I would, I'd look at Wine, IIRC it has a resource compiler that works on Unix.
Update: http://www.winehq.org/docs/winelib-guide/wrc
I don't think, that it's possible.
I would suggest to use nsis.
I want to compile a Haskell program on one Linux box, and then run it on another Linux box. However, this doesn't seem to work at all. I get errors about missing libraries.
Presumably when I install GHC, the package manager also installs all the libraries and stuff that it needs. [I note with some irritation that at least one packaging system fails to install GCC, which GHC apparently can't function without...] But of course, the target system does not have these dependencies installed. So if I copy the compiled binary to the target system, it just fails to run.
Is there some way around this problem? I'm used to working with Windows, where if you compile something, it just works on all Windows systems. (At least, it does until you actually try to use non-standard facilities like database access or something...) I compiled Hello World in Haskell, copied it to another Linux box, and it complained about libgmp.so.10 missing or some cryptic mumbo-jumbo like that.
Just to make things interesting: I only have FTP access to the target machine, not shell access. I'm not even completely sure what OS it's running. So I can change my build machine any way I want, but I can't do anything to the target machine other than copy files to it.
Linux behaves just like Windows in this regard. If you compile a Haskell executable on Linux, it will run on any Linux distribution with the right libraries. The problem is that in Windows, the Haskell executables aren't compiled with a dynamic version of libgmp; they are compiled with a static version (so that the library is compiled into the executable) exactly because it can be so difficult to handle dlls on Windows when distributing executables. It is comparably easy to handle the installation of new libraries on Linux.
What you can do is to copy the libgmp.so.10 (which might be a symbolic link to a different file) out of /usr/lib into the same directory as your executable. You can then set the LD_LIBRARY_PATH environment variable to ".", meaning the current directory, before launching your executable. This will make Linux look for libraries in the same directory as executables that it launches, making it find the library. This can be done with a launcher script:
#!/bin/sh
export LD_LIBRARY_PATH=.
`dirname "$0"`/myexecutable "$#"
Saving this script and marking it as executable with chmod +x myscript will make your executable work.
You can use the ldd command to check what other libraries your executable might need and that aren't on the target system.
If you wish to move executable between machines, you have to link in statically, making single executable without external library dependencies. How to do it depends on compiler, and ghc has -static flag, that 'links static version of haskell libraries'.
btw, check, that you do not try to run 64-bit executable on 32 bit machine. 32-bit executable on 64 bit machine should work in most cases, but... well, it depends on configuration of target box, so check that this is not the case as well.
I have a library that I originally developed for Linux. I am now in the process of porting it to Cygwin. I have noticed that every library on my Cygwin system is installed like this:
DLL (cygfoo.dll) installed to /usr/bin mode 755
Static archive (libfoo.a) installed to /usr/lib mode 644
Import library (libfoo.dll.a) installed to /usr/lib mode 755
The first two make perfect sense to me. DLLs are executables so they should be mode 755. Static archives are not executables, so they are mode 644. The third one, however, seems odd to me. Import libraries are in fact static archives, not executables (ar -t libfoo.dll.a lists the contents of the archive). Shouldn't they also be installed mode 644?
Why is it the convention on Cygwin to install import libraries with mode 755?
Back to 2000:
On NTFS partitions, NT/W2K require the execute permission for DLLs to
allow loading a DLL on process startup.
That's no problem unless a person using ntsec gets a tar archive
packed by a person not using ntsec or packing on a FAT partition.
Since Cygwin fakes the execute permission only for the suffixes "exe",
"bat", "com", DLLs are treated as non executable by the stat() call
when ntsec isn't set.
When a person using ntsec unpacks that tar archive, the start of an
application which requires one of the DLLs from the archive will fail
with the Windows message
"The application failed to initialize properly (0xc0000022)"
which isn't that meaningful for most of the users.
To solve that problem we would have to do a simple step. Fake execute
permissions for DLLs when ntsec isn't set or the file system doesn't
support ACLs (FAT/FAT32).
Here: http://cygwin.com/ml/cygwin-developers/2000-10/msg00044.html
The only answer that occurs to me is that the installer is looking for the ".dll" string in the filename to activate the executable attribute (x) of the copied files... should been looking for /.+\.dll$/ (.dll only at the end).
It is understandable that the impedance mismatch between OS's/filesystems force the installer/copier to have a strategy to decide attribute values at the installer operation (it is easier than have to map a attribute list to the copied file... and in windows only have to look for .exe, .com and .dll)
To confirm this rename your "libfoo.dll.a" to "libfoo.dxx.a" and test it...
This is a Windows requirement: since the .dll file contains code that will be executed, it requires the executable bit to be set.
Remove permission to execute the file, and Windows won't let any of the code inside it be executed, even if the process doing the executing is separate.
Side note: it's a common misconception that there's no +x bit for Windows. That's technically true; Windows doesn't use POSIX rwx permissions, although Cygwin does try to provide an interface that resembles them. Windows does use ACLs (Access Control Lists) for permissions, however, and these do have a concept of "execute permissions", which is what Cygwin maps down to its +x bit.
There's a long discussion on the Cygwin mailing list about this, if you want sources/further reading.
Seems it's just a lazy hack resulting in this behavior for filenames containing ".dll". See hasanyasin's answer for the reasoning behind the "fix" (here).
I am quite new to cygwin. I created a symlink as follows
$ ln -s /var/www /cygdrive/d/foo
and when I check the D drive via windows, I see a system file called foo. Is there a way to make foo act as a folder for Windows instead of a system file?
Windows won't be able to read Cygwin-created symlinks, but you can create Windows symlinks using Windows commands, and Cygwin will treat those as symlinks.
On Vista and 7, this can be done with 'mklink'. This is a cmd.exe builtin rather than a standalone utility, so if you want to invoke it from a bash shell you have to do 'cmd /c mklink', and of course it will only understand Windows paths.
For XP, the 'Windows Resource Kit Tools' contain a utility called linkd that can be used to create directory links.
Not that I know of. Cygwin doesn't update the OS to have symlinks, rather, it allows you to 'fake' symlinks from within the Cygwin shell. You can set up the shell to use Windows LNK files, which may do what you want, but ...
From the Cygwin Documentation:
Creating shortcuts with cygutils
Another problem area is between
Unix-style links, which link one file
to another, and Microsoft .lnk files,
which provide a shortcut to a file.
They seem similar at first glance but,
in reality, are fairly different. By
default, Cygwin does not create
symlinks as .lnk files, but there's an
option to do that, see the section
called “The CYGWIN environment
variable”. These symlink .lnk files
are compatible with Windows-created
.lnk files, but they are still
different. They do not include much of
the information that is available in a
standard Microsoft shortcut, such as
the working directory, an icon, etc.
The cygutils package includes a
mkshortcut utility for creating
standard native Microsoft .lnk files.
But here's the problem. If Cygwin
handled these native shortcuts like
any other symlink, you could not
archive Microsoft .lnk files into tar
archives and keep all the information
in them. After unpacking, these
shortcuts would have lost all the
extra information and would be no
different than standard Cygwin
symlinks. Therefore these two types of
links are treated differently.
Unfortunately, this means that the
usual Unix way of creating and using
symlinks does not work with native
Windows shortcuts.
One alternative way to call mklink (/d creates directory link) without function:
link_name="/cygdrive/c/TestLink"
target_dir="/cygwin/c/Windows"
cmd /c mklink /d "`cygpath -w \"$link_name\"`" "`cygpath -w \"$target_dir\"`"
This example uses backticks (`command`) for command substitution.