xefitra jasper Fortran77

[lazer1]

is there any reason why the jasper configure has a lot of Fortran 77 stuff?


does jasper really depend on Fortran 77?



the Jasper makefile seems to have some Fortran vars, but doesnt seem to use
them.






_______________________________________________
gs-devel mailing list
gs-devel@...
http://www.ghostscript.com/mailman/listinfo/gs-devel

[Ralph Giles-2]

On Wed, Aug 19, 2009 at 9:37 AM, lazer1<lazer1@...> wrote:

> is there any reason why the jasper configure has a lot of Fortran 77 stuff?

Either automake or libtool check for that (along with C++) in case
they later encounter code that requires those tools. Jasper is
completely written in C, so it just slows down the configure run. Feel
free to file a bug against the relevant tool upstream.

All of this is sort of irrelevant because we use our own makefile to
compile the jasper source into ghostscript. However, it was easier to
use jasper's configure script to generate its platform-dependent
header than to reproduce all that in our build. So the whole thing is
a wait of build time, unfortunately.

 -r
_______________________________________________
gs-devel mailing list
gs-devel@...
http://www.ghostscript.com/mailman/listinfo/gs-devel

[lazer1]

On 19-Aug-09, Ralph Giles wrote:
>On Wed, Aug 19, 2009 at 9:37 AM, lazer1<lazer1@...> wrote:

>> is there any reason why the jasper configure has a lot of Fortran 77 stuff?

>Either automake or libtool check for that (along with C++) in case
>they later encounter code that requires those tools. Jasper is
>completely written in C, so it just slows down the configure run. Feel
>free to file a bug against the relevant tool upstream.

when you say upstream you mean to navigate at bugs.ghostscript.com or
at some Jasper website?


it would be nice if there was a configure option --without-fortran

and maybe --without-C++


>All of this is sort of irrelevant because we use our own makefile to
>compile the jasper source into ghostscript.

you dont use the jasper/Makefile created by the configure?

> However, it was easier to
>use jasper's configure script to generate its platform-dependent
>header than to reproduce all that in our build. So the whole thing is
>a wait of build time, unfortunately.

> -r


which versions of make are known to be alright for building Ghostscript?



_______________________________________________
gs-devel mailing list
gs-devel@...
http://www.ghostscript.com/mailman/listinfo/gs-devel

[Ralph Giles-2]

On Wed, Aug 19, 2009 at 5:53 PM, lazer1<lazer1@...> wrote:

> when you say upstream you mean to navigate at bugs.ghostscript.com or
> at some Jasper website?

Sorry, I meant the automake or libtool project. It's their code that's
responsible for the fortran checks; it's nothing the jasper
configure.ac specifically requests.

> you dont use the jasper/Makefile created by the configure?

No, just jasper/src/libjasper/include/jasper/jas_config_ac.h, which is
also created by configure.

> which versions of make are known to be alright for building Ghostscript?

It should work with any make implementation, although some gmake-isms
may have crept in. GNU make is what we normally test against, and
ghostpdl requires GNU make.

 -r
_______________________________________________
gs-devel mailing list
gs-devel@...
http://www.ghostscript.com/mailman/listinfo/gs-devel

[lazer1]

On 19-Aug-09, Ralph Giles wrote:
>On Wed, Aug 19, 2009 at 9:37 AM, lazer1<lazer1@...> wrote:

>> is there any reason why the jasper configure has a lot of Fortran 77 stuff?

>Either automake or libtool check for that (along with C++) in case
>they later encounter code that requires those tools. Jasper is
>completely written in C, so it just slows down the configure run. Feel
>free to file a bug against the relevant tool upstream.

>All of this is sort of irrelevant because we use our own makefile to
>compile the jasper source into ghostscript. However, it was easier to
>use jasper's configure script to generate its platform-dependent
>header than to reproduce all that in our build. So the whole thing is
>a wait of build time, unfortunately.

I eventually got around the Fortran 77 stuff by hiding g77 and g++

mv /bin/g77 /bin/g77_hidden
mv /bin/g++ /bin/g++_hidden

that makes the configure evade the irrelevant fortran and other stuff


hiding c++ led to problems but the configure with c++ is ok.

