Welcome to the Tiny Core Linux Wiki at tinycorelinux.net!

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

wiki:creating_extensions [2017/06/02 07:14]
JustinCB updated some of the information for recent versions of tinycore
wiki:creating_extensions [2018/07/12 06:25] (current)
JustinCB
Line 62: Line 62:
 export LDFLAGS="-Wl,-O1" export LDFLAGS="-Wl,-O1"
 </code> </code>
-It is OK to use lower architectures in -march and -mtune than the recommended(-march=i386 is OK, and -mtune=i586 and -mtune=i486 and -mtune=i386), however it is not OK to use higher architectures in -march and not recommended to use higher architectures in -mtune (eg. -march=i586).  +It is OK to use lower architectures in -march and -mtune than the recommended(-march=i386 is OK, and -mtune=i586 and -mtune=i486 and -mtune=i386), however it is not OK to use higher architectures in -march and not recommended to use higher architectures in -mtune (eg. -march=i586).  It isn't necessary to use "-pipe" and if you get an error about -Wl you can omit it.  You might be able to specify a different -O value to LDFLAGS and you might be able to use "-Oz" in the place of "-Os" but that may only work for "clang" &amp; not "gcc"
  
 Suggested compiler flags on x86_64 (for compatibility; see also [[http://forum.tinycorelinux.net/index.php/topic,14397.0.html|the forum thread]]): Suggested compiler flags on x86_64 (for compatibility; see also [[http://forum.tinycorelinux.net/index.php/topic,14397.0.html|the forum thread]]):
Line 70: Line 70:
 export LDFLAGS="-Wl,-O1" export LDFLAGS="-Wl,-O1"
 </code> </code>
 +Again, "-pipe" isn't necessary &amp; if you get an error about "-Wl" you can leave it out
  
 Suggested compiler flags on RPi (discussed in [[http://forum.tinycorelinux.net/index.php/topic,17059.0.html|this forum thread]]): Suggested compiler flags on RPi (discussed in [[http://forum.tinycorelinux.net/index.php/topic,17059.0.html|this forum thread]]):
Line 77: Line 78:
 export LDFLAGS="-Wl,-O1" export LDFLAGS="-Wl,-O1"
 </code> </code>
 +Again, "-pipe" isn't necessary &amp; if you get an error about "-Wl" you can leave it out
  
 If you wish to try to get a lower sized C++ app, you can try adding "-fno-exceptions -fno-rtti" to CXXFLAGS. Use only on C++ applications, libraries should use the same flags as in CFLAGS above. If you wish to try to get a lower sized C++ app, you can try adding "-fno-exceptions -fno-rtti" to CXXFLAGS. Use only on C++ applications, libraries should use the same flags as in CFLAGS above.
Line 82: Line 84:
 For apps that do not use threads (pthread_cancel), the following flag reduces binary size: "-fno-asynchronous-unwind-tables". For apps that do not use threads (pthread_cancel), the following flag reduces binary size: "-fno-asynchronous-unwind-tables".
  
-For apps that need speed (math library or so), you can use "-O2" flag instead of "-Os" flag.+For apps that need speed (math library or so), you can use "-O2" flag instead of "-Os" flag.  The "-Oz" flag is not portable but you can use it if you're compiling with "clang"(CC="clang" and CXX="clang").  It gives smaller binaries than "-Os".
  
 Flags Not-allowed (good performance, but likely won't work on other machines): Flags Not-allowed (good performance, but likely won't work on other machines):
Line 106: Line 108:
 </code> </code>
  
-Note: "-j3" is meant for a 2 processor system.  The general guideline is -jN where N is 1 more than the total number of processors available, unless you are on a system that supports hyperthreading(which means that the each of the physical processors acts like 2 virtual processors[because the processor does multitasking and so can run 2 processes "at once"]).  If your system uses hyperthreading, use the number of physical plus the number of virtual processors.  +Note: "-j3" is meant for a 2 processor system.  The general guideline is -jN where N is 1 more than the total number of processors available, unless you are on a system that supports hyperthreading(which means that the each of the physical processors acts like 2 virtual processors[because the processor does multitasking and so can run 2 processes "at once"]).  If your system uses hyperthreading, use the number of physical plus the number of virtual processors(usually twice the physical processors).  
  
 Create/update a date marker just in case your app doesn't support DESTDIR: Create/update a date marker just in case your app doesn't support DESTDIR:
Line 130: Line 132:
 ===== All extension creators please note =====  ===== All extension creators please note ===== 
  
-If you don't need a startup script, then skip the next section. The TC system will create empty tce.installed/package_name files. You can ask for help IRC or on the tce Q&A if you are having issues getting your script working ok.  You may wish to see how others have done it, for x86 see http://www.tinycorelinux.net/8.x/x86/tcz/src/ or whatever version you have(If you have a newer or older version, replace 8.x with the version you have).  +If you don't need a startup script, then skip the next section. The TC system will create empty tce.installed/package_name files. You can ask for help IRC or on the tce Q&A if you are having issues getting your script working OK.  You may wish to see how others have done it, for x86 see http://www.tinycorelinux.net/8.x/x86/tcz/src/ or whatever version you have(If you have a newer or older version, replace 8.x with the version you have and/or x86 with your architecture).  
  
 == gutmensch provides the following set of rules: == == gutmensch provides the following set of rules: ==
Line 268: Line 270:
 It is easy to leave out a required dependency from your .dep file. Do use base norestore, and check the dependencies in particular.   It is easy to leave out a required dependency from your .dep file. Do use base norestore, and check the dependencies in particular.  
  
-If you are planning on submitting your extension for inclusion in the repository,  you should run the extension auditing script, which is in the repository as submitqcx.tcz(replace x with the version number of your system, but note that a new submitqcx.tcz extension does not always come out right away when a new version of tinycore, so you might need to use the previous version when a new version has just been released).  submitqc.tcz is a script that does more robust checking, but almost always throws many more warnings/errors submitqc.tcz is the ONLY extension audit script for picore and corepure64(as the submitqcx.tcz extensions are[currently] x86 only).   +If you are planning on submitting your extension for inclusion in the repository,  you should run the extension auditing script, which is in the repository as  submitqc.tcz .
 =====  Separation =====   =====  Separation =====  
  
Line 276: Line 277:
   * move documentation and help files into a doc extension (myprogram-doc.tcz)      * move documentation and help files into a doc extension (myprogram-doc.tcz)   
   * rather than including docs in your extension, use the info file to list official online docs.     * rather than including docs in your extension, use the info file to list official online docs.  
 +  * move headers and static libraries to a dev extension(myprogram-dev.tcz)
  
 ===== Required Files =====   ===== Required Files =====  
Line 283: Line 285:
   * a list of its contents (.tcz.list)    * a list of its contents (.tcz.list) 
   * an md5 sum (.tcz.md5.txt)    * an md5 sum (.tcz.md5.txt) 
-  * an info file describing its contents (.tcz.info) - this content is standardized. [[http://distro.ibiblio.org/tinycorelinux/8.x/x86/tcz/|Visit the repository for examples]](The link is to the 8.x repository.  If you have a different version, follow the link, and then replace 8.x with whatever version you have[but only the major release eg. 7.x 9.x, not the minor release eg. 8.0, 7.2]).  +  * an info file describing its contents (.tcz.info) - this content is standardized. [[http://distro.ibiblio.org/tinycorelinux/8.x/x86/tcz/|Visit the repository for examples]](The link is to the 8.x repository.  If you have a different version, follow the link, and then replace 8.x with whatever version you have[but only the major release eg. 7.x 9.x, not the minor release eg. 8.0, 7.2]). Also see the example below.
   * a dependency list, if necessary (.tcz.dep)    * a dependency list, if necessary (.tcz.dep) 
   * If the source is under the GPL license, include the source as well.     * If the source is under the GPL license, include the source as well.  
-  * a .tcz.zsync (autogenerated with submitqcx[where x is the major release of tinycore linux you have.  A new version might not get a new submitqc right away.  If there isn't one for the current version, use the previous version], or submitqc)  +  * a .tcz.zsync (autogenerated by submitqc)
  
 It is not required, but certainly recommended, that you include any additional build instructions in a plain text file for future reference, mentioning such things as which extensions are required to build the package and what compile flags were used. This can be done in a file named "build-dep". For example, the build-dep file for urxvt looks like this:  It is not required, but certainly recommended, that you include any additional build instructions in a plain text file for future reference, mentioning such things as which extensions are required to build the package and what compile flags were used. This can be done in a file named "build-dep". For example, the build-dep file for urxvt looks like this: 
Line 332: Line 334:
 </code>   </code>  
  
-If the package contains a program, the best choice for its name is the bin name (this will ensure that program start directly if you load package ondemand[but you need to make an executable shell script usr/local/tcz.installed/<bin_name> for that to work{make the script then do   chmod +x usr/local/tcz.installed/<bin_name>}])+If the package contains a program, the best choice for its name is the bin name (this will ensure that program start directly if you load package ondemand[but you need to make an executable shell script usr/local/tce.installed/<bin_name> for that to work{make the script then do   chmod +x usr/local/tce.installed/<bin_name>}]).  The paths would be under you package's root.  
  
 In field "Comments" string "PPI Compatible" (if the package is compatible with "Persistent Personal Installation" mode, usually if we have used /usr/local directory as a installation prefix) seems no longer to be specified since this type of operation has been removed from 4.x and later.  Of course, it doesn't break anything to add PPI Compatible, but it can be kind of confusing since it was removed 4 major releases ago!   In field "Comments" string "PPI Compatible" (if the package is compatible with "Persistent Personal Installation" mode, usually if we have used /usr/local directory as a installation prefix) seems no longer to be specified since this type of operation has been removed from 4.x and later.  Of course, it doesn't break anything to add PPI Compatible, but it can be kind of confusing since it was removed 4 major releases ago!  
 +
 +**DAEMONS**
 +
 +
 +Please show full pathways to start daemons in your info file. TC does not condone starting daemons in your tce.install script.
 +
 +eg 
 +$ sudo /usr/local/etc/init.d/dbus start
  
 ===== .tcz.dep example =====    ===== .tcz.dep example =====   
Line 359: Line 369:
 =====  Submitting =====   =====  Submitting =====  
  
-Have you run the extension audit script(submitqcx[where x is the major release of tinycore that you have] or submitqc) to test your extension? If so, create a gzip archive. For example, if all the required files are in one directory, the command would look like this:  +Have you run the extension audit script(submitqcx[where x is the major release of tinycore that you have{legacy, not available for newer releases}] or submitqc) to test your extension? If so, create a gzip archive. For example, if all the required files are in one directory, the command would look like this:  
  
 <code bash> <code bash>
Line 377: Line 387:
  
 Files part of an extension package are Gmail neutral and accepted for delivery, no need to encrypt.   For more details, read the [[http://forum.tinycorelinux.net/index.php?topic=330.0|guildelines forum thread]]. Files part of an extension package are Gmail neutral and accepted for delivery, no need to encrypt.   For more details, read the [[http://forum.tinycorelinux.net/index.php?topic=330.0|guildelines forum thread]].
 +
 +Gmail currently limits attachments to 25 Mb per email.
Print/export