Re: [1.3] Compiling package.C fails on Debian unstable

[Jean-Marc Lasgouttes]

 Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:

Lars Then this will be automatically installed by autogen.sh.

Well, we need to have the right one to generate the tarball anyway.

Lars Will that help at all? Or does libtool have a problem with
Lars FreeBSD and Darwin in general?

I gave FreeBSD and Darwin as gratuitous examples, I do not remember
the specifics. Contrary to autoconf, libtool relies on a big switch to
know what to do with each platform, which means that it is very
sensitive to behavioral changes in different versions of OSes.

JMarc

Re: [1.3] Compiling package.C fails on Debian unstable

[Jean-Marc Lasgouttes]

> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:

Lars> Then this will be automatically installed by autogen.sh.

Well, we need to have the right one to generate the tarball anyway.

Lars> Will that help at all? Or does libtool have a problem with
Lars> FreeBSD and Darwin in general?

I gave FreeBSD and Darwin as gratuitous examples, I do not remember
the specifics. Contrary to autoconf, libtool relies on a big switch to
know what to do with each platform, which means that it is very
sensitive to behavioral changes in different versions of OSes.

JMarc

Re: [1.3] Compiling package.C fails on Debian unstable

[Georg Baum]

Am Sonntag, 29. Mai 2005 15:36 schrieb Angus Leeming:

 I compile on Debian unstable (linux alpha box) without any problems
 whatsoever.

Thanks for the hint, it made me look at the configure flags (I took 
the .diff.gz from http://packages.debian.org/lyx and made my own .deb 
from it), and it turned out that configure was called with 
--enable-shared. After removing that everything was OK.

Conclusion: --enable-shared is broken in 1.3.6cvs.


Georg

Re: [1.3] Compiling package.C fails on Debian unstable

[Lars Gullik Bjønnes]

Georg Baum [EMAIL PROTECTED] writes:

| Am Sonntag, 29. Mai 2005 15:36 schrieb Angus Leeming:

 I compile on Debian unstable (linux alpha box) without any problems
 whatsoever.

| Thanks for the hint, it made me look at the configure flags (I took 
| the .diff.gz from http://packages.debian.org/lyx and made my own .deb 
| from it), and it turned out that configure was called with 
| --enable-shared. After removing that everything was OK.

| Conclusion: --enable-shared is broken in 1.3.6cvs.

--enable-shared is not supposed to work... (we only support
--enable-statid --disable-shared)
But I have no idea how we can remove that from configure --help.

-- 
Lgb

Re: [1.3] Compiling package.C fails on Debian unstable

[Jean-Marc Lasgouttes]

 Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:

Lars --enable-shared is not supposed to work... (we only support
Lars --enable-statid --disable-shared) But I have no idea how we can
Lars remove that from configure --help.

Just get rid of libtool, maybe. When you read its description in the
info pages, it says it is useful when building dynamic libs. It may be
that we do not need it at all (just use foo_LIBRARIES instead of
foo_LTLIBRARIES in Makefile.am and get rid of libtool code in
configure.ac).

JMarc

Re: [1.3] Compiling package.C fails on Debian unstable

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:

 Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:

| Lars --enable-shared is not supposed to work... (we only support
| Lars --enable-statid --disable-shared) But I have no idea how we can
| Lars remove that from configure --help.

| Just get rid of libtool, maybe. When you read its description in the
| info pages, it says it is useful when building dynamic libs. It may be
| that we do not need it at all (just use foo_LIBRARIES instead of
| foo_LTLIBRARIES in Makefile.am and get rid of libtool code in
| configure.ac).

No no... arrgghhh no.

libtool is nice. And I have plans for it (even for --enable-shared)

-- 
Lgb

Re: [1.3] Compiling package.C fails on Debian unstable

[Jean-Marc Lasgouttes]

 Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:

Lars libtool is nice. And I have plans for it (even for
Lars --enable-shared)

You need to make up you mind :)

JMarc

Re: [1.3] Compiling package.C fails on Debian unstable

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:

 Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:

| Lars libtool is nice. And I have plans for it (even for
| Lars --enable-shared)

