subject:"dmake"



leginee commented on pull request #113:
URL: https://github.com/apache/openoffice/pull/113#issuecomment-747527573


   Worth a test. :)



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

[GitHub] [openoffice] ardovm commented on pull request #113: Avoid "dmake clean" to wipe out the whole tree



ardovm commented on pull request #113:
URL: https://github.com/apache/openoffice/pull/113#issuecomment-747509362


   By the way, I followed that "pattern" as is it the same for the `install` 
target in the same file:
   
   ```Makefile
   install .PHONY :
@test "$(DESTDIR)$(prefix)" != "" || (echo Usage: make install 
[DESTDIR=DIR] prefix=DIR; exit 2)
   [...]
   ```



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

[GitHub] [openoffice] ardovm commented on pull request #113: Avoid "dmake clean" to wipe out the whole tree



ardovm commented on pull request #113:
URL: https://github.com/apache/openoffice/pull/113#issuecomment-747507745


   @leginee I was also surprised it works :-)
   
   Proof:
   ```
   $ echo Hello world; echo Hallo Welt
   Hello world
   Hallo Welt
   $
   ```



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

[GitHub] [openoffice] leginee commented on pull request #113: Avoid "dmake clean" to wipe out the whole tree



leginee commented on pull request #113:
URL: https://github.com/apache/openoffice/pull/113#issuecomment-747446201


   hmm, that echo needs no quotes in 
   ` echo Build environment not set; works without Quotes?` 
   looks strange. Is it special on make files that they can omit these?



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

[GitHub] [openoffice] ardovm opened a new pull request #113: Avoid "dmake clean" to wipe out the whole tree

2020-12-16 Thread GitBox



ardovm opened a new pull request #113:
URL: https://github.com/apache/openoffice/pull/113


   As per a recent thread on the dev@ mailing list, the "dmake clean" command 
may wipe out the whole source tree, if the build environment was not set by 
sourcing the appropriate `.Env` script.
   
   This PR has the purpose to fix the problem, assuming that if the build 
environment is not set, then the "dmake clean" command must not do anything.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: issue with dmake clean

2020-12-16 Thread Don Lewis

On 16 Dec, Arrigo Marchiori wrote:
> Hello all,
> 
> On Tue, Dec 15, 2020 at 05:56:48PM -0500, Carl Marcum wrote:
> 
>> On 12/15/20 3:37 PM, Peter Kovacs wrote:
>> > 
>> > On 15.12.20 20:14, Jim Jagielski wrote:
>> > > 
>> > > > On Dec 15, 2020, at 12:57 PM, Matthias Seidel
>> > > >  wrote:
>> > > > 
>> > > > Hi Carl,
>> > > > 
>> > > > Am 13.12.20 um 23:43 schrieb Carl Marcum:
>> > > > > Hi Matthias,
>> > > > > 
>> > > > > On 12/13/20 4:29 PM, Matthias Seidel wrote:
>> > > > > > Hi Carl,
>> > > > > > 
>> > > > > > Am 13.12.20 um 19:02 schrieb Carl Marcum:
>> > > > > > > Hi all,
>> > > > > > > 
>> > > > > > > Just ran into something.
>> > > > > > > 
>> > > > > > > I ran 'dmake clean' from main probably without having ran source
>> > > > > > >  and it removed all of my directories under 
>> > > > > > > main.
>> > > > > > Tried to do that on Windows (Cygwin64), went into main,
>> > > > > > did "autoconf",
>> > > > > > "dmake clean":
>> > > > > > 
>> > > > > > $ dmake clean
>> > > > > > -bash: dmake: command not found
>> > > > > > 
>> > > > > > Only after "source winenv.set.sh" it did clean up what it should...
>> > > > > It could be because I have a built and installed dmake on my system.
>> > > > > 
>> > > > > Thanks for checking!
>> > > > If an installed dmake does have this consequence we should have
>> > > > a closer
>> > > > look at it...
>> > > > 
>> > > It must be getting those commands from a makefile somewhere
>> > > though... dmake itself has no concept of 'clean' independent of what
>> > > a makefile tells it it is AFAIK
>> > 
>> > there is a makefile on that level. However I think it is for make and
>> > not for dmake. At least when I want to reset the build for sure I do a
>> > dmake clean (from instsetoo_native)first, followed by a make clean
>> > (main).
>> > 
>> > And the make clean has this rm command and removes all sorts of stuff.
>> > Could it be that if you execute dmake clean on main folder will let
>> > dmake read the make file ment for gnumake?
> [...]
>> I've had it happen twice now and it's a pain when it happens but probably
>> not dmake's fault.
> 
> If main/makefile.mk is used by dmake, then that could be the culprit.
> 
> The clean target does:
> 
>> clean .PHONY:
>> -rm -rf */$(INPATH)
> [... the rest is uninportant ...]
> 
> The INPATH variable is set by the Env.sh script
> If the env.sh script is not set, then the command is interpreted as:
> rm -rf */
> 
> I don't know dmake, but if it was GNU Make a possible fix would be
> something like:
> 
>> clean .PHONY:
>> if [ -z "$(INPATH)" ]; then echo "Environment not set!"; exit 1; fi
>> -rm -rf */$(INPATH)
> [... the rest same as above ...]

Something like that is what I would recommend.



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: issue with dmake clean

2020-12-15 Thread Arrigo Marchiori

Hello all,

On Tue, Dec 15, 2020 at 05:56:48PM -0500, Carl Marcum wrote:

> On 12/15/20 3:37 PM, Peter Kovacs wrote:
> > 
> > On 15.12.20 20:14, Jim Jagielski wrote:
> > > 
> > > > On Dec 15, 2020, at 12:57 PM, Matthias Seidel
> > > >  wrote:
> > > > 
> > > > Hi Carl,
> > > > 
> > > > Am 13.12.20 um 23:43 schrieb Carl Marcum:
> > > > > Hi Matthias,
> > > > > 
> > > > > On 12/13/20 4:29 PM, Matthias Seidel wrote:
> > > > > > Hi Carl,
> > > > > > 
> > > > > > Am 13.12.20 um 19:02 schrieb Carl Marcum:
> > > > > > > Hi all,
> > > > > > > 
> > > > > > > Just ran into something.
> > > > > > > 
> > > > > > > I ran 'dmake clean' from main probably without having ran source
> > > > > > >  and it removed all of my directories under 
> > > > > > > main.
> > > > > > Tried to do that on Windows (Cygwin64), went into main,
> > > > > > did "autoconf",
> > > > > > "dmake clean":
> > > > > > 
> > > > > > $ dmake clean
> > > > > > -bash: dmake: command not found
> > > > > > 
> > > > > > Only after "source winenv.set.sh" it did clean up what it should...
> > > > > It could be because I have a built and installed dmake on my system.
> > > > > 
> > > > > Thanks for checking!
> > > > If an installed dmake does have this consequence we should have
> > > > a closer
> > > > look at it...
> > > > 
> > > It must be getting those commands from a makefile somewhere
> > > though... dmake itself has no concept of 'clean' independent of what
> > > a makefile tells it it is AFAIK
> > 
> > there is a makefile on that level. However I think it is for make and
> > not for dmake. At least when I want to reset the build for sure I do a
> > dmake clean (from instsetoo_native)first, followed by a make clean
> > (main).
> > 
> > And the make clean has this rm command and removes all sorts of stuff.
> > Could it be that if you execute dmake clean on main folder will let
> > dmake read the make file ment for gnumake?
[...]
> I've had it happen twice now and it's a pain when it happens but probably
> not dmake's fault.

If main/makefile.mk is used by dmake, then that could be the culprit.

The clean target does:

> clean .PHONY:
> -rm -rf */$(INPATH)
[... the rest is uninportant ...]

The INPATH variable is set by the Env.sh script
If the env.sh script is not set, then the command is interpreted as:
rm -rf */

I don't know dmake, but if it was GNU Make a possible fix would be
something like:

> clean .PHONY:
> if [ -z "$(INPATH)" ]; then echo "Environment not set!"; exit 1; fi
> -rm -rf */$(INPATH)
[... the rest same as above ...]

The GNU Make Makefile main/Makefile prevents this error. Its clean
target is in fact:

> clean:
> . ./*Env.Set.sh && \
> dmake clean

In English: first include the file ending with "Env.Set.sh" and only
then run "dmake clean".

I can issue a PR to fix makefile.mk but it will take me one or two
days; if no one can react any quicker, please let me know and I will
put this in my to-do list.

Regards,
-- 
rigo

http://rigo.altervista.org

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: issue with dmake clean

2020-12-15 Thread Carl Marcum





On 12/15/20 3:37 PM, Peter Kovacs wrote:


On 15.12.20 20:14, Jim Jagielski wrote:


On Dec 15, 2020, at 12:57 PM, Matthias Seidel 
 wrote:


Hi Carl,

Am 13.12.20 um 23:43 schrieb Carl Marcum:

Hi Matthias,

On 12/13/20 4:29 PM, Matthias Seidel wrote:

Hi Carl,

Am 13.12.20 um 19:02 schrieb Carl Marcum:

Hi all,

Just ran into something.

I ran 'dmake clean' from main probably without having ran source
 and it removed all of my directories under main.
Tried to do that on Windows (Cygwin64), went into main, did 
"autoconf",

"dmake clean":

$ dmake clean
-bash: dmake: command not found

Only after "source winenv.set.sh" it did clean up what it should...

It could be because I have a built and installed dmake on my system.

Thanks for checking!
If an installed dmake does have this consequence we should have a 
closer

look at it...

It must be getting those commands from a makefile somewhere though... 
dmake itself has no concept of 'clean' independent of what a makefile 
tells it it is AFAIK


there is a makefile on that level. However I think it is for make and 
not for dmake. At least when I want to reset the build for sure I do a 
dmake clean (from instsetoo_native)first, followed by a make clean 
(main).


And the make clean has this rm command and removes all sorts of stuff. 
Could it be that if you execute dmake clean on main folder will let 
dmake read the make file ment for gnumake?


In total I do not have a high confidence in general in our build 
system. It is complicated and complex. And if some things do not fit 
it will do unexpected things.




It could very well be the result of me using the same session for many 
builds and switching back and forth between branches in the same 
terminal session.


I've had it happen twice now and it's a pain when it happens but 
probably not dmake's fault.


I'll see if I can recreate it in a consistent way and report back.

Thanks,
Carl

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: issue with dmake clean

2020-12-15 Thread Peter Kovacs




On 15.12.20 20:14, Jim Jagielski wrote:



On Dec 15, 2020, at 12:57 PM, Matthias Seidel  
wrote:

Hi Carl,

Am 13.12.20 um 23:43 schrieb Carl Marcum:

Hi Matthias,

On 12/13/20 4:29 PM, Matthias Seidel wrote:

Hi Carl,

Am 13.12.20 um 19:02 schrieb Carl Marcum:

Hi all,

Just ran into something.

I ran 'dmake clean' from main probably without having ran source
 and it removed all of my directories under main.

Tried to do that on Windows (Cygwin64), went into main, did "autoconf",
"dmake clean":

$ dmake clean
-bash: dmake: command not found

Only after "source winenv.set.sh" it did clean up what it should...

It could be because I have a built and installed dmake on my system.

Thanks for checking!

If an installed dmake does have this consequence we should have a closer
look at it...


It must be getting those commands from a makefile somewhere though... dmake 
itself has no concept of 'clean' independent of what a makefile tells it it is 
AFAIK


there is a makefile on that level. However I think it is for make and 
not for dmake. At least when I want to reset the build for sure I do a 
dmake clean (from instsetoo_native)first, followed by a make clean (main).


And the make clean has this rm command and removes all sorts of stuff. 
Could it be that if you execute dmake clean on main folder will let 
dmake read the make file ment for gnumake?


In total I do not have a high confidence in general in our build system. 
It is complicated and complex. And if some things do not fit it will do 
unexpected things.


--
This is the Way! http://www.apache.org/theapacheway/index.html

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: issue with dmake clean

2020-12-15 Thread Jim Jagielski



> On Dec 15, 2020, at 12:57 PM, Matthias Seidel  
> wrote:
> 
> Hi Carl,
> 
> Am 13.12.20 um 23:43 schrieb Carl Marcum:
>> Hi Matthias,
>> 
>> On 12/13/20 4:29 PM, Matthias Seidel wrote:
>>> Hi Carl,
>>> 
>>> Am 13.12.20 um 19:02 schrieb Carl Marcum:
>>>> Hi all,
>>>> 
>>>> Just ran into something.
>>>> 
>>>> I ran 'dmake clean' from main probably without having ran source
>>>>  and it removed all of my directories under main.
>>> Tried to do that on Windows (Cygwin64), went into main, did "autoconf",
>>> "dmake clean":
>>> 
>>> $ dmake clean
>>> -bash: dmake: command not found
>>> 
>>> Only after "source winenv.set.sh" it did clean up what it should...
>> It could be because I have a built and installed dmake on my system.
>> 
>> Thanks for checking!
> 
> If an installed dmake does have this consequence we should have a closer
> look at it...
> 

It must be getting those commands from a makefile somewhere though... dmake 
itself has no concept of 'clean' independent of what a makefile tells it it is 
AFAIK

Re: issue with dmake clean

2020-12-15 Thread Matthias Seidel

Hi Carl,

Am 13.12.20 um 23:43 schrieb Carl Marcum:
> Hi Matthias,
>
> On 12/13/20 4:29 PM, Matthias Seidel wrote:
>> Hi Carl,
>>
>> Am 13.12.20 um 19:02 schrieb Carl Marcum:
>>> Hi all,
>>>
>>> Just ran into something.
>>>
>>> I ran 'dmake clean' from main probably without having ran source
>>>  and it removed all of my directories under main.
>> Tried to do that on Windows (Cygwin64), went into main, did "autoconf",
>> "dmake clean":
>>
>> $ dmake clean
>> -bash: dmake: command not found
>>
>> Only after "source winenv.set.sh" it did clean up what it should...
> It could be because I have a built and installed dmake on my system.
>
> Thanks for checking!

If an installed dmake does have this consequence we should have a closer
look at it...

I remember this bug in Steam:

https://www.theregister.com/2015/01/17/scary_code_of_the_week_steam_cleans_linux_pcs/

Regards,

   Matthias

>
>>
>> Regards,
>>
>>     Matthias
>>
>>> Looks like it ran 'rm -rf */'
>>>
>>> Best regards,
>>> Carl
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>



smime.p7s
Description: S/MIME Cryptographic Signature

Re: issue with dmake clean

2020-12-13 Thread Carl Marcum


Hi Matthias,

On 12/13/20 4:29 PM, Matthias Seidel wrote:

Hi Carl,

Am 13.12.20 um 19:02 schrieb Carl Marcum:

Hi all,

Just ran into something.

I ran 'dmake clean' from main probably without having ran source
 and it removed all of my directories under main.

Tried to do that on Windows (Cygwin64), went into main, did "autoconf",
"dmake clean":

$ dmake clean
-bash: dmake: command not found

Only after "source winenv.set.sh" it did clean up what it should...

It could be because I have a built and installed dmake on my system.

Thanks for checking!



Regards,

    Matthias


Looks like it ran 'rm -rf */'

Best regards,
Carl

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: issue with dmake clean

2020-12-13 Thread Matthias Seidel

Hi Carl,

Am 13.12.20 um 19:02 schrieb Carl Marcum:
> Hi all,
>
> Just ran into something.
>
> I ran 'dmake clean' from main probably without having ran source
>  and it removed all of my directories under main.

Tried to do that on Windows (Cygwin64), went into main, did "autoconf",
"dmake clean":

$ dmake clean
-bash: dmake: command not found

Only after "source winenv.set.sh" it did clean up what it should...

Regards,

   Matthias

>
> Looks like it ran 'rm -rf */'
>
> Best regards,
> Carl
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>



smime.p7s
Description: S/MIME Cryptographic Signature

issue with dmake clean

2020-12-13 Thread Carl Marcum


Hi all,

Just ran into something.

I ran 'dmake clean' from main probably without having ran source 
 and it removed all of my directories under main.


Looks like it ran 'rm -rf */'

Best regards,
Carl

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [openoffice] branch trunk updated: Point people to DMAKE 4.13.1

Hi Jim,

Now dmake (4.13.1) was successfully built on Windows!

Thanks!

Am 27.11.20 um 21:59 schrieb j...@apache.org:
> This is an automated email from the ASF dual-hosted git repository.
>
> jim pushed a commit to branch trunk
> in repository https://gitbox.apache.org/repos/asf/openoffice.git
>
>
> The following commit(s) were added to refs/heads/trunk by this push:
>  new e6d389b  Point people to DMAKE 4.13.1
> e6d389b is described below
>
> commit e6d389b340cbb79271b7f48640ce0dd0c850d4d2
> Author: Jim Jagielski 
> AuthorDate: Fri Nov 27 15:59:03 2020 -0500
>
> Point people to DMAKE 4.13.1
> ---
>  main/configure.ac | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/main/configure.ac b/main/configure.ac
> index 8b54a22..c927b12 100644
> --- a/main/configure.ac
> +++ b/main/configure.ac
> @@ -28,7 +28,7 @@ AC_ARG_WITH(dmake-path,
>  ])
>  AC_ARG_WITH(dmake-url,
>  [  --with-dmake-url=   Specify the location of downloadable dmake 
> source code. For example:
> -  
> https://github.com/jimjag/dmake/archive/v4.13.0/dmake-4.13.0.tar.gz
> +  
> https://github.com/jimjag/dmake/archive/v4.13.1/dmake-4.13.1.tar.gz
>Note that dmake is under GPL license.],
>  [  DMAKE_URL="$withval"
>  ])
>



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [openoffice] branch trunk updated: New URL for dmake

