On Tue, 12 May 2009, Markus Elfring wrote:
It does not seem likely that anything as exotic as data structures and
programming interfaces would be required. What is necessary is to get
the right people interested.
Would you like to introduce more software developers and designers into the
topi
> It does not seem likely that anything as exotic as data structures and
> programming interfaces would be required. What is necessary is to get
> the right people interested.
Would you like to introduce more software developers and designers into the
topic for useful discussion of the details?
W
On Tue, 12 May 2009, Markus Elfring wrote:
I am also interested to convert the wording from the specification into
something where specific default settings can be processed automatically.
http://pathname.com/fhs/pub/fhs-2.3.html#LIBLTQUALGTALTERNATEFORMATESSENTIAL
Will it be worth to invite mor
> My idea is to put this in one config file at a standard location which
> can include site specific information. This could include information
> such as special compile/link flags required for a particular
> architecture format and expected subdirectory or library file naming.
> It would list ar
On Mon, 11 May 2009, Markus Elfring wrote:
http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
The same sort of folks who were involved in developing this standard
could help with an architecture rules specification format.
Did you discuss this idea with any software developers befor
>> http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
> The same sort of folks who were involved in developing this standard
> could help with an architecture rules specification format.
Did you discuss this idea with any software developers before?
> Up to now, I have not heard of any
On Sun, 10 May 2009, Markus Elfring wrote:
Can the file system hierarchy standard help here?
http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
The same sort of folks who were involved in developing this standard
could help with an architecture rules specification format. GNU does
n
> It would be nice if there were standard file naming conventions. On
> my Solaris 10 system, the operating system uses one convention and GCC
> uses another. Packages may use another.
Do you see chances for a mapping between the available approaches?
Can the file system hierarchy standard hel
On Sat, 9 May 2009, Markus Elfring wrote:
Are there any chances to improve the situation on a limited combination
of these software components?
Yes, of course. Things become much easier if you only plan to solve a
subset of the problem. But we should solve the whole problem.
Can any defa
> If you know of a fully automatic way that works, and that not only for
> your system your distribution your current version, but for strictly
> more systems, distributions, versions, compilers and compiler versions
> for which the current method works then we're all ears.
Are there any chances
On Sat, 9 May 2009, Ralf Wildenhues wrote:
* Markus Elfring wrote on Fri, May 08, 2009 at 07:59:16PM CEST:
I am curious if the libtool software will ever be able to determine the
appropriate directory automatically on systems with multiple processor
architectures.
If you know of a fully autom
Hello Markus,
* Markus Elfring wrote on Fri, May 08, 2009 at 07:59:16PM CEST:
> I am curious if the libtool software will ever be able to determine the
> appropriate directory automatically on systems with multiple processor
> architectures.
If you know of a fully automatic way that works, and th
> Sorry that I was not of more help. It does seem necessary to specify
> the linker path to 64-bit libraries on the system. The fixes in
> libtool 2.2 seem to primarily be to assure that the correct compiler
> support and system libraries are used. Libtool queries GCC for the
> built-in linker s
On Mon, 6 Apr 2009, Bernd Speiser wrote:
After some more experimentation, I seem to have found the solution:
I need to place `-L/usr/lib64 -L/usr/lib' in the LDFLAGS variable of the
program to be built. Then, I get the expected behavior (libraries in
/usr/lib do not interfere with those in /usr/
After some more experimentation, I seem to have found the solution:
I need to place `-L/usr/lib64 -L/usr/lib' in the LDFLAGS variable of the
program to be built. Then, I get the expected behavior (libraries in
/usr/lib do not interfere with those in /usr/lib64).
Thanks for helping.
Regards
Bernd
Bernd Speiser wrote:
Bob Friesenhahn wrote:
I expect that the problem is that a .la file loaded via the linking
search path refers to this /usr/lib/libXfixes.la file which does not
exist (because it was deleted or never was installed). The .la files
are just ASCII text files that you can ope
On Sun, 5 Apr 2009, Bernd Speiser wrote:
thanks for this info. 1.5.26 is the default for openSUSE 11.0. However, I
have installed libtool version 2.2.6 on my system now.
With this, after regeneration of of the aclocal.m4 files, I still get an
error message, although a different one:
libtool: l
Bob Friesenhahn wrote:
On Fri, 3 Apr 2009, Bernd Speiser wrote:
I am using autotools on openSUSE 11.0 x86_64 where I have a couple of
libraries (notably the X libraries) installed as both 32 and 64 bit
versions. I seem to have a problem which has been discussed several
times on this list (lib
On Fri, 3 Apr 2009, Bernd Speiser wrote:
I am using autotools on openSUSE 11.0 x86_64 where I have a couple of
libraries (notably the X libraries) installed as both 32 and 64 bit versions.
I seem to have a problem which has been discussed several times on this list
(libtool tries to link the 3
19 matches
Mail list logo
