On 23 Nov 1999 15:45:47 +0100, Lars Gullik Bj°nnes wrote:
>
>The "experimental" use of libtool works for linux, and I have not seen
>any failure reports from other archs yet.
>
>I suspect that when libtool is used in "static" mode as it is now, we
>should not have large problems on any system. However I'd like to see
>"shared" support also tested.
>
>Configure with:
>
>./configure --enable-shared
>
>This will cause libmathed, libinset and libsupport to be built as
>shared libs and when "make install" be installed in /usr/local/lib/lyx
>
>This works perfectly on linux, but I am not sure on other archs.
Just released a DLL-version (lyxsup10.dll) of the old stable branch,
without using libtool, cf. appendix. Please download the package to
lyx.org, if you want.
>
>Note that use of --enable-shared double the compilation time since
>both static and shared libs are built. When Lyx is run in place with
>this setup the static version is used.
>
>I would especially like to see OS2 and Win tested.
>
> Lgb
libtool has some emx-support.
It lacks some linker flags which are necessary or useful, e.g. the
INITINSTANCE TERMINSTANCE (of uninitialized static variables) and DATA
MULTIPLE NONSHARED flags, it does not provide for suitable HEAPSIZE and
STACKSIZE statements. Moreover I would like to check the EXPORTS
statements in the Module Definition File manually before linking.
Dynamic linkage with the standard C++-library is still a mess (you
might have to compile your own custom libstdc++), there are a number of
rough edges and kid's deseases with recent C++-features like virtual
functions or RTTI, all in all it's difficult and you have to go on very
slowly step by step.
You can use the EMXEXP tool to export all global functions and all
initialized global variables.
(And even the uninitialized, but this is often problematic: Please
initialize ALL global variables to a completely defined state and
assert() violations of this rule. Even better is it *not to export any
global variables* and to *export only global functions*. The OS-linker
link386 is in fact not tested for the import of global variables from a
DLL. IIRC this export of global variables occurs with RTTI and virtual
functions as gcc implements them and often leads to multiply defined
symbols; but don't believe me here, I may be wrong.).
So, while an optional libtool is certainly helpful for creating
manually a suitable make process for dynamic linkage by modifying its
templates, I don't think it should be enabled by default.
FYI some glossary terms (stolen from IBM docs with 'corrections' by me,
sorry for pedanticism, I'm currently compiling a kind of emx porting
tutorial):
------
What Is a Module Definition File?
A module definition file describes the names, attributes, exports,
imports, and other characteristics of an application or library. You
must use module definition files to create most applications for OS/2.
You must use module definition files to create all OS/2 dynamic-link
libraries and device drivers.
Module Statements
A module definition file contains one or more Module Statements These
statements:
Define various attributes of the executable file
Define attributes of code and data segments
Identify functions that are imported or exported
Programs for OS/2 generally call one or more dynamic-link libraries.
Dynamic-link libraries serve much the same purpose that standard
libraries do, but they also have the following advantages:
Code and data segments can be shared. Without dynamic linking,
such sharing is not possible because each file has its own copy of all
the code and data it uses. By sharing segments with dynamic linking,
you can use memory more efficiently.
The figure below illustrates a simple case in which you create an
application that uses a single dynamic-link library (.DLL) file.
.OBJ and .DEF file .a file .o and
.LIB files (LIBRARY) (imports) .a files
(exports)
(2) EMXIMP
(1) LINK386 (3) (4) GNU ld
.DLL file .EXE file
(library) (application)
As depicted above, linking occurs in three steps:
1. Object files (and dynamic-link libraries) are linked with a
module definition (.DEF) file to create a .DLL file. A .DEF file is
used that defines all functions exported by the .DLL file. You can use
the EMXEXP tool to export all global functions and all initialized (and
even the uninitialized, but this is often problematic: Please
initialize ALL global variables to a completely defined state; assert()
violations of this complete definition) global variables.
2. The EMXIMP program is used to generate an import library (.a)
file. EMXIMP takes as input the same module definition file used in
the first step. For each export definition in the .DEF file, EMXIMP
generates a corresponding import definition.
3. The .a file generated by EMXIMP is used as input to GNU ld,
which creates an a.out binary. This .a file provides GNU ld with
information about imported dynamic-link functions.
4. The a.out binary is bound together with an a.out binary loader
to create an application (.EXE) file.
Import and Export Definitions
Each dynamic-link library (.DLL file) defines export definitions that
tell OS/2 what functions the library has. Functions not exported can
only be called from within the library. Each export definition
specifies a function name.
Conversely, each executable program (.EXE file) defines import
definitions that tell OS/2 which dynamic-link functions the program
needs and where they can be found. Otherwise, OS/2 would not know
which dynamic-link libraries to load when the program is run. Each
import definition (which is normally found in the import library)
specifies for linker fixup of unresolved symbols a function name and
the .DLL file where the function resides.
Syntax: LIBRARY [libraryname][initialization] [termination]
This statement identifies the executable file as a dynamic-link
library and optionally defines the name and library module
initialization required.
If <initialization> is given, it defines the library initialization
required and can be one of the values below. If omitted,
<initialization> defaults to INITGLOBAL.
INITINSTANCE
The library initialization routine is called each time a new
process gains access to the library.
Using this keyword without a termination flag implies
TERMINSTANCE for DLLs with 32-bit entry points.
These attributes determine how the automatic DATA segment can be
shared:
NONE No automatic data segment is created.
SINGLE A single automatic data segment is shared by all instances
of the module. In this case, the module is said to have solo data.
This keyword is the default for dynamic-link libraries.
MULTIPLE
The automatic data segment is copied for each instance of
the module. In this case, the module is said to have instance data.
This keyword is the default for applications.
These attributes refer to initialized global data. The automatic data
segment is the physical segment represented by the group name DGROUP.
This segment group makes up the physical segment that contains the
local stack and heap of the application.
These attributes determine whether all instances of the program can
share a READWRITE data segment:
SHARED One copy of the data segment is loaded and shared
among all processes accessing the module (default for dynamic-link
libraries).
NONSHARED The segment cannot be shared, and must be loaded
separately for each process (default for applications).
These attributes refer to non-initialized global data. Under OS/2,
this field is ignored if READONLY is specified, since READONLY data
segments are always shared.
Syntax: HEAPSIZE bytes | MAXVAL
This statement defines the size of the application's local heap in
bytes. This value affects the size of the automatic data segment.
The field <bytes> contains any positive integer. You can enter
<bytes> in decimal, octal, or
hexadecimal radix. See Entering Numeric Arguments.
Syntax: STACKSIZE number
This option controls the local stack size (in bytes) of your program.
You can specify any positive value for <number>. See Entering Numeric
Arguments.
If your program generates a stack-overflow message, you can increase
the size of the stack. In contrast, if your program uses the stack
very little, you may save some space by decreasing the stack size.
Syntax:
EXPORTS
exportdefinitions
This statement defines the names and attributes of the functions
exported to other modules and of the functions that run with I/O
privilege.
Note: The term export refers to the process of making a function
available to other run-time modules. By default, functions are hidden
from other modules at run time.
Normally, the EXPORTS statement is meaningful only for functions
within dynamic-link libraries and for functions that execute with I/O
privilege.
The EXPORTS keyword marks the beginning of the export definitions.
Each definition is
entered on a separate line. You need to give an export definition for
each dynamic-link
routine you want to make available to other modules.
Export-Definition Syntax
entryname [=internalname] [@ord[RESIDENTNAME]] [pwords]
<entryname>
The function name as it is known to other modules.
<internalname>
The actual name of the export function as it appears within the
module itself; by default, this name is the same as <entryname>.
<ord>
The function's ordinal position within the module definition
table. If this field is used, the function's entry point can be
invoked by name or by ordinal. Use of ordinal positions is faster and
may save space.
-----------
APPENDIX:
==================BEGIN FORWARDED MESSAGE==================
>Subject: LyX for OS/2 v. 1.0.4.1 released
>
Finally announcing the binary release of
LyX for OS/2 v. 1.0.4.1,
the professional highlevel document processor. Get it from
hobbes.nmsu.edu in pub/incoming, please report installation problems
(if any).
More info:
www.lyx.org
README.bin excerpt:
Binary Distribution of LyX for OS/2, rev. 1.0.4.1
==================================================
LyX has been ported to OS/2 with XFree86 by Shigeru Miyata and
has been installed and used successfully by many people.
[...]
This release is considered to be stable for general use, but - like
any other piece of software - certainly is not bug free.
So take the usual precautions, like adopting a regular backup policy.
Standard disclaimers of non-liability apply.
Compared to the original Unix version this version contains small
enhancements and patches, namely:
* support for cp850.def of LaTeX (Layout->document->encoding)
* invoking of reLyX with absolute path name
* support for invoking tth.exe (if installed on your system)
* while being at it, added some 'const' qualifiers here and there
* small additions for hacking LyX server
* experimental support for alphanumeric section numbering
(LyX does not yet display the headers correctly, please
refer to the example file alfa.lyx; you need CTAN's "KOMA script")
- For general information on LyX please refer to the generic
README. For generic compiling instructions refer to INSTALL.
- For a more detailed step by step guide on installing (or compiling)
LyX and other related useful (or even necessary) optional programs
on OS/2 please refer to INSTALL.OS2. If you are not already an
experienced user of LyX for OS/2, you are advised to read it.
As this is a voluntary project with a large number of contributions
by many people, hints and bug fixes to the program and/or the
documentation are always appreciated and thoroughly considered. If
you have the necessary skills (or want to take the chance to acquire
them) for programming in LaTeX or C++ you can become a LyX developer.
You can support further development by making a donation, if you feel
that LyX made your live a bit easier or you want to support open source
software.
Please refer to the links at www.lyx.org for details.
==============================================================
Have fun,
Arnd
===================END FORWARDED MESSAGE===================