2020-11-27 Thread Jim Jagielski

Try w/ https://github.com/jimjag/dmake/archive/v4.13.1/dmake-4.13.1.tar.gz

> On Nov 27, 2020, at 3:50 PM, Matthias Seidel  
> wrote:
> 
> Hi Jim,
> 
> Am 27.11.20 um 21:38 schrieb Jim Jagielski:
>> I don't think that patch is needed anymore... IIRC it removed 
>> cygwin_conv_to_posix_path, which is already done in dmake-4.13
> Now I get this error and dmake does not build (in Cygwin 64):
> 
> ---
> 
> sysintf.c: In function ‘cygdospath’:
> sysintf.c:1151:17: warning: implicit declaration of function
> ‘cygwin_conv_to_win32_path’; did you mean ‘cygwin_conv_path’?
> [-Wimplicit-function-declaration]
>  1151 |   int err = cygwin_conv_to_win32_path(src, buf);
>   | ^
>   | cygwin_conv_path
> 
> ...
> 
> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
> sysintf.o: in function `cygdospath':
> /cygdrive/c/Source/openoffice/main/solenv/wntmsci12.pro/misc/build/dmake-4.13.0/sysintf.c:1151:
> undefined reference to `cygwin_conv_to_win32_path'
> /cygdrive/c/Source/openoffice/main/solenv/wntmsci12.pro/misc/build/dmake-4.13.0/sysintf.c:1151:(.text+0x1203):
> relocation truncated to fit: R_X86_64_PC32 against undefined symbol
> `cygwin_conv_to_win32_path'
> collect2: error: ld returned 1 exit status
> make[2]: *** [Makefile:584: dmake.exe] Error 1
> make[2]: Leaving directory
> '/cygdrive/c/Source/openoffice/main/solenv/wntmsci12.pro/misc/build/dmake-4.13.0'
> make[1]: *** [Makefile:661: all-recursive] Error 1
> make[1]: Leaving directory
> '/cygdrive/c/Source/openoffice/main/solenv/wntmsci12.pro/misc/build/dmake-4.13.0'
> make: *** [Makefile:427: all] Error 2
> 
> ---
> 
> Regards,
> 
>Matthias
> 
>> 
>> 
>> 
>>> On Nov 27, 2020, at 1:14 PM, Matthias Seidel  
>>> wrote:
>>> 
>>> Additionally, since this happens when building on Windows, the patch
>>> seems to be:
>>> 
>>> /main/solenv/src/dmake-cygwin64.patch
>>> 
>>> It was made by Damjan for the planned Windows 64 build.
>>> 
>>> Regards,
>>> 
>>>   Matthias
>>> 
>>> Am 27.11.20 um 18:41 schrieb Matthias Seidel:
>>>> Hi Jim,
>>>> 
>>>> Tried with dmake 4.13.0:
>>>> 
>>>> making and entering
>>>> C:/Source/openoffice/main/solenv/wntmsci12.pro/misc/build/
>>>> unpacking
>>>> /cygdrive/c/Source/openoffice/ext_sources/07927163cc251770d2624d816f2e9b9e-dmake-4.13.0.tar.gz
>>>> entering dmake-4.13.0
>>>> patching file path.c
>>>> Hunk #1 FAILED at 317.
>>>> 1 out of 1 hunk FAILED -- saving rejects to file path.c.rej
>>>> patching file sysintf.c
>>>> Hunk #1 FAILED at 69.
>>>> Hunk #2 FAILED at 538.
>>>> Hunk #3 succeeded at 1148 (offset 4 lines).
>>>> 2 out of 3 hunks FAILED -- saving rejects to file sysintf.c.rej
>>>> 
>>>> Are these patches still needed?
>>>> 
>>>> Regards,
>>>> 
>>>>   Matthias
>>>> 
>>>> Am 27.11.20 um 15:32 schrieb j...@apache.org:
>>>>> This is an automated email from the ASF dual-hosted git repository.
>>>>> 
>>>>> jim pushed a commit to branch trunk
>>>>> in repository https://gitbox.apache.org/repos/asf/openoffice.git
>>>>> 
>>>>> 
>>>>> The following commit(s) were added to refs/heads/trunk by this push:
>>>>>new 6d55344  New URL for dmake
>>>>> 6d55344 is described below
>>>>> 
>>>>> commit 6d55344ade3d5a22c457d996194d8d8a0bbeee82
>>>>> Author: Jim Jagielski 
>>>>> AuthorDate: Fri Nov 27 09:32:21 2020 -0500
>>>>> 
>>>>>   New URL for dmake
>>>>> ---
>>>>> main/configure.ac | 2 +-
>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>> 
>>>>> diff --git a/main/configure.ac b/main/configure.ac
>>>>> index 430b796..8b54a22 100644
>>>>> --- a/main/configure.ac
>>>>> +++ b/main/configure.ac
>>>>> @@ -28,7 +28,7 @@ AC_ARG_WITH(dmake-path,
>>>>> ])
>>>>> AC_ARG_WITH(dmake-url,
>>>>> [  --with-dmake-url=   Specify the location of downloadable dmake 
>>>>> source code. For example:
>>>>> -  
>>>>> https://sourceforge.net/projects/oooextras.mirror/files/dmake-4.12.tar.bz2
>>>>> +  
>>>>> https://github.com/jimjag/dmake/archive/v4.13.0/dmake-4.13.0.tar.gz
>>>>>  Note that dmake is under GPL license.],
>>>>> [  DMAKE_URL="$withval"
>>>>> ])
>>>>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>> 
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [openoffice] branch trunk updated: New URL for dmake

Hi Jim,

Am 27.11.20 um 21:38 schrieb Jim Jagielski:
> I don't think that patch is needed anymore... IIRC it removed 
> cygwin_conv_to_posix_path, which is already done in dmake-4.13
Now I get this error and dmake does not build (in Cygwin 64):

---

sysintf.c: In function ‘cygdospath’:
sysintf.c:1151:17: warning: implicit declaration of function
‘cygwin_conv_to_win32_path’; did you mean ‘cygwin_conv_path’?
[-Wimplicit-function-declaration]
 1151 |   int err = cygwin_conv_to_win32_path(src, buf);
  | ^
  | cygwin_conv_path

...

/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
sysintf.o: in function `cygdospath':
/cygdrive/c/Source/openoffice/main/solenv/wntmsci12.pro/misc/build/dmake-4.13.0/sysintf.c:1151:
undefined reference to `cygwin_conv_to_win32_path'
/cygdrive/c/Source/openoffice/main/solenv/wntmsci12.pro/misc/build/dmake-4.13.0/sysintf.c:1151:(.text+0x1203):
relocation truncated to fit: R_X86_64_PC32 against undefined symbol
`cygwin_conv_to_win32_path'
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:584: dmake.exe] Error 1
make[2]: Leaving directory
'/cygdrive/c/Source/openoffice/main/solenv/wntmsci12.pro/misc/build/dmake-4.13.0'
make[1]: *** [Makefile:661: all-recursive] Error 1
make[1]: Leaving directory
'/cygdrive/c/Source/openoffice/main/solenv/wntmsci12.pro/misc/build/dmake-4.13.0'
make: *** [Makefile:427: all] Error 2

---

Regards,

   Matthias

>
>
>
>> On Nov 27, 2020, at 1:14 PM, Matthias Seidel  
>> wrote:
>>
>> Additionally, since this happens when building on Windows, the patch
>> seems to be:
>>
>> /main/solenv/src/dmake-cygwin64.patch
>>
>> It was made by Damjan for the planned Windows 64 build.
>>
>> Regards,
>>
>>    Matthias
>>
>> Am 27.11.20 um 18:41 schrieb Matthias Seidel:
>>> Hi Jim,
>>>
>>> Tried with dmake 4.13.0:
>>>
>>> making and entering
>>> C:/Source/openoffice/main/solenv/wntmsci12.pro/misc/build/
>>> unpacking
>>> /cygdrive/c/Source/openoffice/ext_sources/07927163cc251770d2624d816f2e9b9e-dmake-4.13.0.tar.gz
>>> entering dmake-4.13.0
>>> patching file path.c
>>> Hunk #1 FAILED at 317.
>>> 1 out of 1 hunk FAILED -- saving rejects to file path.c.rej
>>> patching file sysintf.c
>>> Hunk #1 FAILED at 69.
>>> Hunk #2 FAILED at 538.
>>> Hunk #3 succeeded at 1148 (offset 4 lines).
>>> 2 out of 3 hunks FAILED -- saving rejects to file sysintf.c.rej
>>>
>>> Are these patches still needed?
>>>
>>> Regards,
>>>
>>>Matthias
>>>
>>> Am 27.11.20 um 15:32 schrieb j...@apache.org:
>>>> This is an automated email from the ASF dual-hosted git repository.
>>>>
>>>> jim pushed a commit to branch trunk
>>>> in repository https://gitbox.apache.org/repos/asf/openoffice.git
>>>>
>>>>
>>>> The following commit(s) were added to refs/heads/trunk by this push:
>>>> new 6d55344  New URL for dmake
>>>> 6d55344 is described below
>>>>
>>>> commit 6d55344ade3d5a22c457d996194d8d8a0bbeee82
>>>> Author: Jim Jagielski 
>>>> AuthorDate: Fri Nov 27 09:32:21 2020 -0500
>>>>
>>>>New URL for dmake
>>>> ---
>>>> main/configure.ac | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/main/configure.ac b/main/configure.ac
>>>> index 430b796..8b54a22 100644
>>>> --- a/main/configure.ac
>>>> +++ b/main/configure.ac
>>>> @@ -28,7 +28,7 @@ AC_ARG_WITH(dmake-path,
>>>> ])
>>>> AC_ARG_WITH(dmake-url,
>>>> [  --with-dmake-url=   Specify the location of downloadable dmake 
>>>> source code. For example:
>>>> -  
>>>> https://sourceforge.net/projects/oooextras.mirror/files/dmake-4.12.tar.bz2
>>>> +  
>>>> https://github.com/jimjag/dmake/archive/v4.13.0/dmake-4.13.0.tar.gz
>>>>   Note that dmake is under GPL license.],
>>>> [  DMAKE_URL="$withval"
>>>> ])
>>>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [openoffice] branch trunk updated: New URL for dmake

2020-11-27 Thread Jim Jagielski

I don't think that patch is needed anymore... IIRC it removed 
cygwin_conv_to_posix_path, which is already done in dmake-4.13



> On Nov 27, 2020, at 1:14 PM, Matthias Seidel  
> wrote:
> 
> Additionally, since this happens when building on Windows, the patch
> seems to be:
> 
> /main/solenv/src/dmake-cygwin64.patch
> 
> It was made by Damjan for the planned Windows 64 build.
> 
> Regards,
> 
>Matthias
> 
> Am 27.11.20 um 18:41 schrieb Matthias Seidel:
>> Hi Jim,
>> 
>> Tried with dmake 4.13.0:
>> 
>> making and entering
>> C:/Source/openoffice/main/solenv/wntmsci12.pro/misc/build/
>> unpacking
>> /cygdrive/c/Source/openoffice/ext_sources/07927163cc251770d2624d816f2e9b9e-dmake-4.13.0.tar.gz
>> entering dmake-4.13.0
>> patching file path.c
>> Hunk #1 FAILED at 317.
>> 1 out of 1 hunk FAILED -- saving rejects to file path.c.rej
>> patching file sysintf.c
>> Hunk #1 FAILED at 69.
>> Hunk #2 FAILED at 538.
>> Hunk #3 succeeded at 1148 (offset 4 lines).
>> 2 out of 3 hunks FAILED -- saving rejects to file sysintf.c.rej
>> 
>> Are these patches still needed?
>> 
>> Regards,
>> 
>>Matthias
>> 
>> Am 27.11.20 um 15:32 schrieb j...@apache.org:
>>> This is an automated email from the ASF dual-hosted git repository.
>>> 
>>> jim pushed a commit to branch trunk
>>> in repository https://gitbox.apache.org/repos/asf/openoffice.git
>>> 
>>> 
>>> The following commit(s) were added to refs/heads/trunk by this push:
>>> new 6d55344  New URL for dmake
>>> 6d55344 is described below
>>> 
>>> commit 6d55344ade3d5a22c457d996194d8d8a0bbeee82
>>> Author: Jim Jagielski 
>>> AuthorDate: Fri Nov 27 09:32:21 2020 -0500
>>> 
>>>    New URL for dmake
>>> ---
>>> main/configure.ac | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>> 
>>> diff --git a/main/configure.ac b/main/configure.ac
>>> index 430b796..8b54a22 100644
>>> --- a/main/configure.ac
>>> +++ b/main/configure.ac
>>> @@ -28,7 +28,7 @@ AC_ARG_WITH(dmake-path,
>>> ])
>>> AC_ARG_WITH(dmake-url,
>>> [  --with-dmake-url=   Specify the location of downloadable dmake 
>>> source code. For example:
>>> -  
>>> https://sourceforge.net/projects/oooextras.mirror/files/dmake-4.12.tar.bz2
>>> +  
>>> https://github.com/jimjag/dmake/archive/v4.13.0/dmake-4.13.0.tar.gz
>>>   Note that dmake is under GPL license.],
>>> [  DMAKE_URL="$withval"
>>> ])
>>> 
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [openoffice] branch trunk updated: New URL for dmake

Additionally, since this happens when building on Windows, the patch
seems to be:

/main/solenv/src/dmake-cygwin64.patch

It was made by Damjan for the planned Windows 64 build.

Regards,

   Matthias

Am 27.11.20 um 18:41 schrieb Matthias Seidel:
> Hi Jim,
>
> Tried with dmake 4.13.0:
>
> making and entering
> C:/Source/openoffice/main/solenv/wntmsci12.pro/misc/build/
> unpacking
> /cygdrive/c/Source/openoffice/ext_sources/07927163cc251770d2624d816f2e9b9e-dmake-4.13.0.tar.gz
> entering dmake-4.13.0
> patching file path.c
> Hunk #1 FAILED at 317.
> 1 out of 1 hunk FAILED -- saving rejects to file path.c.rej
> patching file sysintf.c
> Hunk #1 FAILED at 69.
> Hunk #2 FAILED at 538.
> Hunk #3 succeeded at 1148 (offset 4 lines).
> 2 out of 3 hunks FAILED -- saving rejects to file sysintf.c.rej
>
> Are these patches still needed?
>
> Regards,
>
>    Matthias
>
> Am 27.11.20 um 15:32 schrieb j...@apache.org:
>> This is an automated email from the ASF dual-hosted git repository.
>>
>> jim pushed a commit to branch trunk
>> in repository https://gitbox.apache.org/repos/asf/openoffice.git
>>
>>
>> The following commit(s) were added to refs/heads/trunk by this push:
>>  new 6d55344  New URL for dmake
>> 6d55344 is described below
>>
>> commit 6d55344ade3d5a22c457d996194d8d8a0bbeee82
>> Author: Jim Jagielski 
>> AuthorDate: Fri Nov 27 09:32:21 2020 -0500
>>
>> New URL for dmake
>> ---
>>  main/configure.ac | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/main/configure.ac b/main/configure.ac
>> index 430b796..8b54a22 100644
>> --- a/main/configure.ac
>> +++ b/main/configure.ac
>> @@ -28,7 +28,7 @@ AC_ARG_WITH(dmake-path,
>>  ])
>>  AC_ARG_WITH(dmake-url,
>>  [  --with-dmake-url=   Specify the location of downloadable dmake 
>> source code. For example:
>> -      
>> https://sourceforge.net/projects/oooextras.mirror/files/dmake-4.12.tar.bz2
>> +  
>> https://github.com/jimjag/dmake/archive/v4.13.0/dmake-4.13.0.tar.gz
>>Note that dmake is under GPL license.],
>>  [  DMAKE_URL="$withval"
>>  ])
>>



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [openoffice] branch trunk updated: New URL for dmake

Hi Jim,

Tried with dmake 4.13.0:

making and entering
C:/Source/openoffice/main/solenv/wntmsci12.pro/misc/build/
unpacking
/cygdrive/c/Source/openoffice/ext_sources/07927163cc251770d2624d816f2e9b9e-dmake-4.13.0.tar.gz
entering dmake-4.13.0
patching file path.c
Hunk #1 FAILED at 317.
1 out of 1 hunk FAILED -- saving rejects to file path.c.rej
patching file sysintf.c
Hunk #1 FAILED at 69.
Hunk #2 FAILED at 538.
Hunk #3 succeeded at 1148 (offset 4 lines).
2 out of 3 hunks FAILED -- saving rejects to file sysintf.c.rej