| You need to make up you mind :)

My mind is made up. what makes you belive otherwise?

-- 
Lgb

Re: [1.3] Compiling package.C fails on Debian unstable

[Jean-Marc Lasgouttes]

 Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:

Lars My mind is made up. what makes you belive otherwise?

   ``--enable-shared is not supposed to work... (we only support
 --enable-static --disable-shared) But I have no idea how we can
 remove that from configure --help.''

This reads like: we do not need shared libs and we do not care about
them.

Libtool means that we carry some additional bloat and inconvenience.
This has been for no good reason up to now.

JMarc

Re: [1.3] Compiling package.C fails on Debian unstable

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:

 Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:

| Lars My mind is made up. what makes you belive otherwise?

|``--enable-shared is not supposed to work... (we only support
|  --enable-static --disable-shared) But I have no idea how we can
|  remove that from configure --help.''

| This reads like: we do not need shared libs and we do not care about
| them.

| Libtool means that we carry some additional bloat and inconvenience.
| This has been for no good reason up to now.

But we care about libtool. We use it for the simpler way of creating
convenience libraries.

-- 
Lgb

Re: [1.3] Compiling package.C fails on Debian unstable

[Jean-Marc Lasgouttes]

 Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:

Lars But we care about libtool. We use it for the simpler way of
Lars creating convenience libraries.

The automake and libtool documentation imply that libtool only matters
for shared libraries. Are you saying that what we get from libtools is
the .la file handling? What else is simpler wrt what automake already
does?

JMarc

Re: [1.3] Compiling package.C fails on Debian unstable

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:

 Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:

| Lars But we care about libtool. We use it for the simpler way of
| Lars creating convenience libraries.

| The automake and libtool documentation imply that libtool only matters
| for shared libraries. Are you saying that what we get from libtools is
| the .la file handling? What else is simpler wrt what automake already
| does?

libtool know more about library creation, and also dependencies are
stored in the .la file. and we use this to localize dependency
information to the module.

-- 
Lgb

Re: [1.3] Compiling package.C fails on Debian unstable

[Jean-Marc Lasgouttes]

 Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:

Lars libtool know more about library creation, and also dependencies
Lars are stored in the .la file. and we use this to localize
Lars dependency information to the module.

It would be nice to have a light option to libtool that just does
the static libs. Most of the code is for shqred ones, and it is the
part that causes us problems when such and such script is not up to
date.

JMarc

Re: [1.3] Compiling package.C fails on Debian unstable

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:

 Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:

| Lars libtool know more about library creation, and also dependencies
| Lars are stored in the .la file. and we use this to localize
| Lars dependency information to the module.

| It would be nice to have a light option to libtool that just does
| the static libs. Most of the code is for shqred ones, and it is the
| part that causes us problems when such and such script is not up to
| date.

What problems in particular?

-- 
Lgb

Re: [1.3] Compiling package.C fails on Debian unstable

[Jean-Marc Lasgouttes]

 Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:

Lars What problems in particular?

That the script should be updated to support Darwin 4.7.12 or FreeBSD
12.0.0.1. You know, the fun of being a maintainer :)

But I am not really trying to get rid of libtool. But there is a lot
of nonsense we do not need.

JMarc

Re: [1.3] Compiling package.C fails on Debian unstable

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:

 Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:

| Lars What problems in particular?

| That the script should be updated to support Darwin 4.7.12 or FreeBSD
| 12.0.0.1. You know, the fun of being a maintainer :)

| But I am not really trying to get rid of libtool. But there is a lot
| of nonsense we do not need.

We could remove the libtool script from cvs so that the developer
needs to have the libtool setup stuff installed.

Then this will be automatically installed by autogen.sh.

Will that help at all? Or does libtool have a problem with FreeBSD and
Darwin in general?

-- 
Lgb

Re: [1.3] Compiling package.C fails on Debian unstable

[Georg Baum]

Am Sonntag, 29. Mai 2005 15:36 schrieb Angus Leeming:

> I compile on Debian unstable (linux alpha box) without any problems
> whatsoever.

