headers
Leon Bottou | 3 Feb 2003 17:45

Fwd: mybindir


----------  Forwarded Message  ----------

Subject: mybindir
Date: Mon, 3 Feb 2003 11:29:53 -0500
From: Leon Bottou <leonb <at> nec-labs.com>
To: kevinrosenberg <at> users.sourceforge.net

Your change to mybindir breaks my build.
I reverted it for now.

${mybindir} is only used when running lush
from the compilation directory.

In fact, instead of
%  configure && make && make install
you could do
%  configure && make all && make install

This completely bypasses the definition
of $mybindir and simply uses $bindir
to install the binary.

One tricky point is the generation of the dump file.
The dump file must be generated after installing
the various lsh files because it contains
timestamps.  This is why 'make install'
generates a new version of the dump file
before installing it.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Leon Bottou | 3 Feb 2003 17:50

configure, make, etc


Kevin,

I am reading debian/rule and observe that it works 
by first doing:
  configure --prefix=${DESTDIR}/usr mandir=...
then
  make
then 
  make install

This is because the lush makefiles do not 
support the DESTDIR variable popularized by automake.
Maybe we should fix this because people seem to expect it.

Here is the way we imagine the build sequence:
First do
  configure --prefix=/usr
then 
  make all
then
  make install-nolink prefix=${DESTDIR}/usr mandir=...

Comments ?

- Leon

-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
(Continue reading)

Permalink | Reply | 3 comments |
headers
Leon Bottou | 3 Feb 2003 18:01

DESTDIR

On Monday 03 February 2003 11:50 am, Leon Bottou wrote:
> This is because the lush makefiles do not
> support the DESTDIR variable popularized by automake.
> Maybe we should fix this because people seem to expect it.

There is now DESTDIR support.
The build sequence can be:
   configure --prefix=/usr --mandir=/usr/share/man
then
   make all
then
   make install  DESTDIR=/var/tmp/tmproot

This seems easier.

- Leon

-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
Permalink | Reply | 1 comment |
headers
Kevin Rosenberg | 3 Feb 2003 18:10
Favicon

Re: DESTDIR

Leon Bottou wrote:
> On Monday 03 February 2003 11:50 am, Leon Bottou wrote:
> > This is because the lush makefiles do not
> > support the DESTDIR variable popularized by automake.
> > Maybe we should fix this because people seem to expect it.
> 
> There is now DESTDIR support.
> The build sequence can be:
>    configure --prefix=/usr --mandir=/usr/share/man
> then
>    make all
> then
>    make install  DESTDIR=/var/tmp/tmproot
> 
> This seems easier.

Thanks for the rapid fix!

--

-- 
       Kevin Rosenberg        |  .''`.  ** Debian GNU/Linux **
  http://b9.com/debian.html   | : :' :      The  universal
  GPG signed and encrypted    | `. `'      Operating System
     messages accepted.       |   `-    http://www.debian.org/

-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
Permalink | Reply | 0 comments |
headers
Kevin Rosenberg | 3 Feb 2003 18:09
Favicon

Re: configure, make, etc

Leon Bottou wrote:
> I am reading debian/rule and observe that it works 
> by first doing:
>   configure --prefix=${DESTDIR}/usr mandir=...
> then
>   make
> then 
>   make install

That's essentially correct, except for the minor point that it uses
"make all" rather than just "make"

> This is because the lush makefiles do not 
> support the DESTDIR variable popularized by automake.
> Maybe we should fix this because people seem to expect it.

Yes, that is a common way to set the final destination with the
configure script.

> Here is the way we imagine the build sequence:
> First do
>   configure --prefix=/usr
> then 
>   make all
> then
>   make install-nolink prefix=${DESTDIR}/usr mandir=...
> 
> Comments ?

That's different from the GNU standard idiom, but I'm very glad to use
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brent Fulgham | 5 Feb 2003 01:19

0.97 Is a regression for Cygwin

I just got 0.96 built and working under Cygwin:

The only big issue I see is that I get an assertion failure each time I attempt to compile Lush code:

               /* Insert entry into global hash table */
                hsym = insert_symbol(drop_leading_char(abfd,sym->name));
                ASSERT(! (hsym->flags & DLDF_DEFD));
                hsym->flags = DLDF_DEFD;