Are these patches still needed?

Regards,

   Matthias

Am 27.11.20 um 15:32 schrieb j...@apache.org:
> This is an automated email from the ASF dual-hosted git repository.
>
> jim pushed a commit to branch trunk
> in repository https://gitbox.apache.org/repos/asf/openoffice.git
>
>
> The following commit(s) were added to refs/heads/trunk by this push:
>  new 6d55344  New URL for dmake
> 6d55344 is described below
>
> commit 6d55344ade3d5a22c457d996194d8d8a0bbeee82
> Author: Jim Jagielski 
> AuthorDate: Fri Nov 27 09:32:21 2020 -0500
>
> New URL for dmake
> ---
>  main/configure.ac | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/main/configure.ac b/main/configure.ac
> index 430b796..8b54a22 100644
> --- a/main/configure.ac
> +++ b/main/configure.ac
> @@ -28,7 +28,7 @@ AC_ARG_WITH(dmake-path,
>  ])
>  AC_ARG_WITH(dmake-url,
>  [  --with-dmake-url=   Specify the location of downloadable dmake 
> source code. For example:
> -      
> https://sourceforge.net/projects/oooextras.mirror/files/dmake-4.12.tar.bz2
> +  
> https://github.com/jimjag/dmake/archive/v4.13.0/dmake-4.13.0.tar.gz
>Note that dmake is under GPL license.],
>  [  DMAKE_URL="$withval"
>  ])
>



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Errors in bootstrap while building dmake

2020-02-25 Thread Matthias Seidel


Am 25.02.20 um 12:04 schrieb Peter Kovacs:
> wohoo!
>
> Not our issue are the best issues!

Definitely!

See:

https://cygwin.com/ml/cygwin/2020-02/msg00228.html

Regards,

   Matthias

>
> Am 25.02.20 um 12:03 schrieb Matthias Seidel:
>> Hi all,
>>
>> Just today, there was an update of "binutils" for Cygwin and now the
>> errors are gone... ;-)
>>
>> Sorry for the trouble, I am just doing a new build now!
>>
>> Regards,
>>
>>     Matthias
>>
>> Am 24.02.20 um 18:23 schrieb Matthias Seidel:
>>> Hi,
>>>
>>> Am 24.02.20 um 18:18 schrieb Peter Kovacs:
>>>> can you post what g++ -v prints on bash?
>>> ---
>>> $ g++ -v
>>> Es werden eingebaute Spezifikationen verwendet.
>>> COLLECT_GCC=g++
>>> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/9.2.0/lto-wrapper.exe
>>> Ziel: x86_64-pc-cygwin
>>> Konfiguriert mit:
>>> /cygdrive/i/szsz/tmpp/gcc/gcc-9.2.0-2.x86_64/src/gcc-9.2.0/configure
>>> --srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-9.2.0-2.x86_64/src/gcc-9.2.0
>>> --prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc
>>> --docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C
>>> --build=x86_64-pc-cygwin --host=x86_64-pc-cygwin
>>> --target=x86_64-pc-cygwin --without-libiconv-prefix
>>> --without-libintl-prefix --libexecdir=/usr/lib --enable-shared
>>> --enable-shared-libgcc --enable-static
>>> --enable-version-specific-runtime-libs --enable-bootstrap
>>> --enable-__cxa_atexit --with-dwarf2 --with-tune=generic
>>> --enable-languages=c,c++,fortran,lto,objc,obj-c++ --enable-graphite
>>> --enable-threads=posix --enable-libatomic --enable-libgomp
>>> --enable-libquadmath --enable-libquadmath-support --disable-libssp
>>> --enable-libada --disable-symvers --with-gnu-ld --with-gnu-as
>>> --with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix
>>> --without-libintl-prefix --with-system-zlib --enable-linker-build-id
>>> --with-default-libstdcxx-abi=gcc4-compatible
>>> --enable-libstdcxx-filesystem-ts
>>> Thread-Modell: posix
>>> gcc-Version 9.2.0 (GCC)
>>>
>>> ---
>>>
>>> (This is Cygwin64)
>>> gcc was updated yesterday. I even downgraded to 7.3.0-3 with no effect.
>>>
>>> Regards,
>>>
>>>     Matthias
>>>
>>>> Am 24.02.20 um 17:40 schrieb Matthias Seidel:
>>>>> Hi all,
>>>>>
>>>>> After updating a lot of packages (incl. gcc) in Cygwin64 yesterday
>>>>> I can
>>>>> no longer build AOO for Windows.
>>>>>
>>>>> I get errors in bootstrap while building dmake:
>>>>>
>>>>> make[2]: Verzeichnis
>>>>> „/cygdrive/c/Source/openoffice/main/solenv/wntmsci12.pro/misc/build/dmake-4.12“
>>>>>
>>>>>
>>>>> wird betreten
>>>>> depbase=`echo infer.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`; \
>>>>> if gcc -DHAVE_CONFIG_H -I. -I. -I. -I. -I. -I./unix/cygwin -I./unix
>>>>> -I./unix/cygwin/gnu -I./unix/cygwin -I./unix  -g -O2 -MT
>>>>> infer.o -MD
>>>>> -MP -MF "$depbase.Tpo" -c -o infer.o infer.c; \
>>>>> then mv -f "$depbase.Tpo" "$depbase.Po"; else rm -f
>>>>> "$depbase.Tpo"; exit
>>>>> 1; fi
>>>>> In Datei, eingebunden von extern.h:38,
>>>>>    von infer.c:33:
>>>>> config.h:188:16: Fehler: doppeltes »unsigned«
>>>>>     188 | #define size_t unsigned int
>>>>>     |    ^~~~
>>>>> config.h:188:25: Fehler: zwei oder mehr Datentypen in Deklaration
>>>>>     188 | #define size_t unsigned int
>>>>>     | ^~~
>>>>> config.h:185:15: Fehler: zwei oder mehr Datentypen in Deklaration
>>>>>     185 | #define off_t long int
>>>>>     |   ^~~~
>>>>> config.h:185:20: Fehler: zwei oder mehr Datentypen in Deklaration
>>>>>     185 | #define off_t long int
>>>>>     |    ^~~
>>>>> In Datei, eingebunden von extern.h:86,
>>>>>    von infer.c:33:
>>>>> itypes.h:58:5: Fehler: #error "No 2 byte type, you lose."
>>>>>  58 | #   error "No 2 byte type, you lose."
>>>>>     | ^
>>>>> itypes.h:77:5: Fehler: #error "No 4 byte type, you lose."
>>>>>  77 | #   error "No 4 byte type, you lose."
>>>>>     | ^
>>>>> ...
>>>>>
>>>>>
>>>>> Is there anything we can do to ensure that AOO can be built with an
>>>>> updated Cygwin?
>>>>> Would Jim's updated dmake help?
>>>>>
>>>>> Regards,
>>>>>  Matthias
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>>>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Errors in bootstrap while building dmake

2020-02-25 Thread Peter Kovacs


wohoo!

Not our issue are the best issues!

Am 25.02.20 um 12:03 schrieb Matthias Seidel:

Hi all,

Just today, there was an update of "binutils" for Cygwin and now the
errors are gone... ;-)

Sorry for the trouble, I am just doing a new build now!

Regards,

    Matthias

Am 24.02.20 um 18:23 schrieb Matthias Seidel:

Hi,

Am 24.02.20 um 18:18 schrieb Peter Kovacs:

can you post what g++ -v prints on bash?

---
$ g++ -v
Es werden eingebaute Spezifikationen verwendet.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/9.2.0/lto-wrapper.exe
Ziel: x86_64-pc-cygwin
Konfiguriert mit:
/cygdrive/i/szsz/tmpp/gcc/gcc-9.2.0-2.x86_64/src/gcc-9.2.0/configure
--srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-9.2.0-2.x86_64/src/gcc-9.2.0
--prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc
--docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C
--build=x86_64-pc-cygwin --host=x86_64-pc-cygwin
--target=x86_64-pc-cygwin --without-libiconv-prefix
--without-libintl-prefix --libexecdir=/usr/lib --enable-shared
--enable-shared-libgcc --enable-static
--enable-version-specific-runtime-libs --enable-bootstrap
--enable-__cxa_atexit --with-dwarf2 --with-tune=generic
--enable-languages=c,c++,fortran,lto,objc,obj-c++ --enable-graphite
--enable-threads=posix --enable-libatomic --enable-libgomp
--enable-libquadmath --enable-libquadmath-support --disable-libssp
--enable-libada --disable-symvers --with-gnu-ld --with-gnu-as
--with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix
--without-libintl-prefix --with-system-zlib --enable-linker-build-id
--with-default-libstdcxx-abi=gcc4-compatible
--enable-libstdcxx-filesystem-ts
Thread-Modell: posix
gcc-Version 9.2.0 (GCC)

---

(This is Cygwin64)
gcc was updated yesterday. I even downgraded to 7.3.0-3 with no effect.

Regards,

    Matthias


Am 24.02.20 um 17:40 schrieb Matthias Seidel:

Hi all,

After updating a lot of packages (incl. gcc) in Cygwin64 yesterday I can
no longer build AOO for Windows.

I get errors in bootstrap while building dmake:

make[2]: Verzeichnis
„/cygdrive/c/Source/openoffice/main/solenv/wntmsci12.pro/misc/build/dmake-4.12“

wird betreten
depbase=`echo infer.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`; \
if gcc -DHAVE_CONFIG_H -I. -I. -I. -I. -I. -I./unix/cygwin -I./unix
-I./unix/cygwin/gnu -I./unix/cygwin -I./unix  -g -O2 -MT infer.o -MD
-MP -MF "$depbase.Tpo" -c -o infer.o infer.c; \
then mv -f "$depbase.Tpo" "$depbase.Po"; else rm -f "$depbase.Tpo"; exit
1; fi
In Datei, eingebunden von extern.h:38,
   von infer.c:33:
config.h:188:16: Fehler: doppeltes »unsigned«
    188 | #define size_t unsigned int
    |    ^~~~
config.h:188:25: Fehler: zwei oder mehr Datentypen in Deklaration
    188 | #define size_t unsigned int
    | ^~~
config.h:185:15: Fehler: zwei oder mehr Datentypen in Deklaration
    185 | #define off_t long int
    |   ^~~~
config.h:185:20: Fehler: zwei oder mehr Datentypen in Deklaration
    185 | #define off_t long int
    |    ^~~
In Datei, eingebunden von extern.h:86,
   von infer.c:33:
itypes.h:58:5: Fehler: #error "No 2 byte type, you lose."
     58 | #   error "No 2 byte type, you lose."
    | ^
itypes.h:77:5: Fehler: #error "No 4 byte type, you lose."
     77 | #   error "No 4 byte type, you lose."
    | ^
...


Is there anything we can do to ensure that AOO can be built with an
updated Cygwin?
Would Jim's updated dmake help?

Regards,
     Matthias

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Errors in bootstrap while building dmake

2020-02-25 Thread Matthias Seidel

Hi all,

Just today, there was an update of "binutils" for Cygwin and now the
errors are gone... ;-)

Sorry for the trouble, I am just doing a new build now!

Regards,

   Matthias

Am 24.02.20 um 18:23 schrieb Matthias Seidel:
> Hi,
>
> Am 24.02.20 um 18:18 schrieb Peter Kovacs:
>> can you post what g++ -v prints on bash?
> ---
> $ g++ -v
> Es werden eingebaute Spezifikationen verwendet.
> COLLECT_GCC=g++
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/9.2.0/lto-wrapper.exe
> Ziel: x86_64-pc-cygwin
> Konfiguriert mit:
> /cygdrive/i/szsz/tmpp/gcc/gcc-9.2.0-2.x86_64/src/gcc-9.2.0/configure
> --srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-9.2.0-2.x86_64/src/gcc-9.2.0
> --prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc
> --docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C
> --build=x86_64-pc-cygwin --host=x86_64-pc-cygwin
> --target=x86_64-pc-cygwin --without-libiconv-prefix
> --without-libintl-prefix --libexecdir=/usr/lib --enable-shared
> --enable-shared-libgcc --enable-static
> --enable-version-specific-runtime-libs --enable-bootstrap
> --enable-__cxa_atexit --with-dwarf2 --with-tune=generic
> --enable-languages=c,c++,fortran,lto,objc,obj-c++ --enable-graphite
> --enable-threads=posix --enable-libatomic --enable-libgomp
> --enable-libquadmath --enable-libquadmath-support --disable-libssp
> --enable-libada --disable-symvers --with-gnu-ld --with-gnu-as
> --with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix
> --without-libintl-prefix --with-system-zlib --enable-linker-build-id
> --with-default-libstdcxx-abi=gcc4-compatible
> --enable-libstdcxx-filesystem-ts
> Thread-Modell: posix
> gcc-Version 9.2.0 (GCC)
>
> ---
>
> (This is Cygwin64)
> gcc was updated yesterday. I even downgraded to 7.3.0-3 with no effect.
>
> Regards,
>
>    Matthias
>
>> Am 24.02.20 um 17:40 schrieb Matthias Seidel:
>>> Hi all,
>>>
>>> After updating a lot of packages (incl. gcc) in Cygwin64 yesterday I can
>>> no longer build AOO for Windows.
>>>
>>> I get errors in bootstrap while building dmake:
>>>
>>> make[2]: Verzeichnis
>>> „/cygdrive/c/Source/openoffice/main/solenv/wntmsci12.pro/misc/build/dmake-4.12“
>>>
>>> wird betreten
>>> depbase=`echo infer.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`; \
>>> if gcc -DHAVE_CONFIG_H -I. -I. -I. -I. -I. -I./unix/cygwin -I./unix
>>> -I./unix/cygwin/gnu -I./unix/cygwin -I./unix  -g -O2 -MT infer.o -MD
>>> -MP -MF "$depbase.Tpo" -c -o infer.o infer.c; \
>>> then mv -f "$depbase.Tpo" "$depbase.Po"; else rm -f "$depbase.Tpo"; exit
>>> 1; fi
>>> In Datei, eingebunden von extern.h:38,
>>>   von infer.c:33:
>>> config.h:188:16: Fehler: doppeltes »unsigned«
>>>    188 | #define size_t unsigned int
>>>    |    ^~~~
>>> config.h:188:25: Fehler: zwei oder mehr Datentypen in Deklaration
>>>    188 | #define size_t unsigned int
>>>    | ^~~
>>> config.h:185:15: Fehler: zwei oder mehr Datentypen in Deklaration
>>>    185 | #define off_t long int
>>>    |   ^~~~
>>> config.h:185:20: Fehler: zwei oder mehr Datentypen in Deklaration
>>>    185 | #define off_t long int
>>>    |    ^~~
>>> In Datei, eingebunden von extern.h:86,
>>>   von infer.c:33:
>>> itypes.h:58:5: Fehler: #error "No 2 byte type, you lose."
>>>     58 | #   error "No 2 byte type, you lose."
>>>    | ^
>>> itypes.h:77:5: Fehler: #error "No 4 byte type, you lose."
>>>     77 | #   error "No 4 byte type, you lose."
>>>    | ^
>>> ...
>>>
>>>
>>> Is there anything we can do to ensure that AOO can be built with an
>>> updated Cygwin?
>>> Would Jim's updated dmake help?
>>>
>>> Regards,
>>>     Matthias
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Errors in bootstrap while building dmake

2020-02-24 Thread Matthias Seidel

Hi,

Am 24.02.20 um 18:49 schrieb Peter Kovacs:
> The error suggest a coder error.
>
> But that is strange. So I would try to set following environment
> Variable:
>
> export |CXXFLAGS = $||CXXFLAGS |||-std=gnu98||
>
> ||and then try configure again. Maybe it is something that newer
> definitions are more rigid then the super old we use.||
>
> ||But it is a shot in the blue.

I will try to do that!

But until this is fixed I am out. No builds for 418 or 42X.