Thanks for the hint, it made me look at the configure flags (I took 
the .diff.gz from http://packages.debian.org/lyx and made my own .deb 
from it), and it turned out that configure was called with 
--enable-shared. After removing that everything was OK.

Conclusion: --enable-shared is broken in 1.3.6cvs.


Georg

Re: [1.3] Compiling package.C fails on Debian unstable

[Lars Gullik Bjønnes]

Georg Baum <[EMAIL PROTECTED]> writes:

| Am Sonntag, 29. Mai 2005 15:36 schrieb Angus Leeming:
>
>> I compile on Debian unstable (linux alpha box) without any problems
>> whatsoever.
>
| Thanks for the hint, it made me look at the configure flags (I took 
| the .diff.gz from http://packages.debian.org/lyx and made my own .deb 
| from it), and it turned out that configure was called with 
| --enable-shared. After removing that everything was OK.
>
| Conclusion: --enable-shared is broken in 1.3.6cvs.

--enable-shared is not supposed to work... (we only support
--enable-statid --disable-shared)
But I have no idea how we can remove that from configure --help.

-- 
Lgb

Re: [1.3] Compiling package.C fails on Debian unstable

[Jean-Marc Lasgouttes]

> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:

Lars> --enable-shared is not supposed to work... (we only support
Lars> --enable-statid --disable-shared) But I have no idea how we can
Lars> remove that from configure --help.

Just get rid of libtool, maybe. When you read its description in the
info pages, it says it is useful when building dynamic libs. It may be
that we do not need it at all (just use foo_LIBRARIES instead of
foo_LTLIBRARIES in Makefile.am and get rid of libtool code in
configure.ac).

JMarc

Re: [1.3] Compiling package.C fails on Debian unstable

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:

>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
| Lars> --enable-shared is not supposed to work... (we only support
| Lars> --enable-statid --disable-shared) But I have no idea how we can
| Lars> remove that from configure --help.
>
| Just get rid of libtool, maybe. When you read its description in the
| info pages, it says it is useful when building dynamic libs. It may be
| that we do not need it at all (just use foo_LIBRARIES instead of
| foo_LTLIBRARIES in Makefile.am and get rid of libtool code in
| configure.ac).

No no... arrgghhh no.

libtool is nice. And I have plans for it (even for --enable-shared)

-- 
Lgb

Re: [1.3] Compiling package.C fails on Debian unstable

[Jean-Marc Lasgouttes]

> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:

Lars> libtool is nice. And I have plans for it (even for
Lars> --enable-shared)

You need to make up you mind :)

JMarc

Re: [1.3] Compiling package.C fails on Debian unstable

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:

>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
| Lars> libtool is nice. And I have plans for it (even for
| Lars> --enable-shared)
>
| You need to make up you mind :)

My mind is made up. what makes you belive otherwise?

-- 
Lgb

Re: [1.3] Compiling package.C fails on Debian unstable

[Jean-Marc Lasgouttes]

> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:

Lars> My mind is made up. what makes you belive otherwise?

   ``--enable-shared is not supposed to work... (we only support
 --enable-static --disable-shared) But I have no idea how we can
 remove that from configure --help.''

This reads like: we do not need shared libs and we do not care about
them.

Libtool means that we carry some additional bloat and inconvenience.
This has been for no good reason up to now.

JMarc

Re: [1.3] Compiling package.C fails on Debian unstable

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:

>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
| Lars> My mind is made up. what makes you belive otherwise?
>
|``--enable-shared is not supposed to work... (we only support
|  --enable-static --disable-shared) But I have no idea how we can
|  remove that from configure --help.''
>
| This reads like: we do not need shared libs and we do not care about
| them.
>
| Libtool means that we carry some additional bloat and inconvenience.
| This has been for no good reason up to now.

But we care about libtool. We use it for the simpler way of creating
convenience libraries.

-- 
Lgb

Re: [1.3] Compiling package.C fails on Debian unstable

[Jean-Marc Lasgouttes]

> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:

Lars> But we care about libtool. We use it for the simpler way of
Lars> creating convenience libraries.