I have some questions about the build, but I will send them as other emails






> -r





_______________________________________________
gs-devel mailing list
gs-devel@...
http://www.ghostscript.com/mailman/listinfo/gs-devel

[lazer1]

the questions probably apply to 870 etc, but to avoid ambiguity

I refer to 860.


1. is it possible to remove the usage of file links from the entire build,
eg the archive for a start uses file links, and "make install" uses some?

As that requires the usage of a filesystem with *nix compliant links,

todays hard drives are huge, using cp instead of links wont make a lot of

difference to disk usage, and means one can use any filesystem.


or better still design the build to evade duplicates whether by cp or links.

at the moment I have to look out for link error messages and do the links
manually with cp

30 years ago it was worth using a file link to save 50K, but today you can
waste 100MB without anyone noticing.

especially if the duplicates are just temporary build time duplicates.



2. With the Makefile, GS_LIB_DEFAULT uses : as a separator, but that can cause

problems with filesystems which use : for a volume name

instead could that be replaced by , which probably isnt used in any builds

under normal usage I think

a to z
A to Z
0 to 9
_
:
\
and /

shouldnt

be used as separators


3. There is no X11 on the system here, but in the Makefile,
GS_LIB_DEFAULT=........:/usr/openwin/lib/X11/fonts/Type1:/usr/openwin/lib/X11/fonts/TrueType

2 X11 dependencies have appeared!



4. with the Makefile, I find RESOURCE_LIST=Resource/CMap/ Resource/ColorSpace/
Resource/Decoding/ Resource/Font/ Resource/ProcSet/ Resource/IdiomSet/
Resource/CIDFont/


But when I look in Resource/ I see just CMap ColorSpace Decoding and Encoding


ie in the above list: Font ProcSet IdiomSet and CIDFont dont seem to exist

and

Encoding does exist but isnt in the list

any reason for these 2 wierdnesses?


5. During the build, for contrib/pcl3/eprn/pagecount.c I needed to manually
set

#define RECORD_LOCKING_NOT_IMPLEMENTED 1

before

#include <fcntl.h>

the configure doesnt appear to have dealt with this



thanks for any comments on the above




_______________________________________________
gs-devel mailing list
gs-devel@...
http://www.ghostscript.com/mailman/listinfo/gs-devel

[Ralph Giles-2]

On Fri, Oct 9, 2009 at 11:38 AM, lazer1 <lazer1@...> wrote:

> 1. is it possible to remove the usage of file links from the entire build,
> eg the archive for a start uses file links, and "make install" uses some?
>
> As that requires the usage of a filesystem with *nix compliant links,

The unix install script does assume it's running on a unix system,
yes. Links are used to maintain the same file under multiple names;
it's not just about saving space.

If you use the msvc32.mak top level makefile it uses settings
compatible with Windows filesystems.

 -r
_______________________________________________
gs-devel mailing list
gs-devel@...
http://www.ghostscript.com/mailman/listinfo/gs-devel

[Ralph Giles-2]

On Fri, Oct 9, 2009 at 11:02 AM, lazer1 <lazer1@...> wrote:

> I eventually got around the Fortran 77 stuff by hiding g77 and g++
>
> mv /bin/g77 /bin/g77_hidden
> mv /bin/g++ /bin/g++_hidden
>
> that makes the configure evade the irrelevant fortran and other stuff

Glad you found a work-around.

 -r
_______________________________________________
gs-devel mailing list
gs-devel@...
http://www.ghostscript.com/mailman/listinfo/gs-devel

[lazer1]

On 09-Oct-09, Ralph Giles wrote:
>On Fri, Oct 9, 2009 at 11:38 AM, lazer1 <lazer1@...> wrote:

>> 1. is it possible to remove the usage of file links from the entire build,
>> eg the archive for a start uses file links, and "make install" uses some?
>>
>> As that requires the usage of a filesystem with *nix compliant links,

>The unix install script does assume it's running on a unix system,
>yes. Links are used to maintain the same file under multiple names;
>it's not just about saving space.

the links at the moment are:

for the main gs860 archive I need to run the following script:

#!/bin/sh
cd ghostscript-8.60
cp src/configure.ac configure.ac
cp /usr/share/libtool/config.guess ijs/config.guess
cp /usr/share/libtool/config.sub   ijs/config.sub
cp /usr/share/libtool/ltmain.sh    ijs/ltmain.sh
cp /usr/share/automake/missing     ijs/missing
cp /usr/share/automake/install-sh  ijs/install-sh
cp src/Makefile.in                 Makefile.in
cd ..

to achieve the effect of the links, looking more carefully I see that the

/usr/share ones are in fact links from outside the archive,

(its very confusing how cp does the args in a different order from ln)

could those be moved from the archive to the configure or makefile?

or is that a problem for the ijs project?


for "make install" the link error messages are:


ln: cannot create symbolic link `ps2pdf12.1' to `ps2pdf.1': Operation not
supported by device
ln: cannot create symbolic link `ps2pdf13.1' to `ps2pdf.1': Operation not
supported by device
ln: cannot create symbolic link `ps2pdf12.1' to `ps2pdf.1': Operation not
supported by device
ln: cannot create symbolic link `ps2pdf13.1' to `ps2pdf.1': Operation not
supported by device
ln: cannot create symbolic link `eps2eps.1' to `ps2ps.1': Operation not
supported by device
ln: cannot create symbolic link `ps2pdf12.1' to `ps2pdf.1': Operation not
supported by device
ln: cannot create symbolic link `ps2pdf13.1' to `ps2pdf.1': Operation not
supported by device
ln: cannot create symbolic link `eps2eps.1' to `ps2ps.1': Operation not
supported by device
ln: cannot create symbolic link `ps2pdf12.1' to `ps2pdf.1': Operation not
supported by device
ln: cannot create symbolic link `ps2pdf13.1' to `ps2pdf.1': Operation not
supported by device
ln: cannot create symbolic link `ps2pdf12.1' to `ps2pdf.1': Operation not
supported by device
ln: cannot create symbolic link `ps2pdf13.1' to `ps2pdf.1': Operation not
supported by device
ln: cannot create symbolic link `eps2eps.1' to `ps2ps.1': Operation not
supported by device
ln: cannot create symbolic link `ps2pdf12.1' to `ps2pdf.1': Operation not
supported by device
ln: cannot create symbolic link `ps2pdf13.1' to `ps2pdf.1': Operation not
supported by device
ln: cannot create symbolic link `eps2eps.1' to `ps2ps.1': Operation not
supported by device
ln: cannot create symbolic link `ps2pdf12.1' to `ps2pdf.1': Operation not
supported by device
ln: cannot create symbolic link `ps2pdf13.1' to `ps2pdf.1': Operation not
supported by device


(some devices support links, but I access the same volume from 3 completely
different OS's and the only devices available to all 3 systems dont support
links!)

for this latter set of documentation files it was too much effort to do a cp
script
and I didnt bother!

(besides I tend to read the script directly to determine how to use it)

I think the above 2 lists are the entirety of the links, the first set is the

entirety for the main archive, and the second set are the ones which are
clearly
visible in "make install"

its possible there may be some further ones that have evaded notice.


>If you use the msvc32.mak top level makefile it uses settings
>compatible with Windows filesystems.

they seem to be using ; as a separator


, seems to function here. with : the gs binary thinks its a list of volumes!













_______________________________________________
gs-devel mailing list
gs-devel@...
http://www.ghostscript.com/mailman/listinfo/gs-devel

[lazer1]

On 09-Oct-09, lazer1 wrote:
>On 09-Oct-09, Ralph Giles wrote:
>>On Fri, Oct 9, 2009 at 11:38 AM, lazer1 <lazer1@...> wrote:

>>> 1. is it possible to remove the usage of file links from the entire build,
>>> eg the archive for a start uses file links, and "make install" uses some?
>>>
>>> As that requires the usage of a filesystem with *nix compliant links,

>>The unix install script does assume it's running on a unix system,
>>yes. Links are used to maintain the same file under multiple names;
>>it's not just about saving space.

>the links at the moment are:

>for the main gs860 archive I need to run the following script:

>#!/bin/sh
>cd ghostscript-8.60
>cp src/configure.ac configure.ac
>cp /usr/share/libtool/config.guess ijs/config.guess
>cp /usr/share/libtool/config.sub   ijs/config.sub
>cp /usr/share/libtool/ltmain.sh    ijs/ltmain.sh
>cp /usr/share/automake/missing     ijs/missing
>cp /usr/share/automake/install-sh  ijs/install-sh
>cp src/Makefile.in                 Makefile.in
>cd ..

gs870 is a lot better with just 2 links:

cp base/configure.ac configure.ac
cp base/Makefile.in .


there is a slight error with gs870 which I will probably report at
bugs.ghostscript.com:

base/errors.h has

#include "ierrors.h"

when in fact ierrors.h is in a different directory psi

one of my source files references the above.

I corrected it using

#include "../psi/ierrors.h"





>to achieve the effect of the links, looking more carefully I see that the

>/usr/share ones are in fact links from outside the archive,

>(its very confusing how cp does the args in a different order from ln)

>could those be moved from the archive to the configure or makefile?

>or is that a problem for the ijs project?


>for "make install" the link error messages are:

>ln: cannot create symbolic link `ps2pdf12.1' to `ps2pdf.1': Operation not
>supported by device
>ln: cannot create symbolic link `ps2pdf13.1' to `ps2pdf.1': Operation not
>supported by device
>ln: cannot create symbolic link `ps2pdf12.1' to `ps2pdf.1': Operation not
>supported by device
>ln: cannot create symbolic link `ps2pdf13.1' to `ps2pdf.1': Operation not
>supported by device
>ln: cannot create symbolic link `eps2eps.1' to `ps2ps.1': Operation not
>supported by device
>ln: cannot create symbolic link `ps2pdf12.1' to `ps2pdf.1': Operation not
>supported by device
>ln: cannot create symbolic link `ps2pdf13.1' to `ps2pdf.1': Operation not
>supported by device
>ln: cannot create symbolic link `eps2eps.1' to `ps2ps.1': Operation not
>supported by device
>ln: cannot create symbolic link `ps2pdf12.1' to `ps2pdf.1': Operation not
>supported by device
>ln: cannot create symbolic link `ps2pdf13.1' to `ps2pdf.1': Operation not
>supported by device
>ln: cannot create symbolic link `ps2pdf12.1' to `ps2pdf.1': Operation not
>supported by device
>ln: cannot create symbolic link `ps2pdf13.1' to `ps2pdf.1': Operation not
>supported by device
>ln: cannot create symbolic link `eps2eps.1' to `ps2ps.1': Operation not
>supported by device
>ln: cannot create symbolic link `ps2pdf12.1' to `ps2pdf.1': Operation not
>supported by device
>ln: cannot create symbolic link `ps2pdf13.1' to `ps2pdf.1': Operation not
>supported by device
>ln: cannot create symbolic link `eps2eps.1' to `ps2ps.1': Operation not
>supported by device
>ln: cannot create symbolic link `ps2pdf12.1' to `ps2pdf.1': Operation not
>supported by device
>ln: cannot create symbolic link `ps2pdf13.1' to `ps2pdf.1': Operation not
>supported by device

eventually got round to redoing these links using cp and then found in fact
that

it is just 3 links!

the above long list is in fact endless repeats of the same 3 links.


>(some devices support links, but I access the same volume from 3 completely
>different OS's and the only devices available to all 3 systems dont support
>links!)

>for this latter set of documentation files it was too much effort to do a cp
>script
>and I didnt bother!

>(besides I tend to read the script directly to determine how to use it)

>I think the above 2 lists are the entirety of the links, the first set is the

>entirety for the main archive, and the second set are the ones which are
>clearly
>visible in "make install"

>its possible there may be some further ones that have evaded notice.


>>If you use the msvc32.mak top level makefile it uses settings
>>compatible with Windows filesystems.

>they seem to be using ; as a separator


>, seems to function here. with : the gs binary thinks its a list of volumes!













>_______________________________________________
>gs-devel mailing list
>gs-devel@...
>http://www.ghostscript.com/mailman/listinfo/gs-devel





_______________________________________________
gs-devel mailing list
gs-devel@...
http://www.ghostscript.com/mailman/listinfo/gs-devel