> ||
>
> ||
>
>
> Am 24.02.20 um 18:23 schrieb Matthias Seidel:
>> Hi,
>>
>> Am 24.02.20 um 18:18 schrieb Peter Kovacs:
>>> can you post what g++ -v prints on bash?
>> ---
>> $ g++ -v
>> Es werden eingebaute Spezifikationen verwendet.
>> COLLECT_GCC=g++
>> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/9.2.0/lto-wrapper.exe
>> Ziel: x86_64-pc-cygwin
>> Konfiguriert mit:
>> /cygdrive/i/szsz/tmpp/gcc/gcc-9.2.0-2.x86_64/src/gcc-9.2.0/configure
>> --srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-9.2.0-2.x86_64/src/gcc-9.2.0
>> --prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc
>> --docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C
>> --build=x86_64-pc-cygwin --host=x86_64-pc-cygwin
>> --target=x86_64-pc-cygwin --without-libiconv-prefix
>> --without-libintl-prefix --libexecdir=/usr/lib --enable-shared
>> --enable-shared-libgcc --enable-static
>> --enable-version-specific-runtime-libs --enable-bootstrap
>> --enable-__cxa_atexit --with-dwarf2 --with-tune=generic
>> --enable-languages=c,c++,fortran,lto,objc,obj-c++ --enable-graphite
>> --enable-threads=posix --enable-libatomic --enable-libgomp
>> --enable-libquadmath --enable-libquadmath-support --disable-libssp
>> --enable-libada --disable-symvers --with-gnu-ld --with-gnu-as
>> --with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix
>> --without-libintl-prefix --with-system-zlib --enable-linker-build-id
>> --with-default-libstdcxx-abi=gcc4-compatible
>> --enable-libstdcxx-filesystem-ts
>> Thread-Modell: posix
>> gcc-Version 9.2.0 (GCC)
>>
>> ---
>>
>> (This is Cygwin64)
>> gcc was updated yesterday. I even downgraded to 7.3.0-3 with no effect.
>>
>> Regards,
>>
>>     Matthias
>>
>>> Am 24.02.20 um 17:40 schrieb Matthias Seidel:
>>>> Hi all,
>>>>
>>>> After updating a lot of packages (incl. gcc) in Cygwin64 yesterday
>>>> I can
>>>> no longer build AOO for Windows.
>>>>
>>>> I get errors in bootstrap while building dmake:
>>>>
>>>> make[2]: Verzeichnis
>>>> „/cygdrive/c/Source/openoffice/main/solenv/wntmsci12.pro/misc/build/dmake-4.12“
>>>>
>>>>
>>>> wird betreten
>>>> depbase=`echo infer.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`; \
>>>> if gcc -DHAVE_CONFIG_H -I. -I. -I. -I. -I. -I./unix/cygwin -I./unix
>>>> -I./unix/cygwin/gnu -I./unix/cygwin -I./unix  -g -O2 -MT
>>>> infer.o -MD
>>>> -MP -MF "$depbase.Tpo" -c -o infer.o infer.c; \
>>>> then mv -f "$depbase.Tpo" "$depbase.Po"; else rm -f "$depbase.Tpo";
>>>> exit
>>>> 1; fi
>>>> In Datei, eingebunden von extern.h:38,
>>>>    von infer.c:33:
>>>> config.h:188:16: Fehler: doppeltes »unsigned«
>>>>     188 | #define size_t unsigned int
>>>>     |    ^~~~
>>>> config.h:188:25: Fehler: zwei oder mehr Datentypen in Deklaration
>>>>     188 | #define size_t unsigned int
>>>>     | ^~~
>>>> config.h:185:15: Fehler: zwei oder mehr Datentypen in Deklaration
>>>>     185 | #define off_t long int
>>>>     |   ^~~~
>>>> config.h:185:20: Fehler: zwei oder mehr Datentypen in Deklaration
>>>>     185 | #define off_t long int
>>>>     |    ^~~
>>>> In Datei, eingebunden von extern.h:86,
>>>>    von infer.c:33:
>>>> itypes.h:58:5: Fehler: #error "No 2 byte type, you lose."
>>>>  58 | #   error "No 2 byte type, you lose."
>>>>     | ^
>>>> itypes.h:77:5: Fehler: #error "No 4 byte type, you lose."
>>>>  77 | #   error "No 4 byte type, you lose."
>>>>     | ^
>>>> ...
>>>>
>>>>
>>>> Is there anything we can do to ensure that AOO can be built with an
>>>> updated Cygwin?
>>>> Would Jim's updated dmake help?
>>>>
>>>> Regards,
>>>>  Matthias
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>>
>



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Errors in bootstrap while building dmake

2020-02-24 Thread Peter Kovacs


The error suggest a coder error.

But that is strange. So I would try to set following environment Variable:

export |CXXFLAGS = $||CXXFLAGS |||-std=gnu98||

||and then try configure again. Maybe it is something that newer 
definitions are more rigid then the super old we use.||


||But it is a shot in the blue.
||

||


Am 24.02.20 um 18:23 schrieb Matthias Seidel:

Hi,

Am 24.02.20 um 18:18 schrieb Peter Kovacs:

can you post what g++ -v prints on bash?

---
$ g++ -v
Es werden eingebaute Spezifikationen verwendet.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/9.2.0/lto-wrapper.exe
Ziel: x86_64-pc-cygwin
Konfiguriert mit:
/cygdrive/i/szsz/tmpp/gcc/gcc-9.2.0-2.x86_64/src/gcc-9.2.0/configure
--srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-9.2.0-2.x86_64/src/gcc-9.2.0
--prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc
--docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C
--build=x86_64-pc-cygwin --host=x86_64-pc-cygwin
--target=x86_64-pc-cygwin --without-libiconv-prefix
--without-libintl-prefix --libexecdir=/usr/lib --enable-shared
--enable-shared-libgcc --enable-static
--enable-version-specific-runtime-libs --enable-bootstrap
--enable-__cxa_atexit --with-dwarf2 --with-tune=generic
--enable-languages=c,c++,fortran,lto,objc,obj-c++ --enable-graphite
--enable-threads=posix --enable-libatomic --enable-libgomp
--enable-libquadmath --enable-libquadmath-support --disable-libssp
--enable-libada --disable-symvers --with-gnu-ld --with-gnu-as
--with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix
--without-libintl-prefix --with-system-zlib --enable-linker-build-id
--with-default-libstdcxx-abi=gcc4-compatible
--enable-libstdcxx-filesystem-ts
Thread-Modell: posix
gcc-Version 9.2.0 (GCC)

---

(This is Cygwin64)
gcc was updated yesterday. I even downgraded to 7.3.0-3 with no effect.

Regards,

    Matthias


Am 24.02.20 um 17:40 schrieb Matthias Seidel:

Hi all,

After updating a lot of packages (incl. gcc) in Cygwin64 yesterday I can
no longer build AOO for Windows.

I get errors in bootstrap while building dmake:

make[2]: Verzeichnis
„/cygdrive/c/Source/openoffice/main/solenv/wntmsci12.pro/misc/build/dmake-4.12“

wird betreten
depbase=`echo infer.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`; \
if gcc -DHAVE_CONFIG_H -I. -I. -I. -I. -I. -I./unix/cygwin -I./unix
-I./unix/cygwin/gnu -I./unix/cygwin -I./unix  -g -O2 -MT infer.o -MD
-MP -MF "$depbase.Tpo" -c -o infer.o infer.c; \
then mv -f "$depbase.Tpo" "$depbase.Po"; else rm -f "$depbase.Tpo"; exit
1; fi
In Datei, eingebunden von extern.h:38,
   von infer.c:33:
config.h:188:16: Fehler: doppeltes »unsigned«
    188 | #define size_t unsigned int
    |    ^~~~
config.h:188:25: Fehler: zwei oder mehr Datentypen in Deklaration
    188 | #define size_t unsigned int
    | ^~~
config.h:185:15: Fehler: zwei oder mehr Datentypen in Deklaration
    185 | #define off_t long int
    |   ^~~~
config.h:185:20: Fehler: zwei oder mehr Datentypen in Deklaration
    185 | #define off_t long int
    |    ^~~
In Datei, eingebunden von extern.h:86,
   von infer.c:33:
itypes.h:58:5: Fehler: #error "No 2 byte type, you lose."
     58 | #   error "No 2 byte type, you lose."
    | ^
itypes.h:77:5: Fehler: #error "No 4 byte type, you lose."
     77 | #   error "No 4 byte type, you lose."
    | ^
...


Is there anything we can do to ensure that AOO can be built with an
updated Cygwin?
Would Jim's updated dmake help?

Regards,
     Matthias

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Errors in bootstrap while building dmake

2020-02-24 Thread Peter Kovacs


can you post what g++ -v prints on bash?

Am 24.02.20 um 17:40 schrieb Matthias Seidel:

Hi all,

After updating a lot of packages (incl. gcc) in Cygwin64 yesterday I can
no longer build AOO for Windows.

I get errors in bootstrap while building dmake:

make[2]: Verzeichnis
„/cygdrive/c/Source/openoffice/main/solenv/wntmsci12.pro/misc/build/dmake-4.12“
wird betreten
depbase=`echo infer.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`; \
if gcc -DHAVE_CONFIG_H -I. -I. -I. -I. -I. -I./unix/cygwin -I./unix
-I./unix/cygwin/gnu -I./unix/cygwin -I./unix  -g -O2 -MT infer.o -MD
-MP -MF "$depbase.Tpo" -c -o infer.o infer.c; \
then mv -f "$depbase.Tpo" "$depbase.Po"; else rm -f "$depbase.Tpo"; exit
1; fi
In Datei, eingebunden von extern.h:38,
  von infer.c:33:
config.h:188:16: Fehler: doppeltes »unsigned«
   188 | #define size_t unsigned int
   |    ^~~~
config.h:188:25: Fehler: zwei oder mehr Datentypen in Deklaration
   188 | #define size_t unsigned int
   | ^~~
config.h:185:15: Fehler: zwei oder mehr Datentypen in Deklaration
   185 | #define off_t long int
   |   ^~~~
config.h:185:20: Fehler: zwei oder mehr Datentypen in Deklaration
   185 | #define off_t long int
   |    ^~~
In Datei, eingebunden von extern.h:86,
  von infer.c:33:
itypes.h:58:5: Fehler: #error "No 2 byte type, you lose."
    58 | #   error "No 2 byte type, you lose."
   | ^
itypes.h:77:5: Fehler: #error "No 4 byte type, you lose."
    77 | #   error "No 4 byte type, you lose."
   | ^
...


Is there anything we can do to ensure that AOO can be built with an
updated Cygwin?
Would Jim's updated dmake help?

Regards,
    Matthias


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Errors in bootstrap while building dmake

2020-02-24 Thread Matthias Seidel

Hi all,

After updating a lot of packages (incl. gcc) in Cygwin64 yesterday I can
no longer build AOO for Windows.

I get errors in bootstrap while building dmake:

make[2]: Verzeichnis
„/cygdrive/c/Source/openoffice/main/solenv/wntmsci12.pro/misc/build/dmake-4.12“
wird betreten
depbase=`echo infer.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`; \
if gcc -DHAVE_CONFIG_H -I. -I. -I. -I. -I. -I./unix/cygwin -I./unix
-I./unix/cygwin/gnu -I./unix/cygwin -I./unix  -g -O2 -MT infer.o -MD
-MP -MF "$depbase.Tpo" -c -o infer.o infer.c; \
then mv -f "$depbase.Tpo" "$depbase.Po"; else rm -f "$depbase.Tpo"; exit
1; fi
In Datei, eingebunden von extern.h:38,
 von infer.c:33:
config.h:188:16: Fehler: doppeltes »unsigned«
  188 | #define size_t unsigned int
  |    ^~~~
config.h:188:25: Fehler: zwei oder mehr Datentypen in Deklaration
  188 | #define size_t unsigned int
  | ^~~
config.h:185:15: Fehler: zwei oder mehr Datentypen in Deklaration
  185 | #define off_t long int
  |   ^~~~
config.h:185:20: Fehler: zwei oder mehr Datentypen in Deklaration
  185 | #define off_t long int
  |    ^~~
In Datei, eingebunden von extern.h:86,
 von infer.c:33:
itypes.h:58:5: Fehler: #error "No 2 byte type, you lose."
   58 | #   error "No 2 byte type, you lose."
  | ^
itypes.h:77:5: Fehler: #error "No 4 byte type, you lose."
   77 | #   error "No 4 byte type, you lose."
  | ^
...


Is there anything we can do to ensure that AOO can be built with an
updated Cygwin?
Would Jim's updated dmake help?

Regards,
   Matthias


smime.p7s
Description: S/MIME Cryptographic Signature

Re: patch to move $CCNUMVER from dmake to configure

2018-03-08 Thread Damjan Jovanovic

Hi Don

Please commit this patch ASAP.

I think you're waited enough for Mac testers, and it's now holding up other
changes I want to make.

I can even commit it for you.

Thank you
Damjan


On Thu, Jan 18, 2018 at 9:17 AM, Don Lewis <truck...@apache.org> wrote:

> On 16 Jan, Kay Schenk wrote:
> >
> >
> > On 01/11/2018 11:24 PM, Don Lewis wrote:
> >> The patch below moves the calculation of $CCNUMVER and some other
> >> variables from main/solenv/inc/tg_compv.mk, where it is only usable by
> >> dmake, to configure, where it can be used by both dmake and gbuild. This
> >> is a requirement for me upstream some compiler bug workaround patches
> >> from the FreeBSD port.
> >>
> >> A bit of logic from set_soenv is also moved into configure.  A bunch
> >> more should probably be moved so that the configuration logic is not
> >> spread across so many different places, but that can wait.  Something
> >> else to consider is that it would be nice to use a different value of
> >> $COM for Apple's clang, maybe "ACLANG" or "APPLECLANG" since it  has a
> >> different version numbering scheme that the open-source version of clang
> >> and having a unique identifier would simplify version checking when
> >> applying compiler bug workarounds.
> >>
> >> I've tested this patch on Windows, CentOS 6, and FreeBSD.  It really
> >> needs some testing on Mac and OS/2.
> >>
> >> If you have an existing, populated build tree, then the most important
> >> tests can be done without even doing a build.  Start off by copying the
> >> *env.set.sh script and solver/420/*/inc/comp_ver.mk to a safe location.
> >> Next apply the patch below, run autoconf, and then run configure.
> >> Compare the values of $COMNAME, $COMID, $CCNUMVER, and $CCVER from the
> >> new *.env.set.sh with the values of those variables from the saved copy
> >> of comp_ver.mk.  Also compare the values of $COM in the new and saved
> >> versions of *.env.set.sh.
> >>
> >> Note: I think the old value of $CCNUMVER on the Mac is wrong.  It should
> >> look something like 00080001 or 00070003, depending on the
> >> installed version.
> >>
> >> Note that I changed -DCPPU_ENV on the Mac from $(COMID) to $(COMNAME)
> >> for consistency with the dmake side.  It shouldn't make a difference in
> >> practice since both have the same value on the Mac.
> >>
> >> If things look good, then please try a build with this patch.
> >
> > I'm having problems applying these patches. :(
> > Can you add a new issue and attach all this as a text file.
>
> https://bz.apache.org/ooo/show_bug.cgi?id=127664
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: patch to move $CCNUMVER from dmake to configure

2018-01-19 Thread Kay Schenk



On 01/17/2018 11:17 PM, Don Lewis wrote:

On 16 Jan, Kay Schenk wrote:


On 01/11/2018 11:24 PM, Don Lewis wrote:

The patch below moves the calculation of $CCNUMVER and some other
variables from main/solenv/inc/tg_compv.mk, where it is only usable by
dmake, to configure, where it can be used by both dmake and gbuild. This
is a requirement for me upstream some compiler bug workaround patches
from the FreeBSD port.

A bit of logic from set_soenv is also moved into configure.  A bunch
more should probably be moved so that the configuration logic is not
spread across so many different places, but that can wait.  Something
else to consider is that it would be nice to use a different value of
$COM for Apple's clang, maybe "ACLANG" or "APPLECLANG" since it  has a
different version numbering scheme that the open-source version of clang
and having a unique identifier would simplify version checking when
applying compiler bug workarounds.

I've tested this patch on Windows, CentOS 6, and FreeBSD.  It really
needs some testing on Mac and OS/2.

If you have an existing, populated build tree, then the most important
tests can be done without even doing a build.  Start off by copying the
*env.set.sh script and solver/420/*/inc/comp_ver.mk to a safe location.
Next apply the patch below, run autoconf, and then run configure.
Compare the values of $COMNAME, $COMID, $CCNUMVER, and $CCVER from the
new *.env.set.sh with the values of those variables from the saved copy
of comp_ver.mk.  Also compare the values of $COM in the new and saved
versions of *.env.set.sh.

Note: I think the old value of $CCNUMVER on the Mac is wrong.  It should
look something like 00080001 or 00070003, depending on the
installed version.

Note that I changed -DCPPU_ENV on the Mac from $(COMID) to $(COMNAME)
for consistency with the dmake side.  It shouldn't make a difference in
practice since both have the same value on the Mac.

If things look good, then please try a build with this patch.

I'm having problems applying these patches. :(
Can you add a new issue and attach all this as a text file.

https://bz.apache.org/ooo/show_bug.cgi?id=127664


Thanks. Additional comments in issue.


--
--
MzK

"Ring out the false, ring in the true."
 -- poem "In Memoriam", Alfred Lord Tennyson


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: patch to move $CCNUMVER from dmake to configure

2018-01-17 Thread Don Lewis