The automake and libtool documentation imply that libtool only matters
for shared libraries. Are you saying that what we get from libtools is
the .la file handling? What else is simpler wrt what automake already
does?

JMarc

Re: [1.3] Compiling package.C fails on Debian unstable

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:

>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
| Lars> But we care about libtool. We use it for the simpler way of
| Lars> creating convenience libraries.
>
| The automake and libtool documentation imply that libtool only matters
| for shared libraries. Are you saying that what we get from libtools is
| the .la file handling? What else is simpler wrt what automake already
| does?

libtool know more about library creation, and also dependencies are
stored in the .la file. and we use this to localize dependency
information to the module.

-- 
Lgb

Re: [1.3] Compiling package.C fails on Debian unstable

[Jean-Marc Lasgouttes]

> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:

Lars> libtool know more about library creation, and also dependencies
Lars> are stored in the .la file. and we use this to localize
Lars> dependency information to the module.

It would be nice to have a "light" option to libtool that just does
the static libs. Most of the code is for shqred ones, and it is the
part that causes us problems when such and such script is not up to
date.

JMarc

Re: [1.3] Compiling package.C fails on Debian unstable

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:

>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
| Lars> libtool know more about library creation, and also dependencies
| Lars> are stored in the .la file. and we use this to localize
| Lars> dependency information to the module.
>
| It would be nice to have a "light" option to libtool that just does
| the static libs. Most of the code is for shqred ones, and it is the
| part that causes us problems when such and such script is not up to
| date.

What problems in particular?

-- 
Lgb

Re: [1.3] Compiling package.C fails on Debian unstable

[Jean-Marc Lasgouttes]

> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:

Lars> What problems in particular?

That the script should be updated to support Darwin 4.7.12 or FreeBSD
12.0.0.1. You know, the fun of being a maintainer :)

But I am not really trying to get rid of libtool. But there is a lot
of nonsense we do not need.

JMarc

Re: [1.3] Compiling package.C fails on Debian unstable

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:

>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
| Lars> What problems in particular?
>
| That the script should be updated to support Darwin 4.7.12 or FreeBSD
| 12.0.0.1. You know, the fun of being a maintainer :)
>
| But I am not really trying to get rid of libtool. But there is a lot
| of nonsense we do not need.

We could remove the libtool script from cvs so that the developer
needs to have the libtool setup stuff installed.

Then this will be automatically installed by autogen.sh.

Will that help at all? Or does libtool have a problem with FreeBSD and
Darwin in general?

-- 
Lgb

Re: [1.3] Compiling package.C fails on Debian unstable

[Angus Leeming]

Georg Baum wrote:

 As said in the subject. The handmade Makefile rule writes 'timestamp' to
 package.lo instead of object code. This file gets linked into libsupport,
 and I get lots of errors like
 
 BufferView_pimpl.o: In function
 `BufferView::Pimpl::MenuInsertLyXFile(std::basic_stringchar,
 std::char_traitschar, std::allocatorchar  const)':
 BufferView_pimpl.C:(.text+0xc0bd): undefined reference to
 `lyx::package()'

I compile on Debian unstable (linux alpha box) without any problems
whatsoever.
 
 Why don't we have a package.C.in like in 1.4?

shrug. Because Jean-Marc rewrote how these compile time constants are
handled for 1.4.

-- 
Angus

Re: [1.3] Compiling package.C fails on Debian unstable

[Angus Leeming]

Georg Baum wrote:

> As said in the subject. The handmade Makefile rule writes 'timestamp' to
> package.lo instead of object code. This file gets linked into libsupport,
> and I get lots of errors like
> 
> BufferView_pimpl.o: In function
> `BufferView::Pimpl::MenuInsertLyXFile(std::basic_string std::char_traits, std::allocator > const&)':
> BufferView_pimpl.C:(.text+0xc0bd): undefined reference to
> `lyx::package()'

I compile on Debian unstable (linux alpha box) without any problems
whatsoever.
 
> Why don't we have a package.C.in like in 1.4?

shrug. Because Jean-Marc rewrote how these compile time constants are
handled for 1.4.

-- 
Angus