However, I can't even run 0.97's (helptool) at all under 0.97.  I get:

**** GASP: Severe error : Signal 11 has occurred
**** GASP: Trying to recover
**** GASP: You should save your work immediatly

I couldn't find a Changelog for the 0.97 release, so I don' t have a clue where to start looking.

Thanks,

-Brent

-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
Permalink | Reply | 1 comment |
headers
Leon Bottou | 5 Feb 2003 04:21

Re: 0.97 Is a regression for Cygwin

> However, I can't even run 0.97's (helptool) at all under 0.97.  I get:
> **** GASP: Severe error : Signal 11 has occurred
> **** GASP: Trying to recover
> **** GASP: You should save your work immediatly
> I couldn't find a Changelog for the 0.97 release, so I don' t have a clue
> where to start looking.

There are lots of changes in 0.97.
It might help to have a gdb stack trace.

> The only big issue I see is that I get an assertion failure each time I
> attempt to compile Lush code:
>                /* Insert entry into global hash table */
>                 hsym = insert_symbol(drop_leading_char(abfd,sym->name));
>                 ASSERT(! (hsym->flags & DLDF_DEFD));
>                 hsym->flags = DLDF_DEFD;

At this point lush already has generated the C and
compiled the OBJ file.   Could you email me
the output of 'objdump -fh --syms --disassemble  xxxx.obj'
on this file?

Thank you.

- Leon

-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brent Fulgham | 5 Feb 2003 18:44

RE: 0.97 Is a regression for Cygwin

> > However, I can't even run 0.97's (helptool) at all under 
> 0.97.  I get:
> > **** GASP: Severe error : Signal 11 has occurred
> > **** GASP: Trying to recover
> > **** GASP: You should save your work immediatly
> > I couldn't find a Changelog for the 0.97 release, so I don't 
> > have a clue where to start looking.
> 
> There are lots of changes in 0.97.
> It might help to have a gdb stack trace.
> 

I'm embarassed to admit I can't recreate this right now.  Perhaps
I had only partially installed Lush before, or there was some
active remnant of the 0.96 build in my path.

Things seem to work properly now.

> At this point lush already has generated the C and
> compiled the OBJ file.   Could you email me
> the output of 'objdump -fh --syms --disassemble  xxxx.obj'
> on this file?
>

Certainly.  This is the result of running the sequence of commands
in your documentations regarding the "harmonic" function:

junk.o:     file format pe-i386
architecture: i386, flags 0x00000039:
HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brent Fulgham | 8 Feb 2003 03:02

RE: 0.97 Is a regression for Cygwin

> > However, I can't even run 0.97's (helptool) at all under 
> 0.97.  I get:
> > **** GASP: Severe error : Signal 11 has occurred
> > **** GASP: Trying to recover
> > **** GASP: You should save your work immediatly
> > I couldn't find a Changelog for the 0.97 release, so I don' 
> t have a clue
> > where to start looking.
> 

Please note that this bug may appear depending on how you have
paths set up in Cygwin.  The standard installation treats /usr/bin
as a symlink to /bin.  If you install lush into /usr/bin, it
will expect to be able to go up two levels in the directory 
structure, then find /usr/share -- this doesn't happen and the
program crashes.

This is hard to find, because loading lush in gdb causes the
problem to go away because gdb correctly handles paths internally!

-Brent

-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
Permalink | Reply | 1 comment |
headers
Leon Bottou | 8 Feb 2003 14:36

Re: 0.97 Is a regression for Cygwin

On Friday 07 February 2003 09:02 pm, Brent Fulgham wrote:
> Please note that this bug may appear depending on how you have
> paths set up in Cygwin.  The standard installation treats /usr/bin
> as a symlink to /bin.  If you install lush into /usr/bin, it
> will expect to be able to go up two levels in the directory
> structure, then find /usr/share -- this doesn't happen and the
> program crashes.

When it cannot find the startup files, 
it is supposed to stop with a message
   Lush fatal error :  locate library files

If this is what is happening, I can fix with 
additional search rules.

But your email says 'the program crashes'.
Do you mean a segfault or a gasp message?

- Leon

-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
Permalink | Reply | 0 comments |

Gmane