On 16 Jan, Kay Schenk wrote:
> 
> 
> On 01/11/2018 11:24 PM, Don Lewis wrote:
>> The patch below moves the calculation of $CCNUMVER and some other
>> variables from main/solenv/inc/tg_compv.mk, where it is only usable by
>> dmake, to configure, where it can be used by both dmake and gbuild. This
>> is a requirement for me upstream some compiler bug workaround patches
>> from the FreeBSD port.
>> 
>> A bit of logic from set_soenv is also moved into configure.  A bunch
>> more should probably be moved so that the configuration logic is not
>> spread across so many different places, but that can wait.  Something
>> else to consider is that it would be nice to use a different value of
>> $COM for Apple's clang, maybe "ACLANG" or "APPLECLANG" since it  has a
>> different version numbering scheme that the open-source version of clang
>> and having a unique identifier would simplify version checking when
>> applying compiler bug workarounds.
>> 
>> I've tested this patch on Windows, CentOS 6, and FreeBSD.  It really
>> needs some testing on Mac and OS/2.
>> 
>> If you have an existing, populated build tree, then the most important
>> tests can be done without even doing a build.  Start off by copying the
>> *env.set.sh script and solver/420/*/inc/comp_ver.mk to a safe location.
>> Next apply the patch below, run autoconf, and then run configure.
>> Compare the values of $COMNAME, $COMID, $CCNUMVER, and $CCVER from the
>> new *.env.set.sh with the values of those variables from the saved copy
>> of comp_ver.mk.  Also compare the values of $COM in the new and saved
>> versions of *.env.set.sh.
>> 
>> Note: I think the old value of $CCNUMVER on the Mac is wrong.  It should
>> look something like 00080001 or 00070003, depending on the
>> installed version.
>> 
>> Note that I changed -DCPPU_ENV on the Mac from $(COMID) to $(COMNAME)
>> for consistency with the dmake side.  It shouldn't make a difference in
>> practice since both have the same value on the Mac.
>> 
>> If things look good, then please try a build with this patch.
> 
> I'm having problems applying these patches. :(
> Can you add a new issue and attach all this as a text file.

https://bz.apache.org/ooo/show_bug.cgi?id=127664

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: patch to move $CCNUMVER from dmake to configure

2018-01-16 Thread Kay Schenk




On 01/11/2018 11:24 PM, Don Lewis wrote:

The patch below moves the calculation of $CCNUMVER and some other
variables from main/solenv/inc/tg_compv.mk, where it is only usable by
dmake, to configure, where it can be used by both dmake and gbuild. This
is a requirement for me upstream some compiler bug workaround patches
from the FreeBSD port.

A bit of logic from set_soenv is also moved into configure.  A bunch
more should probably be moved so that the configuration logic is not
spread across so many different places, but that can wait.  Something
else to consider is that it would be nice to use a different value of
$COM for Apple's clang, maybe "ACLANG" or "APPLECLANG" since it  has a
different version numbering scheme that the open-source version of clang
and having a unique identifier would simplify version checking when
applying compiler bug workarounds.

I've tested this patch on Windows, CentOS 6, and FreeBSD.  It really
needs some testing on Mac and OS/2.

If you have an existing, populated build tree, then the most important
tests can be done without even doing a build.  Start off by copying the
*env.set.sh script and solver/420/*/inc/comp_ver.mk to a safe location.
Next apply the patch below, run autoconf, and then run configure.
Compare the values of $COMNAME, $COMID, $CCNUMVER, and $CCVER from the
new *.env.set.sh with the values of those variables from the saved copy
of comp_ver.mk.  Also compare the values of $COM in the new and saved
versions of *.env.set.sh.

Note: I think the old value of $CCNUMVER on the Mac is wrong.  It should
look something like 00080001 or 00070003, depending on the
installed version.

Note that I changed -DCPPU_ENV on the Mac from $(COMID) to $(COMNAME)
for consistency with the dmake side.  It shouldn't make a difference in
practice since both have the same value on the Mac.

If things look good, then please try a build with this patch.


I'm having problems applying these patches. :(
Can you add a new issue and attach all this as a text file.



Index: main/configure.ac
===
--- main/configure.ac   (revision 1820504)
+++ main/configure.ac   (working copy)
@@ -1697,29 +1697,6 @@
 AC_PROG_CC
  fi
  
-dnl Clang detection on supported platforms

-if test "$_os" = "Linux" -o "$_os" = "FreeBSD"; then
-if $CC --version 2>&1 | $GREP clang > /dev/null ; then
-COM_IS=CLANG
-else
-COM_IS=GCC
-fi
-AC_SUBST(COM_IS)
-fi
-
-if test "$_os" = "FreeBSD"; then
-FBSD_GCC_RPATH=
-if "$COM_IS" = "GCC"; then
-rpath=`$CC --print-file-name libstdc++.so`
-rpath=`realpath $rpath`
-rpath=`dirname $rpath`
-   if test "$rpath" != "/usr/lib" ; then
-FBSD_GCC_RPATH="-Wl,-rpath=$rpath"
-   fi
-fi
-AC_SUBST(FBSD_GCC_RPATH)
-fi
-
  COMPATH=`dirname "$CC"`
  if test "$COMPATH" = "." ; then
  AC_PATH_PROGS(COMPATH, $CC)
@@ -2169,6 +2146,101 @@
  AC_SUBST(MSPDB_PATH)
  AC_SUBST(USE_MINGW)
  
+dnl Compiler detection, logic from setsoenv.in

