| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
| |
Function prototype mismatches and missing prototypes
Fix compiler warnings
|
| |
|
|
|
|
| |
Promote previously windows specific functions to be
generically available (and give them names that
reflect that).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This started as a customer request, where the customer wanted to
store a file in the ROM file system with a bunch of command line
parameters in it, and then use the @file syntax to run that file
and setup the interpreter. In essence a 'canned' setup stored in
the ROM file system.
That didn't work, at all, because of a dichotomy in the logic of
argument processing. The code used 'lib_file_open' in order to find
the file using the search path which, on Ghostscript, includes all
the iodevices, Rom file system, RAM file system etc.
That function returns a stream which the calling function 'lib_fopen'
would then reach inside and pull out the pointer to the underlying
gp__file *, and return, because the argument processing was written
to use a gp_file *, not a stream *.
But.... For the ROM file system, what we store in the 'file' member
of the stream is not a gp_file *, its a 'node' *. Trying to use that
as a gp_file * rapidly leads to a seg fault.
So this commit reworks the argument processing to use a stream *
instead of a gp_file *. In reality there is no real difference to the
logic we simply use a different call. There are a lot of fiddly
references to change unfortunately.
There are some consequences; we need to pass stream * around instead of
gp_file *, and in particular the 'encoding' functions, which are
OS-specific need to use a stream *. This isn't a problem for the
interpreters and graphics library, but mkromfs *also* uses those
OS-specific files, and it does not have the stream library available.
Rather than trying to include it, we note that we don't actually need
to use these functions for mkromfs and we do the same hackery as for
other missing functionality; we define a stub function that does nothing
but will permit the compile to complete.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This spins out of bug 705260.
The main focus of this commit was to get the alphabits stroke
fill operation to work properly with the pdf14 device. When
fill stroke operations occur with overprint and transparency
there are specific pdf14 setups required as outlined by the pdf
spec.
Prior to this, the pdf14 stroke/fill method would do all the
required setup within that method. This setup needed to be
accessible to the abuf device when it is doing its stroke/fill
method. This was achieved through the use of a special operation
which has been renamed from gxdso_overprint_op to gxdso_abuf_optrans
to make it clear that it is really only used by the abuf device
for communicating to the overprint and transparency compositors.
Essentially the parts that handled all the special transparency
operations were pulled out of the pdf14 stroke/fill method and made
available for use during the special operations call of
gxdso_abuf_optrans. A state variable was maintained to pass information
as we move from fill to stroke.
There were several additional issues found during this work.
1) The pdf14 op_state which tracks if we are doing fill or
stroke was not getting updated in pdf14_set_marking_params
which caused the wrong overprint state to be used when we
had stroke/fill operations with differing overprint settings
during clist reading.
2) The alpha buffer device must clear its buffer between
the fill and stroke operations and before the overprint state
is restored to its prior state. Otherwise data can remain in
the memory buffer and is not released until the device is closed,
at which point the overprint state may have changed.
3) From careful review, it was clear that when the stroke
and fill alpha both equal 1 and the blend mode is normal
no special groups are pushed in the presence of overprint.
4) The interpreter was pushing a group during stroke/fill
overprint cases. This has been removed as the pdf14 device
will handle all of these decisions.
In case git messes up the attribution, this code was originally
written by Michael Vrhel, and then the gxdso behaviour was
altered by Robin Watts. Credit to Michael, blame to Robin as
usual!
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Supports out-of-order ranges (if the parser allows it and disables the
PageHandler, i.e., flp device). Also adds support for ranges appended
to the "even" and "odd" keyword following a ":".
As before a trailing "-" in a range implies the last page, and as was
supported by the previous 'gxps' code, a leading "-" also is the last page.
For example, with XPS or PDF: -sPageList=odd:3-7,even:4-8,1-,-1,9
prints pages: 3, 5, 7, 4, 6, 8, 1, 2, ..., last, last, last-1, ..., 1, 9
The PageList string is parsed using C code into an array that consists of
an initial int that is > 0 if the list is ordered, followed by sets of
3 integers per range, even/odd flag (odd=1, even=2), start, end. The
final 3 ints are 0,0,0 as a marker.
The initial int is used by 'pagelist_test_printed' as an index to the next
range to be processed when the PageList is used for languages that can only
be processed sequentially (e.g. PS and PCL) and is updated when the page
passes the end of the current range. A value of -1 means the ranges are
not ordered (not strctly increasing).
The flp_fillpage is changed to ignore errors from processing the PageList
performed by ParsePageList (called from SkipPage) when PageCount is 0
so that parsers that support out of order processing (PDF and XPS) can
continue until later. This should have little or no performance impact
since it is limited to PageCount == 0.
Note that the new PDF parser also uses the C code parser and then uses
the array of ranges returned by ".PDFparsePageList". The old PostScript
based parser has not been updated, although it is easy to do so.
|
| |
|
|
|
|
|
|
| |
This will only work for rendering to images. High level output
such as the pdfwrite device will not make the uncolored pattern
color black (or white).
Note I did a little code name cleanup too.
|
| |
|
|
|
|
|
| |
-dBlackVector -dBlackText use a compile time setting on the
L* value of the fill value to decide if value should be a
gray value of 0 (black) or a gray value of 1 (white).
Currently set to a value of 95 (L* varies from 0 to 100)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Specifically this is intended to allow use of -sPostRenderProfile
so we can (for example) use the plan device to render in RGB, then
convert to cmyk as a post-process step.
In preparing this commit, various problems were found in the planar
downscaler, and these are fixed here too.
In addition, to avoid every device that wants to support
PostRenderProfile needing an identical batch of code to create the
icclink, we extract that into a gx_downscaler_create_post_render_link
helper function, and use that in the appropriate devices.
As a knock on for that, we tweak gsicc_free_link. Firstly, it no
longer takes a memory pointer, but rather uses the one in the
link itself. This is a step up from the existing code that appears
to allocate with 'stable_memory' and then free with 'non_gc_memory'.
I suspect we've been getting away with this by chance because the
two have always happened to be the same.
Secondly, it performs the 'free_link' operation as part of the call.
This enables all the call sites to be simplified.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ghostscript has long had an optimisation for paths filled with
patterns and shadings. Instead of scan converting the path, and
then 'filling' that with the pattern, the code would instead
make a clipping device from the path, and then fill that in one
hit using a rectangle fill.
The reason why this is a win can be seen easily when you consider
a shading fill; if we scan converted to get a series of rectangles
that we then filled, the shading would need to be decomposed
repeatedly for each rectangle. By scan converting, making a
clipping device from that, and filling a single rectangle of the
shading, the decomposition only happens once - and the lowest
level 'fills' resulting from that are efficiently filtered by
the clipping device.
The same optimisation has never been applied to stroking, despite
it potentially being even more worthwhile. This commit rectifies
this ommission.
Sadly, applying it causes content to vanish in clist mode. After
some digging it seems that the clist writing code has to wrap
path filling operations with some save/restore magic for cropping
min/max values. Once we extend this mechanism for stroked paths
we need to do the same for stroked operations too.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some devices within Ghostscript (currently the x11 devices,
uniprint and opvp/oprp) use non const static variables, so cannot
be run in multiple instances at a time.
We now maintain a core "count" of how many non-threadsafe devices are
being used at any time. This value can be atomically adjusted by calls
to gs_lib_ctx_nts_adjust.
Non threadsafe devices now call gx_init_non_threadsafe_device either
as or as part of their initialise_device proc. This function attempts
to increment the non-threadsafe count and fails to init if there is
already a non-threadsafe device running.
On success, the device finalize method is modified so that it will
decrement the count at the end.
The known non-threadsafe devices are updated to call this.
In order to have somewhere safe to store this count, we introduce
a gs_globals structure, shared between instances. Setting this up
without race conditions requires some new gp_ functions that can
make use of platform specific threading primitives. We have these
implemented for both windows and pthread based platforms. On other
platforms, we drop back to the old unsafe mechanism for counting
instances.
While we do this work, we take the opportunity to push the
gs_memory_t pointer used for non-threadsafe debug printing into thread
local storage.
This enables us to remove the remaining GS_THREADSAFE guarded
compilation from the source code. What is left is broadly down to
allowing debugging collection for statistics, and these are now
controlled by specific COLLECT_STATS_XXX defines. It is assumed
that anyone wanting to collect such stats is smart enough to not
try to do so while using Ghostscript in a multi-instance environment.
|
| |
|
|
|
|
|
|
|
|
| |
Adding spot colorants when seen in Type 5 halftones could end up adding
some that are not counted in the PageSpotColors count of PDF files, that
were not counted because they did not occur in any colorspace.
If a Type 5 Halftone is set for a spot color before the colorspace that
uses that spot color, it will be ignored, which still needs to be fixed.
That will be a subsequent commit.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Previously, the only C code that required access to the Adobe Glyph List was
in the vector devices, so we kept the AGL definition with those. Otherwise
it was always in Postscript.
The PDF interpreter in C also requires the AGL, so move the AGL into base, and
give it its own ".dev".
Still to do: Remove the Postscript definition, and create the Postscript
definition(s) in PS VM from the C definition.
|
| |
|
|
|
|
|
|
|
|
|
| |
This is a commit of the pdfi branch to master, eliminating
the traditional merge step.
The full history of the pdfi branch can be seen in the repo,
and that branch is effectively frozen from this point onwards.
This commit actually differs from pdfi in a small number of
whitespace changes (trailing spaces etc).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The customer's PDF file defined a Type 5 halftone with different halftones
for some of the named components, but only Default and Cyan, Magenta, Yellow,
and Black were actually being generated and installed into the pgs->dev_ht
so the /Default would be used for all the spot colors.
This change adds the colorant that is not yet known is when it is seen by
gs_color_name_component_number rather than when the colorspace is set with
the colorant. The equivalent color is still loaded when the colorspace is
loaded.
Note that for devices that support DeviceN (extra colorants), we do not
add the "Red", "Green", "Blue" and "Gray" when seen in the HalftoneType,
but only AFTER they are set in a colorspace. This is needed since many
files set these other component names even when they are not yet entered
as spot colors (in Separation or DeviceN colorspaces).
|
| |
|
|
| |
Fixes (spurious) parallel make failure on the cluster
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds the capability to simulate overprint including that of
spot colors for all devices including gray and RGB devices. This
is achieved by having the PDF interpreter look if overprint
is present, the seting of -dOverprint (/simulate /enable /disable),
if the page has transparency, and if the page has spot colors. Depending upon
the color model of the device, and if transparency is present,
a special push of the pdf14 device may occur. The pdf14 device
buffer collects the data in a CMYK or CMYK+spots buffer and the
put_image method in the pdf14 device will map the buffer to
the target device color space. The code was tested with
devices that support and do not support spot colors, those that
support and do not support alpha channels, tag based devices,
gray, RGB, and CMYK devices. A special test file to check
multiple cases was added to the regression suite. By default
-dOverprint is set to /enable, which should result in the existing
behavior where by RGB and Gray devices do no show overprint or spot
colors and CMYK devices will handle CMYK overprinting and separation
devices will show spots and overprint of all colorants. With
-dOverprint set to /disable no device will show overprinting. With
-dOverprint set to /simulate all devices will show overprint and
spot colors. Ray Johnston did the work in the interpreter as
well as the device parameter default setup. I did the pdf14 device
changes and testing. Changes in a variety of locations were required
due to the fact that new combinations were encountered, for example
we had cases where devn colors were being used with a device that
supports tags (bitrgbtags device and pdf14 compositor setup for CMYK+spots).
One file:
tests_private/xps/xpsfts-a4/fts_34xx.xps.pdf ppmraw 72 now produces
an error. This file should have been throwing an error all
along but was being quietly swallowed. Acrobat will not open
the created pdf file and throws and error. I will open a bug
for the issue as it is a problem with the XPS interpreter.
|
| |
|
|
|
| |
gsparamx.c is now required in the "base" configuration, since it contains
function(s) now being called from gsdparam.c
|
| |
|
|
|
|
|
|
|
|
|
| |
Internally the name is changed to "overprint_control" which has enum values
of gs_overprint_control_t. This is in preparation for Michael Vrhel's
overprint simulation implementation.
Documentation of the change and the new parameter specifics added to the
doc/Use.htm file. Also added change to gs_init.ps so that command line use
of -dSimulateOverprint=true maps to -dOverprint=/enable and similarly,
-dSimulateOverprint=false maps to -dOverprint=/disable with a warning.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By using a subclassing device to intercept a few of the device procs
(get_initial_matrix, output_page, fillpage, put_params, close_device, and
dev_spec_op) pages can be placed on to a page that is eventually output.
This initial implementation scales the pages on the 'nest' as defined
by -sNupControl parameter that is a string of the form "HxV" where H
and V are integers controlling nesting across (H) and down (V) the page.
All pages on the nest are the same size/orientation as the first page of
the nest, and if a different PageSize is encountered, any pages on the
current nest will be output before starting a new nest.
In gx_device_set_hwsize_from_media dev_spec_op is used to prevent changing
the device width and height (HWSize) for PageSize or .MediaSize params.
This requires that the graphics library should not assume that HWSize is
derived from PageSize and HWResolution, but it allows the intial clip_path
for the nested pages to be set from the MediaSize, Margins, and HWMargins
in gx_default_clip_box.
There are a few files that have differences with the 'psdcmyk' devices when
tested with -sNupControl=1x1:
Bug688584.ps: Page 6 missing graphics,related to SeparationOrder usage.
(a bug will be opened for this once this is committed).
Bug692517.ps: subclass device barely switches to clist mode for 72.0
(don't care, page mode still works for larger MaxBitmap),
tests_private/pdf/PDFIA1.7_SUBSET/CATX2975.pdf.ppmraw.300.0..gs
(seems to be a progression on page 9)
|
| |
|
|
|
| |
This cures data races with gs_next_ids seen with helgrind and BGPrint
and/or NumRenderingThreads.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, we look in TESSDATA_PREFIX (if defined).
If not found there, we look in ROMFS (in tessdata).
If not found there, we look at the configured "tessdata" path
(which defaults to ${datadir}/tessdata). (${datadir} defaults to
${prefix}/share on unix, and ${gsrootdir} on windows.)
If not found there, we look in the current directory.
Update doc/Devices.html (and fix some indexing).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Map all text to black. This is achieved by altering the
color space to DeviceGray with a fill of black during
gs_text_begin. When gs_text_release occurs, the color space
is restored. This will only occur with the option -dBlackText
and if the text is actually to be drawn.
When going to a raster device, the stroke and stroke fill of
the text is handled with a stroke or stroke fill command.
My original plan of storing the old color spaces and client
color in the text enumerator will not work in this
situation as it the enumerator will have already been
destroyed when the stroke or stroke/fill command occurs.
For this reason I store the old color space information
for the current and alternate color spaces
in the graphic state. The structure holding the information
is garbage collected as it is holding objects that may be
garbage collected. We also need to know if the target
was a high level device like pdfwrite, as that device
will handle the fill AND stroke, and we will need to restore
the color space when we tear down the text enumerator.
gs_text_release needed to have the pgs added as a parameter
to allow the possible release of the blacktext structure
when the text is released from the other languages. This
did not seem to be too big of an issue as gs_text_begin
passes the pgs also. If the pgs is not available, NULL can
be passed, and that is done in several locations.
A new special op was added to let us avoid doing the black
text setting if we are constructing a soft mask. If we did not
do this the mask could result in the loss of the text.
Finally, Type 3 fonts will NOT be affected by this process.
Type 3 fonts are often used for actual graphic logos etc.
Ken Sharp suggested we not have them affected by this setting.
There were also issues with trying to do type 3 fonts in
in that the PDF interpreter does some color space settings
of its state when dealing with type 3 fonts and this put the
interpreter's state out of sync with the graphic library state.
This was tested with a forced setting of black text enabled.
No seg faults or errors occurred. There were obviously a lot
of differences reported (over 33,000). All the images that were available
to me with bmpcmp were gone through. Problems were found
and addressed (the soft mask issue for example was found,
as were issues with color spaces not getting properly restored).
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Move the compiler parameters around so the third party lib specific -I options
come first - hopefully meaning we'll favor any included headers over those in
the system include path(s).
This assumes the compiler searched include directives given on the command line
left to right. Apparently this used to be a problem, I've not found a recent
compiler that breaks that assumption (yet!).
This applies to: expat, freetype, ijs, jbig2dec, jpeg, jpegxr, openjpeg, png
tiff and zlib
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that the allocations from the bitmap cache are aligned to the platform's
required alignment, see commit:
260c443bc14cdffa4d94e14c3a57e35bebee3a5b
We also want the initial size of the memory pool used by the cache to be
"aligned".
This is so that code that attempts to identify cache entries to evict by
requesting a size equal to the entire size of cache memory pool doesn't get an
unexpected failure, because we've rounded up that allocation request to a value
larger than the entire size of the memory pool.
Because we don't expect an error to be possible at that point, a crash can
occur.
Of the "normal" platforms we use, this only exhibits on Win32 because that is
the only platform where the align_bitmap_mod we use is less than the
obj_align_mod used for the memory managers.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For efficiency, the glyph cache allocates "large" blocks of memory into which
it parcels out offsets for individual glyph cache bitmaps, as required.
Since cached glyphs are usually fairly small, and potentially can be short
lived, this saves the overheads of "full" memory for every cached glyph.
Unfortunately, in calculating the offsets for the cached glyph, it was failing
to account for the required alignment of the system. In any environment that
strictly enforces aligned memory accesses, this will potentially cause a bus
error.
In this case, it was switching the gs_glyph type to a 64 bit type that triggered
the issue. But any changed to the contents of the cached_char struct could have
resulted in it happening.
|
| |
|
|
|
|
| |
If the process color space does not match the source color space (for example
drawing an RGB image to a CMYK device) and overprint is true, then we should
still retain the spot colorants assuming the device supports them.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Actually, steal the existing functions from the PJL code,
move them into the graphics library, and refactor slightly.
2 functions; the first one, gs_param_list_add_tokens reads
a string of key/value pairs and adds them to the list.
The second one, gs_param_list_add_parsed_value takes a key
and a string for the value, and just adds that pair to the
list.
|
| |
|
|
|
|
| |
Aiming for a better match to Adobe's reference implementation.
Patch supplied by Peter Cherepanov. Many Thanks!
|
| |
|
|
| |
Patch from Peter Cherepanov. Many thanks!
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, the plane_begin_typed_image function used the gs_gstate_copy_temp,
but since this was allocated as a st_gs_gstate, and the reference counts
were not handled (as the comment describes), freeing that object would
decrement the ref_counts, causing premature free of objects.
Remove this dangerous function.
Change to use gs_gstate_copy so we have a proper gs_gstate structure.
Using gs_gstate_copy from a clist playback gstate requires that we have
client colors and device colors in the color[0] and color[1] elements.
Allocate, and initialize these, then free upon exit from clist_playback.
Also, the mem device underlying the plane_extract device needs to be
retained so that it is not prematurely freed.
|
| | |
|
| |
|
|
|
|
| |
pdfocr8/24/32, ocr and hocr devices.
Use OCRLanguage to set languages to use ("eng" by default).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the blending color space is RGB based,
special consideration must be made for doing
overprint with separation and devicen color spaces.
In particular if we are going out to a separation
device we could have RGB+spot support but not
if the separation color was a process name like
Cyan.
Also implement the missing gxdso_pdf14_sep_device
special operation.
|
| | |
|
| |
|
|
|
| |
The alpha value in the graphic state is not used and will
only lead to confusion for people working on transparency.
|
| |
|
|
|
|
|
| |
Looks like the calling code was unfinished, and the build
changes were not done.
Also, squash some warnings.
|
| |
|
|
|
| |
I'd missed the dependency to make sure the required directories were created
before attempting to copy the custom header into one of those directories.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The font in the XPS file has both outline and bitmap glyphs, and with such fonts
freetype ends up marking them as "bitmap" and "non-scalable" fonts, so when we
attempt to set a size for glyph scaling not equivalent to the included bitmaps,
freetype throws an error.
The file works with (a default build) of mupdf because mupdf disables freetype's
bitmap font support at build time. It is not possible to force freetype to
ignore bitmap glyphs at run time.
This commit adopts a similar approach to mupdf, and disables bitmap glyph
support using a custom options header file.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This branch had several contributors including Robin Watts,
Ken Sharp and Ray Johnston.
The intent was to add a "fill and stroke" path device method
to ensure we get proper rendering when doing fill/stroke
methods with overprint and transparency. In addition,
adding the method made it possible for pdfwrite to match
the original pdf source file if it also had fill/stroke methods.
The interaction with overprint and transparency led to significant
changes in parts of the code related to those sections. In particular,
overprint was reworked to ensure that the overprint compositor and
the transparency compositor were aware if it was to be using
the overprint drawn_comps for stroke or for fill. The code was
rewritten so that the overprint compositor actions only occurred when
an actual operation occurred (e.g. fill, stroke, image, text) as opposed
to every time that the overprint graphic state values changed.
When there is a fill-stroke operation with transparency, depending upon the
graphic state values, a non-isolated knockout group may be pushed. From this,
an issue with knockout groups within knockout groups was revealed, which was
related to the backdrop selection. The backdrop selection code was simplified.
|
| |
|
|
|
|
|
|
|
| |
Any "printer" device depends on the low level 'page' device (page.dev),
unaccountably, the cups devices (cups and pwgraster) did not have that
dependency in the makefiles.
Also, the PDF transparency compositor now (and for some time) has also depended
upon page.dev, so update the makefiles for that, too.
|
| |
|
|
|
|
|
| |
The header inclusion in gssprintf.c meant the definitions of the PRI macros
for string formatting could be inconsistent with other source files.
Adding the appropriate headers in the correct order resolves that issue.
|
| |
|
|
|
|
| |
Sets MKROMFS_FLAGS=-q and pass to all invocations of mkromfs.
[Makefile.in and configure.ac changes by chrisl]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is mainly moving from using uname to identify the the target platform,
to using the 'host' value to identify the target platform, and 'host' and
'build' values to know when we're cross-compiling.
There are also a couple of tweaks related to cross-compiling to MSYS.
Also, make double sure API symbols are always visible. This affects builds with
gcc and compatible compilers.
Remove use of $cross_compiling variable
Credit to djcj for most of the changes
|