+case "$build_os" in
+   *cygwin*)
+   if test "$WITH_MINGWIN" = "yes"; then
+   COM="GCC";
+   else
+   COM="MSC";
+   fi;;
+   os2*)
+   COM="GCC";;
+   netbsd | kfreebsd* | freebsd* | linux* | darwin* )
+   if $CC --version 2>&1 | $GREP clang > /dev/null ; then
+   COM="CLANG";
+   else
+   COM="GCC";
+   fi;;
+   solaris*)
+   case "$CC" in
+   *gcc*)  COM="GCC";;
+   *)  COM="C52";;
+   esac;;
+   osf | aix*)
+   COM="CXX";;
+   *) AC_MSG_ERROR([Unable to decipher compiler for $build_os]);;
+esac
+AC_SUBST(COM)
+
+dnl  Decode the compiler version.  Logic from main/solenv/inc/tg_compv.mk.
+case $COM in
+   GCC)
+   CCVER=`${CC} -dumpversion 2>&1`;
+   CCNUMVER=`echo ${CCVER} | $AWK -v num=true -f 
${_solenv}/bin/getcompver.awk`;
+   if test "${CCNUMVER}" -ge 00030001; then
+   COMID="gcc3";
+   COMNAME="gcc3";
+   elif test "${CCNUMVER}" -ge 00030001; then
+   COMID="GCC";
+   COMNAME="gcc2";
+   else
+   AC_MSG_ERROR([gcc too old]);
+   fi
+   ;;
+   CLANG)
+   CCVER=`${CC} --version 2>&1 | head -n1 | sed -e"s/.*version //" 
-e"s/ .*//&quo

patch to move $CCNUMVER from dmake to configure

2018-01-11 Thread Don Lewis

The patch below moves the calculation of $CCNUMVER and some other
variables from main/solenv/inc/tg_compv.mk, where it is only usable by
dmake, to configure, where it can be used by both dmake and gbuild. This
is a requirement for me upstream some compiler bug workaround patches
from the FreeBSD port.

A bit of logic from set_soenv is also moved into configure.  A bunch
more should probably be moved so that the configuration logic is not
spread across so many different places, but that can wait.  Something
else to consider is that it would be nice to use a different value of
$COM for Apple's clang, maybe "ACLANG" or "APPLECLANG" since it  has a
different version numbering scheme that the open-source version of clang
and having a unique identifier would simplify version checking when
applying compiler bug workarounds.

I've tested this patch on Windows, CentOS 6, and FreeBSD.  It really
needs some testing on Mac and OS/2.

If you have an existing, populated build tree, then the most important
tests can be done without even doing a build.  Start off by copying the
*env.set.sh script and solver/420/*/inc/comp_ver.mk to a safe location.
Next apply the patch below, run autoconf, and then run configure.
Compare the values of $COMNAME, $COMID, $CCNUMVER, and $CCVER from the
new *.env.set.sh with the values of those variables from the saved copy
of comp_ver.mk.  Also compare the values of $COM in the new and saved
versions of *.env.set.sh.

Note: I think the old value of $CCNUMVER on the Mac is wrong.  It should
look something like 00080001 or 00070003, depending on the
installed version.

Note that I changed -DCPPU_ENV on the Mac from $(COMID) to $(COMNAME)
for consistency with the dmake side.  It shouldn't make a difference in
practice since both have the same value on the Mac.

If things look good, then please try a build with this patch.

Index: main/configure.ac
===
--- main/configure.ac   (revision 1820504)
+++ main/configure.ac   (working copy)
@@ -1697,29 +1697,6 @@
AC_PROG_CC
 fi
 
-dnl Clang detection on supported platforms
-if test "$_os" = "Linux" -o "$_os" = "FreeBSD"; then
-if $CC --version 2>&1 | $GREP clang > /dev/null ; then
-COM_IS=CLANG
-else
-COM_IS=GCC
-fi
-AC_SUBST(COM_IS)
-fi
-
-if test "$_os" = "FreeBSD"; then
-FBSD_GCC_RPATH=
-if "$COM_IS" = "GCC"; then
-rpath=`$CC --print-file-name libstdc++.so`
-rpath=`realpath $rpath`
-rpath=`dirname $rpath`
-   if test "$rpath" != "/usr/lib" ; then
-FBSD_GCC_RPATH="-Wl,-rpath=$rpath"
-   fi
-fi
-AC_SUBST(FBSD_GCC_RPATH)
-fi
-
 COMPATH=`dirname "$CC"`
 if test "$COMPATH" = "." ; then
 AC_PATH_PROGS(COMPATH, $CC)
@@ -2169,6 +2146,101 @@
 AC_SUBST(MSPDB_PATH)
 AC_SUBST(USE_MINGW)
 
+dnl Compiler detection, logic from setsoenv.in
+case "$build_os" in
+   *cygwin*)
+   if test "$WITH_MINGWIN" = "yes"; then
+   COM="GCC";
+   else
+   COM="MSC";
+   fi;;
+   os2*)
+   COM="GCC";;
+   netbsd | kfreebsd* | freebsd* | linux* | darwin* )
+   if $CC --version 2>&1 | $GREP clang > /dev/null ; then
+   COM="CLANG";
+   else
+   COM="GCC";
+   fi;;
+   solaris*)
+   case "$CC" in
+   *gcc*)  COM="GCC";;
+   *)  COM="C52";;
+   esac;;
+   osf | aix*)
+   COM="CXX";;
+   *) AC_MSG_ERROR([Unable to decipher compiler for $build_os]);;
+esac
+AC_SUBST(COM)
+
+dnl  Decode the compiler version.  Logic from main/solenv/inc/tg_compv.mk.
+case $COM in
+   GCC)
+   CCVER=`${CC} -dumpversion 2>&1`;
+   CCNUMVER=`echo ${CCVER} | $AWK -v num=true -f 
${_solenv}/bin/getcompver.awk`;
+   if test "${CCNUMVER}" -ge 00030001; then
+   COMID="gcc3";
+   COMNAME="gcc3";
+   elif test "${CCNUMVER}" -ge 00030001; then
+   COMID="GCC";
+   COMNAME="gcc2";
+   else
+   AC_MSG_ERROR([gcc too old]);
+   fi
+   ;;
+   CLANG)
+   CCVER=`${CC} --version 2>&1 | head -n1 | sed -e"s/.*version //" 
-e"s/ .*//"`;
+   CCNUMVER=`echo ${CCVER} | $AWK -v num=true -f 
${_solenv}/bin/getcompver.awk`;
+   # The version in tg_compv.mk for darwin does not l

Re: [Build] XCodeLegacy - Re: dmake and epm

2017-10-25 Thread Jim Jagielski

With Xcode9, you do need to use Xcodelegacy.

> On Oct 25, 2017, at 11:19 AM, Dave Fisher <dave2w...@comcast.net> wrote:
> 
> Hi Jim,
> 
> Thanks. I have Xcode 9 which has the following:
> 
> $ xcodebuild -showsdks
> iOS SDKs:
>   iOS 11.0-sdk iphoneos11.0
> 
> iOS Simulator SDKs:
>   Simulator - iOS 11.0-sdk iphonesimulator11.0
> 
> macOS SDKs:
>   macOS 10.13 -sdk macosx10.13
> 
> tvOS SDKs:
>   tvOS 11.0   -sdk appletvos11.0
> 
> tvOS Simulator SDKs:
>   Simulator - tvOS 11.0   -sdk appletvsimulator11.0
> 
> watchOS SDKs:
>   watchOS 4.0 -sdk watchos4.0
> 
> watchOS Simulator SDKs:
>   Simulator - watchOS 4.0 -sdk watchsimulator4.0
> 
> I modified configure to target 10.13 and adjusted the egrep:
> 
> sdk_found=`xcodebuild -showsdks | $EGREP "sdk macosx10.(10|11|12|13)" | sed 
> -e "s/.*sdk //" | head -n1`
> 
> Also - 
> #   sdk_target=10.9   
>   
>
>sdk_target=10.13
> 
> The last means the environment variable MACOSX_DEPLOYMENT_TARGET in the 
> release script is not used.
> 
> On to the next issue with the category B downloads. Certificate store issues 
> giving 500 errors.
> 
> Also, I noticed a version 5.5 of Tomcat ….
> 
> Regards,
> Dave
> 
>> On Oct 25, 2017, at 5:32 AM, Jim Jagielski <j...@jagunet.com 
>> <mailto:j...@jagunet.com>> wrote:
>> 
>> Actually, if you have Xcode7 or Xcode8, there is no need for
>> Xcodelegacy at all.
>> 
>> All Xcodelegacy does is obtain older macOS SDKs and installs them
>> in Xcode. But we use the latest SDK available (via configure). So
>> Xcodelegacy is not a requirement/dependency per se. It's just
>> useful in case we get into a situation where we need to
>> use an older SDK rather than the latest.
>> 
>>> On Oct 24, 2017, at 6:00 PM, Dave Fisher <dave2w...@comcast.net 
>>> <mailto:dave2w...@comcast.net>> wrote:
>>> 
>>> Hi Jim,
>>> 
>>> I’m hung up on what I should do with 
>>> https://github.com/devernay/xcodelegacy 
>>> <https://github.com/devernay/xcodelegacy> 
>>> <https://github.com/devernay/xcodelegacy 
>>> <https://github.com/devernay/xcodelegacy>>
>>> 
>>> What should I download before I run the scripts? Which form of the command 
>>> should I use?
>>> 
>>> BTW - this requirement is only mentioned in the build release script.
>>> 
>>> Regards,
>>> Dave
>>> 
>>>> On Oct 23, 2017, at 5:38 PM, Dave Fisher <dave2w...@comcast.net 
>>>> <mailto:dave2w...@comcast.net> <mailto:dave2w...@comcast.net 
>>>> <mailto:dave2w...@comcast.net>>> wrote:
>>>> 
>>>> Hi Jim,
>>>> 
>>>> I wanted to validate build instructions. Should I take these two from your 
>>>> github for my MacOS Sierra environment?
>>>> 
>>>> Regards,
>>>> Dave
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>>> On Oct 20, 2017, at 7:31 AM, Jim Jagielski <j...@jagunet.com 
>>>>> <mailto:j...@jagunet.com> <mailto:j...@jagunet.com 
>>>>> <mailto:j...@jagunet.com>>> wrote:
>>>>> 
>>>>> Just a FYI that I am tracking dmake and epm on the
>>>>> below Github pages:
>>>>> 
>>>>> o https://github.com/jimjag/epm <https://github.com/jimjag/epm> 
>>>>> <https://github.com/jimjag/epm <https://github.com/jimjag/epm>>
>>>>> o https://github.com/jimjag/dmake <https://github.com/jimjag/dmake> 
>>>>> <https://github.com/jimjag/dmake <https://github.com/jimjag/dmake>>
>>>>> 
>>>>> I know we are moving away from dmake, but IMO it'll take
>>>>> some time for that to be complete. Plus, updating to the
>>>>> latest version of EPM is useful (it's the ONLY way to build
>>>>> the macOS versions now, for example), but we also need
>>>>> the AOO-specific patches in there. Which are included
>>>>> in my forks.
>>>>> 
>>>>> Just topic for discussion and chewing over
>>>>> 
>>>>> -
>>>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org 
>>>>> <mailto:dev-unsubscr...@openoffice.apache.org> 
>>>>> <mailto:dev-unsubscr...@openoffice.apache.org 
>>>>> <mailto:dev-unsubscr...@openoffice.apache.org>>
>>>>> For additional commands, e-mail: dev-h...@openoffice.apache.org 
>>>>> <mailto:dev-h...@openoffice.apache.org> 
>>>>> <mailto:dev-h...@openoffice.apache.org 
>>>>> <mailto:dev-h...@openoffice.apache.org>>
>>>>> 
>>>> 
>>>> 
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org 
>>>> <mailto:dev-unsubscr...@openoffice.apache.org> 
>>>> <mailto:dev-unsubscr...@openoffice.apache.org 
>>>> <mailto:dev-unsubscr...@openoffice.apache.org>>
>>>> For additional commands, e-mail: dev-h...@openoffice.apache.org 
>>>> <mailto:dev-h...@openoffice.apache.org> 
>>>> <mailto:dev-h...@openoffice.apache.org 
>>>> <mailto:dev-h...@openoffice.apache.org>>
>>>> 
>>> 
>> 
>

Re: dmake and epm

2017-10-25 Thread Dave Fisher

Hi -

FYI - on https://sourceforge.net/projects/oooextras.mirror/files/ 
<https://sourceforge.net/projects/oooextras.mirror/files/>

The epm version there is 3.7.

It can be configured as:

configure:1952:  --disable-epm   AOO includes self-packaging code, that 
requires
configure:1953:  epm, however epm is useless for large 
scale
configure:2218:  --with-epm   Decides which epm to use. Default is 
to use
configure:2221:   epm will be built.
configure:2223:  --with-epm-url=Specify the location of downloadable 
epm source code. For example:
configure:2224:
https://sourceforge.net/projects/oooextras.mirror/files/epm-3.7.tar.gz
configure:2226:
http://epm.sourcearchive.com/downloads/3.7-1/epm_3.7.orig.tar.gz
configure:2227:  Version 3.7 or later is required. Note 
that epm is under GPL license.

Any reason to make changes in configure, or should we warn?

Regards,
Dave

> On Oct 25, 2017, at 5:34 AM, Jim Jagielski <j...@jagunet.com> wrote:
> 
> You can. I used the downloads mentioned in the macOS build script
> for AOO414.
> 
> The version of dmake isn't important. The version of epm *is*
> (it must be 4.3 or later) because it allows for direct building
> of dmg's w/o requiring a long deprecated support application
> which is no longer available.
> 
>> On Oct 23, 2017, at 8:38 PM, Dave Fisher <dave2w...@comcast.net> wrote:
>> 
>> Hi Jim,
>> 
>> I wanted to validate build instructions. Should I take these two from your 
>> github for my MacOS Sierra environment?
>> 
>> Regards,
>> Dave
>> 
>> Sent from my iPhone
>> 
>>> On Oct 20, 2017, at 7:31 AM, Jim Jagielski <j...@jagunet.com> wrote:
>>> 
>>> Just a FYI that I am tracking dmake and epm on the
>>> below Github pages:
>>> 
>>> o https://github.com/jimjag/epm
>>> o https://github.com/jimjag/dmake
>>> 
>>> I know we are moving away from dmake, but IMO it'll take
>>> some time for that to be complete. Plus, updating to the
>>> latest version of EPM is useful (it's the ONLY way to build
>>> the macOS versions now, for example), but we also need
>>> the AOO-specific patches in there. Which are included
>>> in my forks.
>>> 
>>> Just topic for discussion and chewing over
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 



signature.asc
Description: Message signed with OpenPGP

Re: [Build] XCodeLegacy - Re: dmake and epm

2017-10-25 Thread Dave Fisher

Hi Jim,

Thanks. I have Xcode 9 which has the following:

$ xcodebuild -showsdks
iOS SDKs:
iOS 11.0-sdk iphoneos11.0

iOS Simulator SDKs:
Simulator - iOS 11.0-sdk iphonesimulator11.0

macOS SDKs:
macOS 10.13 -sdk macosx10.13

tvOS SDKs:
tvOS 11.0   -sdk appletvos11.0

tvOS Simulator SDKs:
Simulator - tvOS 11.0   -sdk appletvsimulator11.0

watchOS SDKs:
watchOS 4.0 -sdk watchos4.0

watchOS Simulator SDKs:
Simulator - watchOS 4.0 -sdk watchsimulator4.0

I modified configure to target 10.13 and adjusted the egrep:

sdk_found=`xcodebuild -showsdks | $EGREP "sdk macosx10.(10|11|12|13)" | sed -e 
"s/.*sdk //" | head -n1`

Also -
#   sdk_target=10.9
   sdk_target=10.13

The last means the environment variable MACOSX_DEPLOYMENT_TARGET in the release 
script is not used.

On to the next issue with the category B downloads. Certificate store issues 
giving 500 errors.

Also, I noticed a version 5.5 of Tomcat ….

Regards,
Dave

> On Oct 25, 2017, at 5:32 AM, Jim Jagielski <j...@jagunet.com> wrote:
> 
> Actually, if you have Xcode7 or Xcode8, there is no need for
> Xcodelegacy at all.
> 
> All Xcodelegacy does is obtain older macOS SDKs and installs them
> in Xcode. But we use the latest SDK available (via configure). So
> Xcodelegacy is not a requirement/dependency per se. It's just
> useful in case we get into a situation where we need to
> use an older SDK rather than the latest.
> 
>> On Oct 24, 2017, at 6:00 PM, Dave Fisher <dave2w...@comcast.net> wrote:
>> 
>> Hi Jim,
>> 
>> I’m hung up on what I should do with https://github.com/devernay/xcodelegacy 
>> <https://github.com/devernay/xcodelegacy>
>> 
>> What should I download before I run the scripts? Which form of the command 
>> should I use?
>> 
>> BTW - this requirement is only mentioned in the build release script.
>> 
>> Regards,
>> Dave
>> 
>>> On Oct 23, 2017, at 5:38 PM, Dave Fisher <dave2w...@comcast.net 
>>> <mailto:dave2w...@comcast.net>> wrote:
>>> 
>>> Hi Jim,
>>> 
>>> I wanted to validate build instructions. Should I take these two from your 
>>> github for my MacOS Sierra environment?
>>> 
>>> Regards,
>>> Dave
>>> 
>>> Sent from my iPhone
>>> 
>>>> On Oct 20, 2017, at 7:31 AM, Jim Jagielski <j...@jagunet.com 
>>>> <mailto:j...@jagunet.com>> wrote:
>>>> 
>>>> Just a FYI that I am tracking dmake and epm on the
>>>> below Github pages:
>>>> 
>>>> o https://github.com/jimjag/epm <https://github.com/jimjag/epm>
>>>> o https://github.com/jimjag/dmake <https://github.com/jimjag/dmake>
>>>> 
>>>> I know we are moving away from dmake, but IMO it'll take
>>>> some time for that to be complete. Plus, updating to the
>>>> latest version of EPM is useful (it's the ONLY way to build
>>>> the macOS versions now, for example), but we also need
>>>> the AOO-specific patches in there. Which are included
>>>> in my forks.
>>>> 
>>>> Just topic for discussion and chewing over
>>>> 
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org 
>>>> <mailto:dev-unsubscr...@openoffice.apache.org>
>>>> For additional commands, e-mail: dev-h...@openoffice.apache.org 
>>>> <mailto:dev-h...@openoffice.apache.org>
>>>> 
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org 
>>> <mailto:dev-unsubscr...@openoffice.apache.org>
>>> For additional commands, e-mail: dev-h...@openoffice.apache.org 
>>> <mailto:dev-h...@openoffice.apache.org>
>>> 
>> 
> 



signature.asc
Description: Message signed with OpenPGP

Re: dmake and epm

2017-10-25 Thread Jim Jagielski

You can. I used the downloads mentioned in the macOS build script
for AOO414.

The version of dmake isn't important. The version of epm *is*
(it must be 4.3 or later) because it allows for direct building
of dmg's w/o requiring a long deprecated support application
which is no longer available.

> On Oct 23, 2017, at 8:38 PM, Dave Fisher <dave2w...@comcast.net> wrote:
> 
> Hi Jim,
> 
> I wanted to validate build instructions. Should I take these two from your 
> github for my MacOS Sierra environment?
> 
> Regards,
> Dave
> 
> Sent from my iPhone
> 
>> On Oct 20, 2017, at 7:31 AM, Jim Jagielski <j...@jagunet.com> wrote:
>> 
>> Just a FYI that I am tracking dmake and epm on the
>> below Github pages:
>> 
>>  o https://github.com/jimjag/epm
>>  o https://github.com/jimjag/dmake
>> 
>> I know we are moving away from dmake, but IMO it'll take
>> some time for that to be complete. Plus, updating to the
>> latest version of EPM is useful (it's the ONLY way to build
>> the macOS versions now, for example), but we also need
>> the AOO-specific patches in there. Which are included
>> in my forks.
>> 
>> Just topic for discussion and chewing over
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [Build] XCodeLegacy - Re: dmake and epm

2017-10-25 Thread Jim Jagielski

Actually, if you have Xcode7 or Xcode8, there is no need for
Xcodelegacy at all.

All Xcodelegacy does is obtain older macOS SDKs and installs them
in Xcode. But we use the latest SDK available (via configure). So
Xcodelegacy is not a requirement/dependency per se. It's just
useful in case we get into a situation where we need to
use an older SDK rather than the latest.

> On Oct 24, 2017, at 6:00 PM, Dave Fisher <dave2w...@comcast.net> wrote:
> 
> Hi Jim,
> 
> I’m hung up on what I should do with https://github.com/devernay/xcodelegacy 
> <https://github.com/devernay/xcodelegacy>
> 
> What should I download before I run the scripts? Which form of the command 
> should I use?
> 
> BTW - this requirement is only mentioned in the build release script.
> 
> Regards,
> Dave
> 
>> On Oct 23, 2017, at 5:38 PM, Dave Fisher <dave2w...@comcast.net 
>> <mailto:dave2w...@comcast.net>> wrote:
>> 
>> Hi Jim,
>> 
>> I wanted to validate build instructions. Should I take these two from your 
>> github for my MacOS Sierra environment?
>> 
>> Regards,
>> Dave
>> 
>> Sent from my iPhone
>> 
>>> On Oct 20, 2017, at 7:31 AM, Jim Jagielski <j...@jagunet.com 
>>> <mailto:j...@jagunet.com>> wrote:
>>> 
>>> Just a FYI that I am tracking dmake and epm on the
>>> below Github pages:
>>> 
>>>  o https://github.com/jimjag/epm <https://github.com/jimjag/epm>
>>>  o https://github.com/jimjag/dmake <https://github.com/jimjag/dmake>
>>> 
>>> I know we are moving away from dmake, but IMO it'll take
>>> some time for that to be complete. Plus, updating to the
>>> latest version of EPM is useful (it's the ONLY way to build
>>> the macOS versions now, for example), but we also need
>>> the AOO-specific patches in there. Which are included
>>> in my forks.
>>> 
>>> Just topic for discussion and chewing over
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org 
>>> <mailto:dev-unsubscr...@openoffice.apache.org>
>>> For additional commands, e-mail: dev-h...@openoffice.apache.org 
>>> <mailto:dev-h...@openoffice.apache.org>
>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org 
>> <mailto:dev-unsubscr...@openoffice.apache.org>
>> For additional commands, e-mail: dev-h...@openoffice.apache.org 
>> <mailto:dev-h...@openoffice.apache.org>
>> 
>

[Build] XCodeLegacy - Re: dmake and epm

2017-10-24 Thread Dave Fisher

Hi Jim,

I’m hung up on what I should do with https://github.com/devernay/xcodelegacy 
<https://github.com/devernay/xcodelegacy>

What should I download before I run the scripts? Which form of the command 
should I use?

BTW - this requirement is only mentioned in the build release script.

Regards,
Dave

> On Oct 23, 2017, at 5:38 PM, Dave Fisher <dave2w...@comcast.net> wrote:
> 
> Hi Jim,
> 
> I wanted to validate build instructions. Should I take these two from your 
> github for my MacOS Sierra environment?
> 
> Regards,
> Dave
> 
> Sent from my iPhone
> 
>> On Oct 20, 2017, at 7:31 AM, Jim Jagielski <j...@jagunet.com> wrote:
>> 
>> Just a FYI that I am tracking dmake and epm on the
>> below Github pages:
>> 
>>  o https://github.com/jimjag/epm
>>  o https://github.com/jimjag/dmake
>> 
>> I know we are moving away from dmake, but IMO it'll take
>> some time for that to be complete. Plus, updating to the
>> latest version of EPM is useful (it's the ONLY way to build
>> the macOS versions now, for example), but we also need
>> the AOO-specific patches in there. Which are included
>> in my forks.
>> 
>> Just topic for discussion and chewing over
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 



signature.asc
Description: Message signed with OpenPGP

Re: dmake and epm

2017-10-23 Thread Dave Fisher

Hi Jim,

I wanted to validate build instructions. Should I take these two from your 
github for my MacOS Sierra environment?

Regards,
Dave

Sent from my iPhone

> On Oct 20, 2017, at 7:31 AM, Jim Jagielski <j...@jagunet.com> wrote:
> 
> Just a FYI that I am tracking dmake and epm on the
> below Github pages:
> 
>   o https://github.com/jimjag/epm
>   o https://github.com/jimjag/dmake
> 
> I know we are moving away from dmake, but IMO it'll take
> some time for that to be complete. Plus, updating to the
> latest version of EPM is useful (it's the ONLY way to build
> the macOS versions now, for example), but we also need
> the AOO-specific patches in there. Which are included
> in my forks.
> 
> Just topic for discussion and chewing over
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

dmake and epm

2017-10-20 Thread Jim Jagielski

Just a FYI that I am tracking dmake and epm on the
below Github pages:

   o https://github.com/jimjag/epm
   o https://github.com/jimjag/dmake

I know we are moving away from dmake, but IMO it'll take
some time for that to be complete. Plus, updating to the
latest version of EPM is useful (it's the ONLY way to build
the macOS versions now, for example), but we also need
the AOO-specific patches in there. Which are included
in my forks.

Just topic for discussion and chewing over

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Difficulty with dmake

2017-01-25 Thread Damjan Jovanovic

I am not sure. My changes definitely didn't affect that.

I think it might have always been the case, that "source ..." is necessary
before ./bootstrap.

On Thu, Jan 26, 2017 at 6:39 AM, Patricia Shanahan <p...@acm.org> wrote:

> Thanks. That worked.
>
> The step-by-step puts winenv.set.sh after ./bootstrap, and that used to
> work. Do you expect it to work again, or do we need to edit the
> instructions?
>
>
> On 1/25/2017 8:25 PM, Damjan Jovanovic wrote:
>
>> Try "source winenv.set.sh" between ./configure and ./bootstrap.
>>
>> Damjan
>>
>> On Thu, Jan 26, 2017 at 2:20 AM, Patricia Shanahan <p...@acm.org> wrote:
>>
>> I am trying to set up a new debug environment, incorporating the recent
>>> changes to how debug works. Unfortunately, my configure-and-bootstrap
>>> cannot find dmake. It looks for it in a different URL from the one
>>> specified as DMAKE_URL from configure.
>>>
>>> run_configure.sh contains my configure parameters. wk_log.txt is the
>>> output from an attempt to configure and bootstrap.
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>>
>>>
>>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: Difficulty with dmake

2017-01-25 Thread Patricia Shanahan


Thanks. That worked.

The step-by-step puts winenv.set.sh after ./bootstrap, and that used to 
work. Do you expect it to work again, or do we need to edit the 
instructions?


On 1/25/2017 8:25 PM, Damjan Jovanovic wrote:

Try "source winenv.set.sh" between ./configure and ./bootstrap.

Damjan

On Thu, Jan 26, 2017 at 2:20 AM, Patricia Shanahan <p...@acm.org> wrote:


I am trying to set up a new debug environment, incorporating the recent
changes to how debug works. Unfortunately, my configure-and-bootstrap
cannot find dmake. It looks for it in a different URL from the one
specified as DMAKE_URL from configure.

run_configure.sh contains my configure parameters. wk_log.txt is the
output from an attempt to configure and bootstrap.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Difficulty with dmake

2017-01-25 Thread Damjan Jovanovic

Try "source winenv.set.sh" between ./configure and ./bootstrap.

Damjan

On Thu, Jan 26, 2017 at 2:20 AM, Patricia Shanahan <p...@acm.org> wrote:

> I am trying to set up a new debug environment, incorporating the recent
> changes to how debug works. Unfortunately, my configure-and-bootstrap
> cannot find dmake. It looks for it in a different URL from the one
> specified as DMAKE_URL from configure.
>
> run_configure.sh contains my configure parameters. wk_log.txt is the
> output from an attempt to configure and bootstrap.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>

I am trying to set up a new debug environment, incorporating the recent
changes to how debug works. Unfortunately, my configure-and-bootstrap
cannot find dmake. It looks for it in a different URL from the one
specified as DMAKE_URL from configure.

run_configure.sh contains my configure parameters. wk_log.txt is the
output from an attempt to configure and bootstrap.
SDK_PATH="/cygdrive/c/Program Files/Microsoft SDKs/Windows/v7.0"
./configure \
--enable-dbgutil \
--enable-symbols \
--disable-strip-solver \
--with-frame-home="$SDK_PATH" \
--with-psdk-home="$SDK_PATH" \
--with-midl-path="$SDK_PATH/bin" \
--disable-directx \
--with-ant-home="/cygdrive/c/ant" \

--with-dmake-url="https://sourceforge.net/projects/oooextras.mirror/files/dmake-4.12.tar.bz2;
\

--with-epm-url="https://sourceforge.net/projects/oooextras.mirror/files/epm-3.7.tar.gz;
\
--disable-pch \
--disable-atl \
--disable-activex \
--without-junit \
--with-package-format="archive installed" \
--with-jdk-home="/cygdrive/c/Program Files (x86)/Java/jdk1.7.0_79"

Patricia@Jan2014Desktop /cygdrive/c/OpenOfficeDev/new_debug/main
$ source run_configure.sh
checking whether configure is up-to-date... yes

* *
* Apache OpenOffice build configuration. *
* *
* The configure process checks your platform to see whether *
* you can build Apache OpenOffice on it. *
* This process checks all pre-requisites and generates a file*
* containing the necessary environment variables.*
* Source this file after configure has ended successfully. *
* *
* Warnings that are generated during the configure process *
* must be taken into account since it can be a reason for*
* an unsuccessful build of Apache OpenOffice.*
* *

* *
* Checking the platform pre-requisites. *
* *

checking for grep that handles long lines and -e... C:/cygwin32/bin/grep.exe
checking for egrep... C:/cygwin32/bin/grep.exe -E
checking for gawk... gawk
checking for gawk... /usr/bin/gawk
checking for sed... /usr/bin/sed
checking for solenv environment... default
checking for custom pack.lst... no
checking build system type... i686-pc-cygwin
checking host system type... i686-pc-cygwin
checking target system type... i686-pc-cygwin
cygwin
checking Cygwin version... 2.4.1(0.293/5/3)
head: cannot open '/etc/*-release' for reading: No such file or directory
CYGWIN_NT-6.3-WOW Jan2014Desktop 2.4.1(0.293/5/3) 2016-01-24 11:24 i686 Cygwin
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking whether to enable crashdump feature... no
checking whether to use the standard non-optimizing compiler... no
checking whether to build/use the Windows 64bit shell extensions... no
checking whether to turn warnings to errors... no
checking whether to do a debug build... no
checking whether to build with additional debug utilities... yes
checking whether to include symbols into final build... yes
checking whether to strip the solver or not no
checking whether to enable category B components... no: disabled modules nss,
hunspell, hyphen, saxon, rhino, graphite, coinmp
checking whether to enable the Online Update support... yes
checking whether to enable unit tests... yes
checking whether to enable native CUPS support... no
checking whether to enable fontconfig support... no
checking whether to use DirectX... no
checking whether to use ActiveX... no
checking whether to use ATL... no
checking whether to use RPATH in shared libraries... yes
checking whether to use dicts from external paths... no
checking Windows build environment sanity... ok
checking for cygwin gcc/g++... found
checking for bash... /usr/bin/bash
checking gcc home... /usr
checking whether to enable pch feature... no
checking for GNU make... make
checking the GNU make version... make 4.1
3+:
checking for dmake... configure: no system or user-provided dmake found
dmake will be downloaded and compiled in bootstrap
checking for GNU or compatible BSD tar... tar
checking for perl... C:/cygwin32/bin/perl
checking the Perl version... c

Re: Building 4.1.3: Error with dmake and further packages

2016-09-18 Thread Marcus


Am 09/18/2016 12:30 AM, schrieb Ariel Constenla-Haile:

On Sat, Sep 17, 2016 at 10:57:10PM +0200, Marcus wrote:

it breaks again at the same place:

...

[ info  ALL ] LinkTarget Library/libxcr.so not defined: Assuming headers to
be there!
R=/share/linux2/AOO413&&  S=$R/main&&  O=$S/solver/413/unxlngx6.pro&&
W=$O/workdir&&  mkdir -p $W/ExternalHeaders/Library/&&  touch
$W/ExternalHeaders/Library/libxcr.so&&  mkdir -p $W/LinkTarget/pdb/Library/
R=/share/linux2/AOO413&&  S=$R/main&&  O=$S/solver/413/unxlngx6.pro&&
W=$O/workdir&&  mkdir -p $W/Headers/Library/&&  touch
$W/Headers/Library/libxcr.so
R=/share/linux2/AOO413&&  S=$R/main&&  O=$S/solver/413/unxlngx6.pro&&
W=$O/workdir&&  mkdir -p $W/ExternalHeaders/Library/&&  touch
$W/ExternalHeaders/Library/libsvx.so&&  mkdir -p $W/LinkTarget/pdb/Library/
R=/share/linux2/AOO413&&  S=$R/main&&  O=$S/solver/413/unxlngx6.pro&&
W=$O/workdir&&  mkdir -p $W/Headers/Library/&&  touch
$W/Headers/Library/libsvx.so
[ build DEP ] LNK:Library/libsvx.so
R=/share/linux2/AOO413&&  S=$R/main&&  O=$S/solver/413/unxlngx6.pro&&
W=$O/workdir&&  mkdir -p $W/Dep/LinkTarget/Library/&&
RESPONSEFILE=/tmp/gbuild.ViuwkU&&  cat ${RESPONSEFILE} /dev/null | xargs -n
200 cat>  $W/Dep/LinkTarget/Library/libsvx.so.d&&  rm -f ${RESPONSEFILE}
/share/linux2/AOO413/main/solenv/gbuild/LinkTarget.mk:163: *** Unable to
find generated C++ file 
/share/linux2/AOO413/main/solver/413/unxlngx6.pro/workdir/svx/source/sdr/attribute/sdrallfillattributeshelper.cxx


main/svx/source/sdr/attribute/sdrallfillattributeshelper.cxx
main/svx/inc/svx/sdr/attribute/sdrallfillattributeshelper.hxx

where introduced in revision 1599233 and are only part of trunk, not
branch AOO41*. How did you get the AOO413 source?


just a simple:

svn co https://svn.apache.org/repos/asf/openoffice/branches/AOO413/

But I've found the problem:
It's the same "newer GCC compiler cannot optimize certain files" in my 
previous AOO420 build and it seems I've patched the makefile not perfect 
enough. :-(


Thanks for the hint about the files. That showed me the right direction.

And finally I got my install files.

Sorry for the confusion.

Marcus

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Building 4.1.3: Error with dmake and further packages

2016-09-17 Thread Ariel Constenla-Haile

On Sat, Sep 17, 2016 at 10:57:10PM +0200, Marcus wrote:
> it breaks again at the same place:
> 
> ...
> 
> [ info  ALL ] LinkTarget Library/libxcr.so not defined: Assuming headers to
> be there!
> R=/share/linux2/AOO413 && S=$R/main && O=$S/solver/413/unxlngx6.pro &&
> W=$O/workdir && mkdir -p $W/ExternalHeaders/Library/ && touch
> $W/ExternalHeaders/Library/libxcr.so && mkdir -p $W/LinkTarget/pdb/Library/
> R=/share/linux2/AOO413 && S=$R/main && O=$S/solver/413/unxlngx6.pro &&
> W=$O/workdir && mkdir -p $W/Headers/Library/ && touch
> $W/Headers/Library/libxcr.so
> R=/share/linux2/AOO413 && S=$R/main && O=$S/solver/413/unxlngx6.pro &&
> W=$O/workdir && mkdir -p $W/ExternalHeaders/Library/ && touch
> $W/ExternalHeaders/Library/libsvx.so && mkdir -p $W/LinkTarget/pdb/Library/
> R=/share/linux2/AOO413 && S=$R/main && O=$S/solver/413/unxlngx6.pro &&
> W=$O/workdir && mkdir -p $W/Headers/Library/ && touch
> $W/Headers/Library/libsvx.so
> [ build DEP ] LNK:Library/libsvx.so
> R=/share/linux2/AOO413 && S=$R/main && O=$S/solver/413/unxlngx6.pro &&
> W=$O/workdir && mkdir -p $W/Dep/LinkTarget/Library/ &&
> RESPONSEFILE=/tmp/gbuild.ViuwkU && cat ${RESPONSEFILE} /dev/null | xargs -n
> 200 cat > $W/Dep/LinkTarget/Library/libsvx.so.d && rm -f ${RESPONSEFILE}
> /share/linux2/AOO413/main/solenv/gbuild/LinkTarget.mk:163: *** Unable to
> find generated C++ file 
> /share/linux2/AOO413/main/solver/413/unxlngx6.pro/workdir/svx/source/sdr/attribute/sdrallfillattributeshelper.cxx

main/svx/source/sdr/attribute/sdrallfillattributeshelper.cxx
main/svx/inc/svx/sdr/attribute/sdrallfillattributeshelper.hxx

where introduced in revision 1599233 and are only part of trunk, not
branch AOO41*. How did you get the AOO413 source? 


Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina


signature.asc
Description: Digital signature

Re: Building 4.1.3: Error with dmake and further packages


Am 09/17/2016 10:29 PM, schrieb Marcus:

Am 09/17/2016 08:55 PM, schrieb Ariel Constenla-Haile:


On Sat, Sep 17, 2016 at 12:51:08PM +0200, Marcus wrote:

Hi all,

I want to build the current 4.1.3 source.

Therefore I've checked out today the new AOO413 branch (incl. Ariels
last
commit r1761157 !).

Configure was successful but bootstrap throws an error:



download from
http://sourceforge.net/projects/oooextras.mirror/files/dmake-4.12.tar.bz2

failed
download failed
making and entering
/share/linux2/AOO413/main/solenv/unxlngx6.pro/misc/build/
can not find the dmake package



It doesn't matter if it's a HTTP or HTTPS URL.


It matters, sourceforge is redirecting all HTTP to HTTPS.


I can workaround this by using the dmake binary built in trunk with the
"--with-dmake-path" option. Then I can build until errors in these
modules:

more_fonts (which are the dejavu fonts), libxml2, expat, curl

Looking at the errors it seems that the 4 package files cannot be
build as
they were not downloaded.

I think the downloading of external libraries/dependencis isn't
working like
for trunk. Any reason for the difference?


There have been some changes in the code that hasn't been cherrypicked,
I'd try to merge those changes and test.


Needless to say that with trunk I don't have this problem. ;-)

Any hint for root cause and solution?


You might be missing some perl modules that enable HTTPS, the configure
on branch AOO413 does not fail if those are not installed. Check if you
have the following modules:

perl-Archive-Zip
perl-XML-Parser
perl-Digest-SHA
perl-Digest-MD5
perl-Crypt-SSLeay
perl-libwww-perl
perl-LWP-Protocol-https


Right, these are not installed.


Do not install modules using CPAN, use the packagemanager, yum or dnf on
newer Fedora. For example:

dnf info perl-Crypt-SSLeay
yum info perl-Crypt-SSLeay


Done


If the packages do not exist with this names, use the perl module path
to find out which package provides it:

dnf whatprovides */Crypt/SSLeay.pm
yum whatprovides */Crypt/SSLeay.pm

I opened two tasks:
https://bz.apache.org/ooo/show_bug.cgi?id=127119
https://bz.apache.org/ooo/show_bug.cgi?id=127120


That would be great if it could be committed to the AOO413 branch.

Thanks a lot for your help. I now can build much further until svx. Here
a precompiled CXX file is not found. I'll cleanup everything and start
the build again.


it breaks again at the same place:

...

[ info  ALL ] LinkTarget Library/libxcr.so not defined: Assuming headers 
to be there!
R=/share/linux2/AOO413 && S=$R/main && O=$S/solver/413/unxlngx6.pro && 
W=$O/workdir && mkdir -p $W/ExternalHeaders/Library/ && touch 
$W/ExternalHeaders/Library/libxcr.so && mkdir -p $W/LinkTarget/pdb/Library/
R=/share/linux2/AOO413 && S=$R/main && O=$S/solver/413/unxlngx6.pro && 
W=$O/workdir && mkdir -p $W/Headers/Library/ && touch 
$W/Headers/Library/libxcr.so
R=/share/linux2/AOO413 && S=$R/main && O=$S/solver/413/unxlngx6.pro && 
W=$O/workdir && mkdir -p $W/ExternalHeaders/Library/ && touch 
$W/ExternalHeaders/Library/libsvx.so && mkdir -p $W/LinkTarget/pdb/Library/
R=/share/linux2/AOO413 && S=$R/main && O=$S/solver/413/unxlngx6.pro && 
W=$O/workdir && mkdir -p $W/Headers/Library/ && touch 
$W/Headers/Library/libsvx.so

[ build DEP ] LNK:Library/libsvx.so
R=/share/linux2/AOO413 && S=$R/main && O=$S/solver/413/unxlngx6.pro && 
W=$O/workdir && mkdir -p $W/Dep/LinkTarget/Library/ && 
RESPONSEFILE=/tmp/gbuild.ViuwkU && cat ${RESPONSEFILE} /dev/null | xargs 
-n 200 cat > $W/Dep/LinkTarget/Library/libsvx.so.d && rm -f ${RESPONSEFILE}
/share/linux2/AOO413/main/solenv/gbuild/LinkTarget.mk:163: *** Unable to 
find generated C++ file 
/share/linux2/AOO413/main/solver/413/unxlngx6.pro/workdir/svx/source/sdr/attribute/sdrallfillattributeshelper.cxx 
in WORKDIR..  Stop.
rm 
/share/linux2/AOO413/main/solver/413/unxlngx6.pro/workdir/ExternalHeaders/Library/libxcr.so

dmake:  Error code 2, while making 'all'

1 module(s):
svx
need(s) to be rebuilt

Reason(s):

ERROR: error 65280 occurred while making /share/linux2/AOO413/main/svx/prj

When you have fixed the errors in that module you can resume the build 
by running:


build --from svx



The file is indeed not existing:

/share/linux2/AOO413/main/solver/413/unxlngx6.pro/workdir/svx/source/sdr/attribute/sdrallfillattributeshelper.cxx

But also not this part of the mentioned path:

svx/source/sdr/attribute/sdrallfillattributeshelper.cxx

Marcus

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Building 4.1.3: Error with dmake and further packages


Am 09/17/2016 08:55 PM, schrieb Ariel Constenla-Haile:


On Sat, Sep 17, 2016 at 12:51:08PM +0200, Marcus wrote:

Hi all,

I want to build the current 4.1.3 source.

Therefore I've checked out today the new AOO413 branch (incl. Ariels last
commit r1761157 !).

Configure was successful but bootstrap throws an error:



download from
http://sourceforge.net/projects/oooextras.mirror/files/dmake-4.12.tar.bz2
failed
 download failed
making and entering
/share/linux2/AOO413/main/solenv/unxlngx6.pro/misc/build/
can not find the dmake package



It doesn't matter if it's a HTTP or HTTPS URL.


It matters, sourceforge is redirecting all HTTP to HTTPS.


I can workaround this by using the dmake binary built in trunk with the
"--with-dmake-path" option. Then I can build until errors in these modules:

more_fonts (which are the dejavu fonts), libxml2, expat, curl

Looking at the errors it seems that the 4 package files cannot be build as
they were not downloaded.

I think the downloading of external libraries/dependencis isn't working like
for trunk. Any reason for the difference?


There have been some changes in the code that hasn't been cherrypicked,
I'd try to merge those changes and test.


Needless to say that with trunk I don't have this problem. ;-)

Any hint for root cause and solution?


You might be missing some perl modules that enable HTTPS, the configure
on branch AOO413 does not fail if those are not installed. Check if you
have the following modules:

perl-Archive-Zip
perl-XML-Parser
perl-Digest-SHA
perl-Digest-MD5
perl-Crypt-SSLeay
perl-libwww-perl
perl-LWP-Protocol-https


Right, these are not installed.


Do not install modules using CPAN, use the packagemanager, yum or dnf on
newer Fedora. For example:

dnf info perl-Crypt-SSLeay
yum info perl-Crypt-SSLeay


Done


If the packages do not exist with this names, use the perl module path
to find out which package provides it:

dnf whatprovides */Crypt/SSLeay.pm
yum whatprovides */Crypt/SSLeay.pm

I opened two tasks:
https://bz.apache.org/ooo/show_bug.cgi?id=127119
https://bz.apache.org/ooo/show_bug.cgi?id=127120


That would be great if it could be committed to the AOO413 branch.

Thanks a lot for your help. I now can build much further until svx. Here 
a precompiled CXX file is not found. I'll cleanup everything and start 
the build again.


Marcus

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Building 4.1.3: Error with dmake and further packages

2016-09-17 Thread Ariel Constenla-Haile

Hi Marcus,

On Sat, Sep 17, 2016 at 12:51:08PM +0200, Marcus wrote:
> Hi all,
> 
> I want to build the current 4.1.3 source.
> 
> Therefore I've checked out today the new AOO413 branch (incl. Ariels last
> commit r1761157 !).
> 
> Configure was successful but bootstrap throws an error:
> 
> 
> 
> download from
> http://sourceforge.net/projects/oooextras.mirror/files/dmake-4.12.tar.bz2
> failed
> download failed
> making and entering
> /share/linux2/AOO413/main/solenv/unxlngx6.pro/misc/build/
> can not find the dmake package
> 
> 
> 
> It doesn't matter if it's a HTTP or HTTPS URL.

It matters, sourceforge is redirecting all HTTP to HTTPS.

> I can workaround this by using the dmake binary built in trunk with the
> "--with-dmake-path" option. Then I can build until errors in these modules:
> 
> more_fonts (which are the dejavu fonts), libxml2, expat, curl
> 
> Looking at the errors it seems that the 4 package files cannot be build as
> they were not downloaded.
> 
> I think the downloading of external libraries/dependencis isn't working like
> for trunk. Any reason for the difference?

There have been some changes in the code that hasn't been cherrypicked,
I'd try to merge those changes and test.

> Needless to say that with trunk I don't have this problem. ;-)
> 
> Any hint for root cause and solution?

You might be missing some perl modules that enable HTTPS, the configure
on branch AOO413 does not fail if those are not installed. Check if you
have the following modules:

perl-Archive-Zip
perl-XML-Parser
perl-Digest-SHA
perl-Digest-MD5
perl-Crypt-SSLeay
perl-libwww-perl
perl-LWP-Protocol-https

Do not install modules using CPAN, use the packagemanager, yum or dnf on
newer Fedora. For example:

dnf info perl-Crypt-SSLeay
yum info perl-Crypt-SSLeay

If the packages do not exist with this names, use the perl module path
to find out which package provides it:

dnf whatprovides */Crypt/SSLeay.pm
yum whatprovides */Crypt/SSLeay.pm

I opened two tasks:
https://bz.apache.org/ooo/show_bug.cgi?id=127119
https://bz.apache.org/ooo/show_bug.cgi?id=127120


Regards
-- 
Ariel Constenla-Haile


signature.asc
Description: Digital signature

Re: Building 4.1.3: Error with dmake and further packages

I've tried the whole afternoon. I cannot get bootstrap to downlaod the 
external libraries that are missing. When doing this manually with wget 
then it's no problem. So, Sourceforge has them but they cannot be 
downloaded when the build is prepared.


Marcus



Am 09/17/2016 12:51 PM, schrieb Marcus:

Hi all,

I want to build the current 4.1.3 source.

Therefore I've checked out today the new AOO413 branch (incl. Ariels
last commit r1761157 !).

Configure was successful but bootstrap throws an error:



download from
http://sourceforge.net/projects/oooextras.mirror/files/dmake-4.12.tar.bz2 failed

download failed
making and entering
/share/linux2/AOO413/main/solenv/unxlngx6.pro/misc/build/
can not find the dmake package



It doesn't matter if it's a HTTP or HTTPS URL.

I can workaround this by using the dmake binary built in trunk with the
"--with-dmake-path" option. Then I can build until errors in these modules:

more_fonts (which are the dejavu fonts), libxml2, expat, curl

Looking at the errors it seems that the 4 package files cannot be build
as they were not downloaded.

I think the downloading of external libraries/dependencis isn't working
like for trunk. Any reason for the difference?

Needless to say that with trunk I don't have this problem. ;-)

Any hint for root cause and solution?

Thanks

Marcus


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Building 4.1.3: Error with dmake and further packages


Hi all,

I want to build the current 4.1.3 source.

Therefore I've checked out today the new AOO413 branch (incl. Ariels 
last commit r1761157 !).


Configure was successful but bootstrap throws an error:



download from 
http://sourceforge.net/projects/oooextras.mirror/files/dmake-4.12.tar.bz2 failed

download failed
making and entering 
/share/linux2/AOO413/main/solenv/unxlngx6.pro/misc/build/

can not find the dmake package



It doesn't matter if it's a HTTP or HTTPS URL.

I can workaround this by using the dmake binary built in trunk with the 
"--with-dmake-path" option. Then I can build until errors in these modules:


more_fonts (which are the dejavu fonts), libxml2, expat, curl

Looking at the errors it seems that the 4 package files cannot be build 
as they were not downloaded.


I think the downloading of external libraries/dependencis isn't working 
like for trunk. Any reason for the difference?


Needless to say that with trunk I don't have this problem. ;-)

Any hint for root cause and solution?

Thanks

Marcus

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

4.1.3_release_blocker granted: [Issue 127118] Update dmake URL in configure

2016-09-17 Thread bugzilla

Patricia Shanahan <p...@acm.org> has granted Ariel Constenla-Haile
<arie...@apache.org>'s request for 4.1.3_release_blocker:
Issue 127118: Update dmake URL in configure
https://bz.apache.org/ooo/show_bug.cgi?id=127118

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

4.1.3_release_blocker requested: [Issue 127118] Update dmake URL in configure

2016-09-16 Thread bugzilla

Ariel Constenla-Haile <arie...@apache.org> has asked  for
4.1.3_release_blocker:
Issue 127118: Update dmake URL in configure
https://bz.apache.org/ooo/show_bug.cgi?id=127118



--- Description ---
configure help points to an URL that does not work:


AC_ARG_WITH(dmake-url,
[  --with-dmake-url=   Specify the location of downloadable dmake source
code. For example:
 
http://dmake.apache-extras.org.codespot.com/files/dmake-4.12.tar.bz2
  Note that dmake is under GPL license.],


Revision 1758093 should be cherrypicked in branch AOO413
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: dmake

> On Sep 15, 2016, at 12:31 PM, Ariel Constenla-Haile  
> wrote:
> 
> 
> Note that we could also update the AOO patch to make epm get rid of the
> PackageMaker, the patch already fixes the path:
> http://svn.apache.org/viewvc/openoffice/trunk/main/epm/epm-3.7.patch?revision=1413471=markup#l381
> We could change that system call.

The issue is that PackageMaker is old, old. It is no longer
even obtainable unless you are lucky enough to have an
old copy of the Xcode dev tools. So for people who wish to
build AOO under OSX, the dependency on PackageMaker is a
NoGo.

When Apple deprecated PackageMaker, they replaced it with
a command-line suite (pkg*). Unfortunately, all versions of
epm older than 4.3 have no concept of it and instead rely
on PackageMaker.

So it would be nice to be able to standardize on 4.3 for ALL
platforms, but that means applying the 3.7-patch to 4.3... that
is what I'm working on now at https://github.com/jimjag/epm/tree/aoo
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: dmake

Here's what I have so far:

https://github.com/jimjag/epm/tree/aoo
> On Sep 15, 2016, at 10:48 AM, Jim Jagielski  wrote:
> 
> 
>> On Sep 15, 2016, at 10:13 AM, Jim Jagielski  wrote:
>> 
>> 
>>> On Sep 15, 2016, at 9:44 AM, Andrea Pescetti  wrote:
>>> 
>>> That would be challenging but useful then. For epm, as Ariel already 
>>> explained to you, we use a patched version so it's not a trivial task to 
>>> replace it, but probably it's feasible.
>>> 
>> 
>> It looks like most of the epm patch is not related to OSX (except for
>> some minor things)... The reliance on PackageMaker is a major
>> hurdle and one which will only get worse as things go on.
>> 
>> epm 4.3 may not be feasible for non-OSX but so far it's been a
>> major boon for the Mac.
>> 
>> Has anyone been in contact w/ Michael Sweet to get our required
>> patches into his distro?? 
> 
> In the meantime, I'll look at patching 4.3 w/ the 3.7 patch to
> create a cleanly applying one.
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: dmake

2016-09-15 Thread Ariel Constenla-Haile

Hi Jim,

On Thu, Sep 15, 2016 at 10:13:08AM -0400, Jim Jagielski wrote:
> It looks like most of the epm patch is not related to OSX (except for
> some minor things)... 

last time I tried on Linux some years ago with the latest upstream, it had 
several bugs; looking at the release notes, it seems they fixed several Linux 
bugs.
https://www.msweet.org/projects.php?Z2

> The reliance on PackageMaker is a major
> hurdle and one which will only get worse as things go on.
> 
> epm 4.3 may not be feasible for non-OSX but so far it's been a
> major boon for the Mac.

The build system seems to do some weird things, checking if epm is
patched by AOO:
http://svn.apache.org/viewvc/openoffice/trunk/main/solenv/bin/modules/installer/epmfile.pm?revision=1591062=markup#l849
I guess unpatched epm breaks somewhere.

Note that we could also update the AOO patch to make epm get rid of the
PackageMaker, the patch already fixes the path:
http://svn.apache.org/viewvc/openoffice/trunk/main/epm/epm-3.7.patch?revision=1413471=markup#l381
We could change that system call.

> Has anyone been in contact w/ Michael Sweet to get our required
> patches into his distro?? 

It seems that Sun developers didn't care about upstreamming their fixes,
I tried now to look at the 4.3 bug fixes, and it required an account...
https://www.msweet.org/login.php?PAGE=bugs.php%3FU497%2BP0%2BS-2%2BI0%2BE0%2BZ-1%2BQ

Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina

signature.asc
Description: Digital signature

Re: dmake


> On Sep 15, 2016, at 10:13 AM, Jim Jagielski  wrote:
> 
> 
>> On Sep 15, 2016, at 9:44 AM, Andrea Pescetti  wrote:
>> 
>> That would be challenging but useful then. For epm, as Ariel already 
>> explained to you, we use a patched version so it's not a trivial task to 
>> replace it, but probably it's feasible.
>> 
> 
> It looks like most of the epm patch is not related to OSX (except for
> some minor things)... The reliance on PackageMaker is a major
> hurdle and one which will only get worse as things go on.
> 
> epm 4.3 may not be feasible for non-OSX but so far it's been a
> major boon for the Mac.
> 
> Has anyone been in contact w/ Michael Sweet to get our required
> patches into his distro?? 

In the meantime, I'll look at patching 4.3 w/ the 3.7 patch to
create a cleanly applying one.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: dmake

> On Sep 15, 2016, at 9:44 AM, Andrea Pescetti  wrote:
> 
> That would be challenging but useful then. For epm, as Ariel already 
> explained to you, we use a patched version so it's not a trivial task to 
> replace it, but probably it's feasible.
> 

It looks like most of the epm patch is not related to OSX (except for
some minor things)... The reliance on PackageMaker is a major
hurdle and one which will only get worse as things go on.

epm 4.3 may not be feasible for non-OSX but so far it's been a
major boon for the Mac.

Has anyone been in contact w/ Michael Sweet to get our required
patches into his distro?? 
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: dmake

2016-09-15 Thread John D'Orazio

It's good to know about the sourceforge copy of epm too, I'll update some
of the wiki links that are pointing to third party links.

On Thu, Sep 15, 2016 at 3:44 PM, Andrea Pescetti <pesce...@apache.org>
wrote:

> Jim Jagielski wrote:
>
>> epm is required and not under our control.
>>
>
> We have a copy under our control at
> https://sourceforge.net/projects/oooextras.mirror/files/epm-3.7.tar.gz
> and I would recommend that one over an external site.
>
> In fact, epm 4.3 is out  and work much better for AOO
>>
>
> That would be challenging but useful then. For epm, as Ariel already
> explained to you, we use a patched version so it's not a trivial task to
> replace it, but probably it's feasible.
>
> Or is this the typical warm and inviting behavior that all
>> "new" AOO contributors are subjected to?
>>
>
> It wasn't meant to be rude. I hope you agree that starting a new project
> under your name at Github for a non-issue (we don't have actual issues with
> dmake right now; or I never heard about them) is not top priority, even
> though it might have advantages in the long term.
>
> We digress, but if I can make an example of a priority issue on Mac OS X I
> would pick https://bz.apache.org/ooo/show_bug.cgi?id=126622 (proper QA
> for a 4.1.3 release blocker). Of course, like all volunteers, you choose
> how to allocate your time and this will be appreciated in all cases. Thank
> you for helping out!
>
> Regards,
>   Andrea.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>


-- 
John R. D'Orazio

Re: dmake

2016-09-15 Thread Andrea Pescetti


Jim Jagielski wrote:

epm is required and not under our control.


We have a copy under our control at
https://sourceforge.net/projects/oooextras.mirror/files/epm-3.7.tar.gz
and I would recommend that one over an external site.


In fact, epm 4.3 is out  and work much better for AOO


That would be challenging but useful then. For epm, as Ariel already 
explained to you, we use a patched version so it's not a trivial task to 
replace it, but probably it's feasible.



Or is this the typical warm and inviting behavior that all
"new" AOO contributors are subjected to?


It wasn't meant to be rude. I hope you agree that starting a new project 
under your name at Github for a non-issue (we don't have actual issues 
with dmake right now; or I never heard about them) is not top priority, 
even though it might have advantages in the long term.


We digress, but if I can make an example of a priority issue on Mac OS X 
I would pick https://bz.apache.org/ooo/show_bug.cgi?id=126622 (proper QA 
for a 4.1.3 release blocker). Of course, like all volunteers, you choose 
how to allocate your time and this will be appreciated in all cases. 
Thank you for helping out!


Regards,
  Andrea.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: dmake


> On Sep 14, 2016, at 6:40 PM, Jim Jagielski  wrote:
> 
> 
> epm is required and not under our control. In fact, epm 4.3 is out
> and work much better for AOO since it removes the need for the
> long-since deprecated PackageMaker app and instead uses the
> official pkgbuild stuff. Part of my configure.in changes (to
> be submitted to trunk) notices that.
> 

FWIW, this is for MacOS


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: dmake

> On Sep 14, 2016, at 5:28 PM, Andrea Pescetti <pesce...@apache.org> wrote:
> 
> Jim Jagielski wrote:
>> Tarballs are at:
>>  https://github.com/jimjag/dmake/releases
>> My goal was to try to combine all the flavors of dmake into one
>> "canonical" version we can use.
> 
> Is there a reason for that?
> 

The only reason I saw was that it was a dependency that we
haven't tracked at all (see the req to fix configure.am/in
with the correct URL) and was/is easy to lose. There seemed
to have been some improvements since 4.12 that also looked
like they might have been useful.

All in all, have a tarball w/ no real source version
control, and a tarball whose location has changed and
been lost, up to now, seems like an easy thing to
resolve. Hence the repo.

> 
> Our build is designed to succeed based only on resources under control of the 
> project, namely: the SVN repository; the OOoExtras site; the Extensions site. 
> Depending on yet another online resource (a personal account on GitHub) seems 
> an additional issue.
> 

epm is required and not under our control. In fact, epm 4.3 is out
and work much better for AOO since it removes the need for the
long-since deprecated PackageMaker app and instead uses the
official pkgbuild stuff. Part of my configure.in changes (to
be submitted to trunk) notices that.

Or is this the typical warm and inviting behavior that all
"new" AOO contributors are subjected to?
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: dmake

2016-09-14 Thread Andrea Pescetti


Jim Jagielski wrote:

Tarballs are at:
https://github.com/jimjag/dmake/releases
My goal was to try to combine all the flavors of dmake into one
"canonical" version we can use.


Is there a reason for that?

So far it has been enough for us to get a specific dmake tarball from a 
certain URL specified at build time. We just use that version of dmake, 
without working on it any further since we have no need for that, unless 
I'm missing something.


Our build is designed to succeed based only on resources under control 
of the project, namely: the SVN repository; the OOoExtras site; the 
Extensions site. Depending on yet another online resource (a personal 
account on GitHub) seems an additional issue.


Under the assumption that this new repository is useful, 
https://github.com/jimjag/dmake/commit/e9edbf3228af898e6832b4346355f1e4c9ed867a 
should be fixed to include the correct name of the project.


But at this time I can't find a good reason for it, except the usual 
"one new standard to unify them all" joke.


Regards,
  Andrea.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: dmake

Tarballs are at:

https://github.com/jimjag/dmake/releases

My goal was to try to combine all the flavors of dmake into one
"canonical" version we can use.

> On Sep 14, 2016, at 3:12 PM, John D'Orazio 
> <john.dora...@cappellaniauniroma3.org> wrote:
> 
> I myself just ran into the problem of the missing apache-extras link, I've
> used a sourceforge link for my build:
> http://sourceforge.net/projects/oooextras.mirror/files/dmake-4.12.tar.bz2.
> Most of the links indicated in your github repo's README are dead links...
> I believe a downloadable tarball is useful for the building process, the
> sourceforge tarball seems to be working for me so far (it's my first build,
> and it's still building, but it's gotten past the initial dmake
> installation stage at least).
> 
> On Wed, Sep 14, 2016 at 5:25 PM, Jim Jagielski <j...@jagunet.com> wrote:
> 
>> Seeing that there is a dependency, still, on dmake, I've gone
>> ahead and created
>> 
>>https://github.com/jimjag/dmake
>> 
>> based on what I've been using... Suggestions and patches
>> welcome. Hoping we can use this to replace the apche-extras
>> links.
>> 
>> It's based on (https://github.com/mohawk2/dmake)
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>> 
>> 
> 
> 
> -- 
> John R. D'Orazio


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: dmake

2016-09-14 Thread John D'Orazio

I myself just ran into the problem of the missing apache-extras link, I've
used a sourceforge link for my build:
http://sourceforge.net/projects/oooextras.mirror/files/dmake-4.12.tar.bz2.
Most of the links indicated in your github repo's README are dead links...
I believe a downloadable tarball is useful for the building process, the
sourceforge tarball seems to be working for me so far (it's my first build,
and it's still building, but it's gotten past the initial dmake
installation stage at least).

On Wed, Sep 14, 2016 at 5:25 PM, Jim Jagielski <j...@jagunet.com> wrote:

> Seeing that there is a dependency, still, on dmake, I've gone
> ahead and created
>
> https://github.com/jimjag/dmake
>
> based on what I've been using... Suggestions and patches
> welcome. Hoping we can use this to replace the apche-extras
> links.
>
> It's based on (https://github.com/mohawk2/dmake)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

-- 
John R. D'Orazio

dmake