makefile with "ln"
John Small
into a problem with a certain part of a certain makefile.
The relevant portion of the makefile:
libboinc_api.a: libboinc_api.la
rm -f libboinc_api.a
ln .libs/libboinc_api.a
The errors I get are:
rm -f libboinc_api.a
ln .libs/libboinc_api.a
ln: accessing `.libs/libboinc_api.a': No such file or directory
My questions:
1) What is "ln .libs/libboinc_api.a" trying to do?
2) What would be needed in order for "ln .libs/libboinc_api.a" to
succeed? (.libs is a valid subdirectory but there is no
"libboinc_api.a" in that directory. There are, however,
"libboinc_api.la" and "libboinc_api.lai" files in that directory.)
3) Do I need TVFS for this to work?
4) If I can't make the existing makefile work, are there any
workarounds that I can use?
Thanks for your help!
--
John Small
Dave Yeo
> In my continuing efforts to port the latest Boinc source, I have run
> into a problem with a certain part of a certain makefile.
>
> The relevant portion of the makefile:
>
> libboinc_api.a: libboinc_api.la
> rm -f libboinc_api.a
> ln .libs/libboinc_api.a
>
> The errors I get are:
>
> rm -f libboinc_api.a
> ln .libs/libboinc_api.a
> ln: accessing `.libs/libboinc_api.a': No such file or directory
>
> My questions:
> 1) What is "ln .libs/libboinc_api.a" trying to do?
I:\usr\local\bin>ln --help
Usage: I:\usr\local\bin\ln.exe [OPTION]... [-T] TARGET LINK_NAME (1st
form)
or: I:\usr\local\bin\ln.exe [OPTION]... TARGET (2nd
form)
or: I:\usr\local\bin\ln.exe [OPTION]... TARGET... DIRECTORY (3rd
form)
or: I:\usr\local\bin\ln.exe [OPTION]... -t DIRECTORY TARGET... (4th
form)
In the 1st form, create a link to TARGET with the name LINK_NAME.
In the 2nd form, create a link to TARGET in the current directory.
In the 3rd and 4th forms, create links to each TARGET in DIRECTORY.
Create hard links by default, symbolic links with --symbolic.
When creating hard links, each TARGET must exist.
So trying to create a link named ./libboinc_api.a to .libs/libboinc.a
> 2) What would be needed in order for "ln .libs/libboinc_api.a" to
> succeed? (.libs is a valid subdirectory but there is no
> "libboinc_api.a" in that directory. There are, however,
> "libboinc_api.la" and "libboinc_api.lai" files in that directory.)
You need to use cp instead of ln and I think you need both the source
and target names eg cp .libs/libboinc.a libboinc.a.
Looks like they're only part way to switching to libtool. Usually
configure checks for ln -s and falls back to cp -f. Randomly looking
around I see things like
# AC_LIBTOOL_SETUP
# ----------------
AC_DEFUN([AC_LIBTOOL_SETUP],
[AC_PREREQ(2.50)dnl
...
AC_REQUIRE([AC_PROG_LN_S])dnl
in aclocal.m4 and $(LN_S) in makefiles with $LN_S being defined to
either ln -s or cp -f.
You are going to have to hack the makefile or read up on how to set up
AC_PROG_LN_S and add it where ever it needs it. This might mean
rewriting makefile.am. Probably need to look at the automake docs,
perhaps libtool or autoconf docs.
> 3) Do I need TVFS for this to work?
The only file system I know of that supports hard links on OS/2 is
ext2fs. klibc supports symlinks or just use cp.
> 4) If I can't make the existing makefile work, are there any
> workarounds that I can use?
I'd just hack the makefile or better makefile.am and rerun automake etc
>
> Thanks for your help!
>
Dave
John Small
wrote:
> On 01/28/09 10:29 am, John Small wrote:
> > In my continuing efforts to port the latest Boinc source, I have run
> > into a problem with a certain part of a certain makefile.
> >
> > The relevant portion of the makefile:
> >
> > libboinc_api.a: libboinc_api.la
> > rm -f libboinc_api.a
> > ln .libs/libboinc_api.a
> >
> > The errors I get are:
> >
> > rm -f libboinc_api.a
> > ln .libs/libboinc_api.a
> > ln: accessing `.libs/libboinc_api.a': No such file or directory
> >
> > My questions:
> > 1) What is "ln .libs/libboinc_api.a" trying to do?
> ...
> Create hard links by default, symbolic links with --symbolic.
> When creating hard links, each TARGET must exist.
I'm unclear about the differences between hard links and symbolic
links.
> So trying to create a link named ./libboinc_api.a to .libs/libboinc.a
But, as the error message indicates, there is no .libs/libboinc.a
file.
The dependency rule suggests that libboinc_api.a depends on
libboinc_api.la. But libboinc_api.la is not referenced in the
statements that follow. Is there, perhaps, a statement missing? Or
maybe the ln command should link libboinc_api.a to libboinc_api.la? Or
is there some command to turn a .la file into a .a file?
> > 2) What would be needed in order for "ln .libs/libboinc_api.a" to
> > succeed? (.libs is a valid subdirectory but there is no
> > "libboinc_api.a" in that directory. There are, however,
> > "libboinc_api.la" and "libboinc_api.lai" files in that directory.)
>
> You need to use cp instead of ln and I think you need both the source
> and target names eg cp .libs/libboinc.a libboinc.a.
Again, there is no .libs/libboinc_api.a file. So I would think the cp
would fail also.
> Looks like they're only part way to switching to libtool. Usually
> configure checks for ln -s and falls back to cp -f. Randomly looking
> around I see things like
> # AC_LIBTOOL_SETUP
> # ----------------
> AC_DEFUN([AC_LIBTOOL_SETUP],
> [AC_PREREQ(2.50)dnl
>
> ...
>
> AC_REQUIRE([AC_PROG_LN_S])dnl
>
> in aclocal.m4 and $(LN_S) in makefiles with $LN_S being defined to
> either ln -s or cp -f.
How/where do you learn about all this? If I understood more of all
this I would not need so much help (and I'd be a little more
productive in my porting efforts).
> You are going to have to hack the makefile or read up on how to set up
> AC_PROG_LN_S and add it where ever it needs it. This might mean
> rewriting makefile.am.
Is *LN_S what I need to change? The makefile does not use "-s".
> ... Probably need to look at the automake docs,
> perhaps libtool or autoconf docs.
What docs? Are you talking about info pages? If yes, is there a better
program than info to read these pages? I find info hard to work with.
Thanks for all your help, Dave!!
--
John Small
Dave Yeo
> On Wed, 28 Jan 2009 20:28:21 UTC, Dave Yeo<dave....@gmail.com>
> wrote:
>
>> On 01/28/09 10:29 am, John Small wrote:
>>> In my continuing efforts to port the latest Boinc source, I have run
>>> into a problem with a certain part of a certain makefile.
>>>
>>> The relevant portion of the makefile:
>>>
>>> libboinc_api.a: libboinc_api.la
>>> rm -f libboinc_api.a
>>> ln .libs/libboinc_api.a
>>>
>>> The errors I get are:
>>>
>>> rm -f libboinc_api.a
>>> ln .libs/libboinc_api.a
>>> ln: accessing `.libs/libboinc_api.a': No such file or directory
>>>
>>> My questions:
>>> 1) What is "ln .libs/libboinc_api.a" trying to do?
>> ...
>> Create hard links by default, symbolic links with --symbolic.
>> When creating hard links, each TARGET must exist.
>
> I'm unclear about the differences between hard links and symbolic
> links.
A hard link is when you have 2 or more directory entries pointing to the
same file (actually a bit more complicated) so create foo, link bar to
foo and all changes to foo also happen to bar as it is physically the
same file. Delete foo and bar still exists.
A symbolic link is just a pointer, create foo, symlink bar to foo and
they appear to be the same file. Delete foo and bar becomes a broken
dangling symlink pointing nowhere.
Both KLIBC and Linux support symlinks on HPFS by creating an EA
containing the name of the real file. KLIBC works the same way with
other file systems like JFS. Linux creates true symlinks and hardlinks
on JFS.
Symlinks can exist across file systems (partitions) while hard links
have to be on the same file system.
>
>> So trying to create a link named ./libboinc_api.a to .libs/libboinc.a
>
> But, as the error message indicates, there is no .libs/libboinc.a
> file.
I probably got it backwards :) Don't use ln enough
>
> The dependency rule suggests that libboinc_api.a depends on
> libboinc_api.la. But libboinc_api.la is not referenced in the
> statements that follow. Is there, perhaps, a statement missing? Or
> maybe the ln command should link libboinc_api.a to libboinc_api.la? Or
> is there some command to turn a .la file into a .a file?
>
>>> 2) What would be needed in order for "ln .libs/libboinc_api.a" to
>>> succeed? (.libs is a valid subdirectory but there is no
>>> "libboinc_api.a" in that directory. There are, however,
>>> "libboinc_api.la" and "libboinc_api.lai" files in that directory.)
>> You need to use cp instead of ln and I think you need both the source
>> and target names eg cp .libs/libboinc.a libboinc.a.
>
> Again, there is no .libs/libboinc_api.a file. So I would think the cp
> would fail also.
I'm probably backwards. Getting forgetful in my old age :)
>
>> Looks like they're only part way to switching to libtool. Usually
>> configure checks for ln -s and falls back to cp -f. Randomly looking
>> around I see things like
>> # AC_LIBTOOL_SETUP
>> # ----------------
>> AC_DEFUN([AC_LIBTOOL_SETUP],
>> [AC_PREREQ(2.50)dnl
>>
>> ...
>>
>> AC_REQUIRE([AC_PROG_LN_S])dnl
>>
>> in aclocal.m4 and $(LN_S) in makefiles with $LN_S being defined to
>> either ln -s or cp -f.
>
> How/where do you learn about all this? If I understood more of all
> this I would not need so much help (and I'd be a little more
> productive in my porting efforts).
I've been fiddling with porting various things for probably 10+ years
now. It used to be a lot harder to get configure scripts etc to run
correctly on OS/2. Luckily between some knowledgeable people getting
fixes in for the auto tools and the prevalence of Windows which works
the same way for lots of things it has become much easier.
>
>> You are going to have to hack the makefile or read up on how to set up
>> AC_PROG_LN_S and add it where ever it needs it. This might mean
>> rewriting makefile.am.
>
> Is *LN_S what I need to change? The makefile does not use "-s".
>
>> ... Probably need to look at the automake docs,
>> perhaps libtool or autoconf docs.
>
> What docs? Are you talking about info pages? If yes, is there a better
> program than info to read these pages? I find info hard to work with.
If you have the source texi files you can convert them to HTML with
texi2html (perl script) or at
http://hobbes.nmsu.edu/h-browse.php?dir=/pub/os2/apps/wp/tex/util there
are a couple of texi to inf converters that you could try.
There's also probably HTML versions on line at gnu.org.
>
> Thanks for all your help, Dave!!
>
Dave
Trevor Hemsley
<dave....@gmail.com> wrote:
> A hard link is when you have 2 or more directory entries pointing to the
> same file (actually a bit more complicated) so create foo, link bar to
> foo and all changes to foo also happen to bar as it is physically the
> same file. Delete foo and bar still exists.
On all the *ix systems I have used, a hard linked file will copy-on-write to a
separate file - so in your example above, create foo, link bar to foo then any
change to either file will result in the creation of two separate files with
different content.
--
Trevor Hemsley, Brighton, UK
Trevor dot Hemsley at ntlworld dot com
Dave Yeo
> On Thu, 29 Jan 2009 00:14:27 UTC in comp.os.os2.programmer.porting, Dave Yeo
> <dave....@gmail.com> wrote:
>
>> A hard link is when you have 2 or more directory entries pointing to the
>> same file (actually a bit more complicated) so create foo, link bar to
>> foo and all changes to foo also happen to bar as it is physically the
>> same file. Delete foo and bar still exists.
>
> On all the *ix systems I have used, a hard linked file will copy-on-write to a
> separate file - so in your example above, create foo, link bar to foo then any
> change to either file will result in the creation of two separate files with
> different content.
>
Well testing with an ext3 filesystem results in
dsl@box:~$ touch foo
dsl@box:~$ echo test1 > foo
dsl@box:~$ cat foo
test1
dsl@box:~$ ln foo bar
dsl@box:~$ cat bar
test1
dsl@box:~$ echo test2 >> foo
dsl@box:~$ echo test3 >> bar
dsl@box:~$ cat foo
test1
test2
test3
dsl@box:~$ cat bar
test1
test2
test3
dsl@box:~$
And from official description of the Unix link() function,
http://www.opengroup.org/onlinepubs/009695399/functions/link.html
The link() function shall create a new link (directory entry) for the
existing file, path1.
Dave
John Small
wrote:
> On 01/28/09 02:42 pm, John Small wrote:
> > On Wed, 28 Jan 2009 20:28:21 UTC, Dave Yeo<dave....@gmail.com>
> > wrote:
> >
> >> On 01/28/09 10:29 am, John Small wrote:
> >>> In my continuing efforts to port the latest Boinc source, I have run
> >>> into a problem with a certain part of a certain makefile.
> >>>
> >>> The relevant portion of the makefile:
> >>>
> >>> libboinc_api.a: libboinc_api.la
> >>> rm -f libboinc_api.a
> >>> ln .libs/libboinc_api.a
> >>>
> >>> The errors I get are:
> >>>
> >>> rm -f libboinc_api.a
> >>> ln .libs/libboinc_api.a
> >>> ln: accessing `.libs/libboinc_api.a': No such file or directory
As much as I've learned in this thread (and I am genuinely thankful
for the help!), I am still left the the original dilemma: the ln
command fails because the file ".libs\libboinc_api.a" does not exist.
And if I am able to change this to a cp command, it will fail, too,
because this file is missing.
So it seems I need to figure out why there is no
".libs\libboinc_api.a" file. Please correct me if I am wrong.
Unfortunately, after grepping on "libboinc_api", the code above is the
only place I have been able to find the file referenced as a build
target in any of the makefile, makefile.in or makefile.am files.
Any ideas? Can a .a file be built as a side effect of something else?
Should I grep on some other string?
TIA.
--
John Small
Dave Yeo
Is there no libboinc_api.a built in lib ? Can you cd into boinc/lib and
do a make clean, make 2>&1 build.log and post the last dozen or so lines
Dave
John Small
wrote:
There is no libboinc_api.a anywhere.
> Can you cd into boinc/lib and
> do a make clean, make 2>&1 build.log and post the last dozen or so lines
The current/working directory in question is the api directory (and
the ,libs subdirectory of api).
I did a make clean in the api directory followed by make >build.log
2>&1. Build log is only 28 lines so I'll post the whole thing:
if ash.exe ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I.
-I. -I.. -I../lib -I../api -I../db -I../client -I../tools -I../sched
-I../lib/mac -I/curl/include -D__EMX__ -DOS2 -D__ST_MT_ERRNO__ -O3
-mcpu=pentium3 -MT boinc_api.lo -MD -MP -MF ".deps/boinc_api.Tpo" -c
-o boinc_api.lo boinc_api.cpp; \
then mv -f ".deps/boinc_api.Tpo" ".deps/boinc_api.Plo"; else rm -f
".deps/boinc_api.Tpo"; exit 1; fi
libtool: ignoring unknown tag CXX
mkdir .libs
g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../lib -I../api -I../db
-I../client -I../tools -I../sched -I../lib/mac -I/curl/include
-D__EMX__ -DOS2 -D__ST_MT_ERRNO__ -O3 -mcpu=pentium3 -MT boinc_api.lo
-MD -MP -MF .deps/boinc_api.Tpo -c boinc_api.cpp -DDLL_EXPORT -DPIC
-o .libs/boinc_api.o
g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../lib -I../api -I../db
-I../client -I../tools -I../sched -I../lib/mac -I/curl/include
-D__EMX__ -DOS2 -D__ST_MT_ERRNO__ -O3 -mcpu=pentium3 -MT boinc_api.lo
-MD -MP -MF .deps/boinc_api.Tpo -c boinc_api.cpp -o boinc_api.o
>/dev/null 2>&1
if ash.exe ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I.
-I. -I.. -I../lib -I../api -I../db -I../client -I../tools -I../sched
-I../lib/mac -I/curl/include -D__EMX__ -DOS2 -D__ST_MT_ERRNO__ -O3
-mcpu=pentium3 -MT reduce_main.lo -MD -MP -MF ".deps/reduce_main.Tpo"
-c -o reduce_main.lo reduce_main.cpp; \
then mv -f ".deps/reduce_main.Tpo" ".deps/reduce_main.Plo"; else rm
-f ".deps/reduce_main.Tpo"; exit 1; fi
libtool: ignoring unknown tag CXX
g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../lib -I../api -I../db
-I../client -I../tools -I../sched -I../lib/mac -I/curl/include
-D__EMX__ -DOS2 -D__ST_MT_ERRNO__ -O3 -mcpu=pentium3 -MT
reduce_main.lo -MD -MP -MF .deps/reduce_main.Tpo -c reduce_main.cpp
-DDLL_EXPORT -DPIC -o .libs/reduce_main.o
g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../lib -I../api -I../db
-I../client -I../tools -I../sched -I../lib/mac -I/curl/include
-D__EMX__ -DOS2 -D__ST_MT_ERRNO__ -O3 -mcpu=pentium3 -MT
reduce_main.lo -MD -MP -MF .deps/reduce_main.Tpo -c reduce_main.cpp -o
reduce_main.o >/dev/null 2>&1
if ash.exe ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I.
-I. -I.. -I../lib -I../api -I../db -I../client -I../tools -I../sched
-I../lib/mac -I/curl/include -D__EMX__ -DOS2 -D__ST_MT_ERRNO__ -O3
-mcpu=pentium3 -MT graphics2_util.lo -MD -MP -MF
".deps/graphics2_util.Tpo" -c -o graphics2_util.lo graphics2_util.cpp;
\
then mv -f ".deps/graphics2_util.Tpo" ".deps/graphics2_util.Plo";
else rm -f ".deps/graphics2_util.Tpo"; exit 1; fi
libtool: ignoring unknown tag CXX
g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../lib -I../api -I../db
-I../client -I../tools -I../sched -I../lib/mac -I/curl/include
-D__EMX__ -DOS2 -D__ST_MT_ERRNO__ -O3 -mcpu=pentium3 -MT
graphics2_util.lo -MD -MP -MF .deps/graphics2_util.Tpo -c
graphics2_util.cpp -DDLL_EXPORT -DPIC -o .libs/graphics2_util.o
g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../lib -I../api -I../db
-I../client -I../tools -I../sched -I../lib/mac -I/curl/include
-D__EMX__ -DOS2 -D__ST_MT_ERRNO__ -O3 -mcpu=pentium3 -MT
graphics2_util.lo -MD -MP -MF .deps/graphics2_util.Tpo -c
graphics2_util.cpp -o graphics2_util.o >/dev/null 2>&1
ash.exe ../libtool --tag=CXX --mode=link g++ -D__EMX__ -DOS2
-D__ST_MT_ERRNO__ -O3 -mcpu=pentium3 -Zexe -Zomf -Zmap -Zargs-wild
-D__ST_MT_ERRNO__ -s -o libboinc_api.la -rpath /usr/local/lib
-L/usr/local/lib -rpath /usr/local/lib -version-number 6:7:0
boinc_api.lo reduce_main.lo graphics2_util.lo
libtool: ignoring unknown tag CXX
libtool: link: warning: undefined symbols not allowed in i386-pc-os2
shared libraries
ar.exe cru .libs/boinc_api.a boinc_api.o reduce_main.o
graphics2_util.o
echo .libs/boinc_api.a
.libs/boinc_api.a
creating libboinc_api.la
(cd .libs && rm -f libboinc_api.la && ln -s ../libboinc_api.la
libboinc_api.la)
rm -f libboinc_api.a
ln .libs/libboinc_api.a
ln: accessing `.libs/libboinc_api.a': No such file or directory
make: *** [libboinc_api.a] Error 1
--
John Small
Dave Yeo
> ar.exe cru .libs/boinc_api.a boinc_api.o reduce_main.o
> graphics2_util.o
> echo .libs/boinc_api.a
> .libs/boinc_api.a
> creating libboinc_api.la
> libboinc_api.la)
> rm -f libboinc_api.a
> ln .libs/libboinc_api.a
> ln: accessing `.libs/libboinc_api.a': No such file or directory
> make: *** [libboinc_api.a] Error 1
>
Ok, the top line starting with ar.exe creates the static lib. The
libtool you are using drops the lib prefix so creates boinc_api.a
instead of libboinc_api.a. EMX didn't use the lib prefix (FAT
compatibility).
Easiest fix is change the rm -f line to rm -f boinc_api.a and the ln
line to cp -f .libs/boinc_api. ./.
Even better would be to use $LN_S and have configure decide whether to
use ln -s or cp.
If you change it in makefile.am and run automake and autoconf it will be
a permanent change.
Also libtool could be changed to output library names with the lib
prefix as even EMX was fixed to handle libraries both with the lib
prefix and without.
KLIBC also excepts the _s.a suffix to signify a static lib and _dll.a
for an import lib.
Dave
ps you might get a shared lib by adding -no-undefined to LDFLAGS
pps there might be other references to libboinc_api.a that need changed
John Small
wrote:
> On 01/29/09 05:25 pm, John Small wrote:
> > ar.exe cru .libs/boinc_api.a boinc_api.o reduce_main.o
> > graphics2_util.o
> > echo .libs/boinc_api.a
> > .libs/boinc_api.a
> > creating libboinc_api.la
> > (cd .libs&& rm -f libboinc_api.la&& ln -s ../libboinc_api.la
> > libboinc_api.la)
> > rm -f libboinc_api.a
> > ln .libs/libboinc_api.a
> > ln: accessing `.libs/libboinc_api.a': No such file or directory
> > make: *** [libboinc_api.a] Error 1
> >
>
> Ok, the top line starting with ar.exe creates the static lib. The
> libtool you are using drops the lib prefix so creates boinc_api.a
> instead of libboinc_api.a. EMX didn't use the lib prefix (FAT
> compatibility).
> Easiest fix is change the rm -f line to rm -f boinc_api.a and the ln
> line to cp -f .libs/boinc_api. ./.
> Even better would be to use $LN_S and have configure decide whether to
> use ln -s or cp.
Would using $LN_S make any difference? The makefile ln commands which
are failing are not using "-s". And, as I understand it, ln defaults
to hard links not symbolic, "-s", links.
Is there such a thing as $LN?
> Also libtool could be changed to output library names with the lib
> prefix as even EMX was fixed to handle libraries both with the lib
> prefix and without.
I think this route may be best. I'll dig into the libtool docs to see
how to do this.
Thanks again for all your help!!
--
John Small
Dave Yeo
>> Easiest fix is change the rm -f line to rm -f boinc_api.a and the ln
>> > line to cp -f .libs/boinc_api. ./.
>> > Even better would be to use $LN_S and have configure decide whether to
>> > use ln -s or cp.
>
> Would using $LN_S make any difference? The makefile ln commands which
> are failing are not using "-s". And, as I understand it, ln defaults
> to hard links not symbolic, "-s", links.
>
> Is there such a thing as $LN?
It seems to me that $LN_S is more portable. Operating Systems like OS/2
and perhaps some Win NT environments support symbolic links better then
hard links. Also same with file systems, if you booted into Linux and
tried compiling boinc on HPFS it would fail due to the lack of hard link
support. Also there is already an M4 macro for setting $LN_S to ln -s or
cp depending on the capabilities of the OS and/or filesystem so
configure can set it appropriately.
Don't ever remember seeing a reference to $LN
>
>> > Also libtool could be changed to output library names with the lib
>> > prefix as even EMX was fixed to handle libraries both with the lib
>> > prefix and without.
>
> I think this route may be best. I'll dig into the libtool docs to see
> how to do this.
Usually the references to things like static libs are represented by
variables and I can't remember running into this issue before.
>
> Thanks again for all your help!!
>
Dave
John Small
wrote:
> On 01/30/09 05:17 pm, John Small wrote:
> >> Easiest fix is change the rm -f line to rm -f boinc_api.a and the ln
> >> > line to cp -f .libs/boinc_api. ./.
> >> > Even better would be to use $LN_S and have configure decide whether to
> >> > use ln -s or cp.
> >
> > Would using $LN_S make any difference? The makefile ln commands which
> > are failing are not using "-s". And, as I understand it, ln defaults
> > to hard links not symbolic, "-s", links.
> >
> > Is there such a thing as $LN?
>
> It seems to me that $LN_S is more portable.
That may be. But will modifying $LN_S have any impact if the makefiles
being built are not using "ln -s"?
Also keep in mind that the bigger problem is not ln vs cp. Either
command will fail because the file in question does not exist. I have
a boinc_api.a file, not libboinc_api.a file.
It seems that I need to make changes so that:
a) libboinc_api.a is created (instead of or in addition to
boinc_api.a); or
b) the build process expects and is able to use the boinc_api.a file
that it is currently creating.
> > Thanks again for all your help!!
--
John Small
Dave Yeo
Looking at
http://boinc.berkeley.edu/trac/browser/trunk/boinc/api/Makefile.am and
reading the libtool manual, http://www.gnu.org/software/libtool/manual/
in particular
http://www.gnu.org/software/libtool/manual/html_node/Using-Automake.html#Using-Automake
I think really the problem is that the rule for all_local needs to
removed. Basically removing lines 54 to 70. This should enable building
libboinc_api.la which will point to the correct library.
Then some other variables may need to be added to stop the library from
being installed if I read it correctly, noinst_LTLIBRARIES.
There also probably will need other changes in various makefile.am to
use libboinc_api.la instead of libboinc_api.a
Dave
ps don't forget after editing makefile.am you need to run the autotools
again
John Small
wrote:
libboinc_api.la is already being built.
> Then some other variables may need to be added to stop the library from
> being installed if I read it correctly, noinst_LTLIBRARIES.
> There also probably will need other changes in various makefile.am to
> use libboinc_api.la instead of libboinc_api.a
I'll keep reading the libtool docs to see if I can figure this out.
--
John Small
Dave Yeo
>> I think really the problem is that the rule for all_local needs to
>> > removed. Basically removing lines 54 to 70. This should enable building
>> > libboinc_api.la which will point to the correct library.
>
> libboinc_api.la is already being built.
Yes, but the problem is the make rule then manipulates libboinc_api.a
when it should just leave it where it is built and link against
libboinc_api.la using libtool
>
>> > Then some other variables may need to be added to stop the library from
>> > being installed if I read it correctly, noinst_LTLIBRARIES.
>> > There also probably will need other changes in various makefile.am to
>> > use libboinc_api.la instead of libboinc_api.a
>
> I'll keep reading the libtool docs to see if I can figure this out.
>
Dave
John Small
wrote:
> On 01/31/09 05:01 pm, John Small wrote:
> >> I think really the problem is that the rule for all_local needs to
> >> > removed. Basically removing lines 54 to 70. This should enable building
> >> > libboinc_api.la which will point to the correct library.
> >
> > libboinc_api.la is already being built.
>
> Yes, but the problem is the make rule then manipulates libboinc_api.a
> when it should just leave it where it is built and link against
> libboinc_api.la using libtool
I have not yet had a "libboinc_api.a" file built. This is why the "ln"
fails.
--
John Small
KO Myung-Hun
How about trying libtool 1.5.26 in hobbes ?
--
KO Myung-Hun
Using Mozilla SeaMonkey 1.1.14
Under OS/2 Warp 4 for Korean with FixPak #15
On AMD ThunderBird 1 GHz with 512 MB RAM
Korean OS/2 User Community : http://www.ecomstation.co.kr
John Small
wrote:
> Hi/2.
>
> John Small wrote:
> > On Sun, 1 Feb 2009 01:07:00 UTC, Dave Yeo <dave....@gmail.com>
> > wrote:
> >
> >
> >> On 01/31/09 05:01 pm, John Small wrote:
> >>
> >>>> I think really the problem is that the rule for all_local needs to
> >>>>
> >>>>> removed. Basically removing lines 54 to 70. This should enable building
> >>>>> libboinc_api.la which will point to the correct library.
> >>>>>
> >>> libboinc_api.la is already being built.
> >>>
> >> Yes, but the problem is the make rule then manipulates libboinc_api.a
> >> when it should just leave it where it is built and link against
> >> libboinc_api.la using libtool
> >>
> >
> > I have not yet had a "libboinc_api.a" file built. This is why the "ln"
> > fails.
> >
> >
>
> How about trying libtool 1.5.26 in hobbes ?
I think I am using that libtool. If I run
sh libtool --version
I get
ltmain.sh (GNU libtool) 1.5.26 (1.1220.2.493 2008/02/01 16:58:18)
--
John Small
KO Myung-Hun
Did you run 'libtoolize -f' ?
And can you attach your 'config.log' ?
Dave Yeo
>>>> I have not yet had a "libboinc_api.a" file built. This is why the "ln"
>>>> fails.
>>>>
>>> How about trying libtool 1.5.26 in hobbes ?
>>
>> I think I am using that libtool. If I run
>> sh libtool --version
>> I get
>> ltmain.sh (GNU libtool) 1.5.26 (1.1220.2.493 2008/02/01 16:58:18)
>>
>
> Did you run 'libtoolize -f' ?
>
> And can you attach your 'config.log' ?
Your port of Libtool does not add the lib prefix.
Dave
Dave Yeo
The problem is that they are transitioning to libtool and haven't
finished, so the ln command is probably left over from before they used
libtool. Really there is no reason that they can't link to the lib that
is created in .lib and the proper libtool way is to use link against the
la file.
If you look at libboinc_api.la it should be basically a pointer the real
library. In this case boinc_api.a.
Also with klibc -lboinc_api will work with libboinc_api.a or boinc_api.a
(also _s.a and _dll.a)
Dave
KO Myung-Hun
And don't use 'ln -s', too.
KO Myung-Hun
John Small wrote:
> ar.exe cru .libs/boinc_api.a boinc_api.o reduce_main.o
> graphics2_util.o
> echo .libs/boinc_api.a
> .libs/boinc_api.a
> creating libboinc_api.la
> (cd .libs && rm -f libboinc_api.la && ln -s ../libboinc_api.la
> libboinc_api.la)
> rm -f libboinc_api.a
> ln .libs/libboinc_api.a
> ln: accessing `.libs/libboinc_api.a': No such file or directory
> make: *** [libboinc_api.a] Error 1
>
>
I looked at api/Makefile.am.
-----
libboinc_api.a: libboinc_api.la
rm -f libboinc_api.a
ln .libs/libboinc_api.a
libboinc_graphics2.a: libboinc_graphics2.la
rm -f libboinc_graphics2.a
ln .libs/libboinc_graphics2.a
-----
Your logs say that boinc_api.a in .libs created successfully. But build
system of BOINC assume that the name of the created library has a 'lib'
prefix. It's not true for libtool for OS/2.
And 'ln TARGET' form is not supported on OS/2, I know. From help
message, it means 'create a link to TARGET in the current directory'. If
trying that, it reports 'Function not implemented'. I'm using 'ln (GNU
coreutils) 5.94'.
You should replace that ln parts with 'cp .libs/boinc_api.a
libboinc_api.a'. So does boinc_graphics2.a.
This is a build system bug of BOINC due to incompleted transition to
libtool as David said.
Finally, you should use coreutils supporting symbolic link, i.e.,
compiled by kLIBC to get the correct result. Or use libtool on hobbes
and launch 'libtoolize -f' that use 'cp -f' instead of 'ln -s'.
John Small
wrote:
> Hi/2.
By this, do you mean:
<ftp://ftp.netlabs.org/pub/gcc/GCC-3.3.5-csd3.zip>?
If yes,
1) I have been using Paul Smedley's build environment. Is it OK to
unzip this file over this Paul's environment? Would doing so break or
fundamentally alter Paul's environment?
2) Do I then start using the usr/bin/gccenv.cmd contained in
<ftp://ftp.netlabs.org/pub/gcc/GCC-3.3.5-csd3.zip> instead of Paul's
gcc335.cmd?
3) In the usr/doc/gcc-3.3.5/install.os2 file within
<ftp://ftp.netlabs.org/pub/gcc/GCC-3.3.5-csd3.zip> it says: "If you
wanna use -Zomf you should check the usage output from emxomfld
carefully, cause additional environment setup might be required."
Could someone expand on this? What should I look for? What envrionment
settings might need adjustment?
Dave Yeo
> By this, do you mean:
> <ftp://ftp.netlabs.org/pub/gcc/GCC-3.3.5-csd3.zip>?
>
> If yes,
> 1) I have been using Paul Smedley's build environment. Is it OK to
> unzip this file over this Paul's environment? Would doing so break or
> fundamentally alter Paul's environment?
Paul's build environment should be based on the KLIBC environment. Take
a look in /usr/docs/GCC-3.3.5
Dave
Dave
John Small
wrote:
On further inspection, there is almost nothing in
<ftp://ftp.netlabs.org/pub/gcc/GCC-3.3.5-csd3.zip> that is newer than
what I have on my U: (Paul's build envrionment).
So where to I find "coreutils supporting symbolic link, i.e., compiled
by kLIBC to get the correct result".
Dave Yeo
> On further inspection, there is almost nothing in
> <ftp://ftp.netlabs.org/pub/gcc/GCC-3.3.5-csd3.zip> that is newer than
> what I have on my U: (Paul's build envrionment).
>
> So where to I find "coreutils supporting symbolic link, i.e., compiled
> by kLIBC to get the correct result".
>
ftp://ftp.netlabs.org/pub/gcc/alpha/coreutils-5.94.zip. Also IIRC also
Hobbes
Dave
Dave Yeo
Actually I'd be surprised if Paul doesn't already have a relatively up
to date coreutils in his enviroment
Dave
John Small
wrote:
> Hi/2.
Will do.
> This is a build system bug of BOINC due to incompleted transition to
> libtool as David said.
I agree that there is some bug. My config.log shows that configure
determines that hard links do not work but symbolic links do. Then it
proceeds to use hard links (i.e. ln TARGET) instead of symbolic links
(i.e. ln -s) in the makefiles anyway!?
> Finally, you should use coreutils supporting symbolic link, i.e.,
> compiled by kLIBC to get the correct result.
Disregard my earlier replies about these coreutils. I already have a
ln.exe which creates symbolic links.
--
John Small
John Small
wrote:
> On 01/29/09 05:25 pm, John Small wrote:
> > ar.exe cru .libs/boinc_api.a boinc_api.o reduce_main.o
> > graphics2_util.o
> > echo .libs/boinc_api.a
> > .libs/boinc_api.a
> > creating libboinc_api.la
> > (cd .libs&& rm -f libboinc_api.la&& ln -s ../libboinc_api.la
> > libboinc_api.la)
> > rm -f libboinc_api.a
> > ln .libs/libboinc_api.a
> > ln: accessing `.libs/libboinc_api.a': No such file or directory
> > make: *** [libboinc_api.a] Error 1
> >
>
> Ok, the top line starting with ar.exe creates the static lib. The
> libtool you are using drops the lib prefix so creates boinc_api.a
> instead of libboinc_api.a. EMX didn't use the lib prefix (FAT
> compatibility).
The "libtool I am using"? Is there a libtool I should be using? The
version I have says "ltmain.sh (GNU libtool) 1.5.26 (1.1220.2.493
2008/02/01 16:58:18)" in response to "sh libtool --version"
> Also libtool could be changed to output library names with the lib
> prefix as even EMX was fixed to handle libraries both with the lib
> prefix and without.
Changed in what way? Reprogrammed or re-configured? I seriously doubt
I could reprogram libtool. But I'd gladly try reconfiguring it if I
knew how this was done.
> ps you might get a shared lib by adding -no-undefined to LDFLAGS
Do I want shared libraries? I am using a script from the previous
porter which uses "--disable-shared" when running the configure
script.
Am I correct in thinking that a "shared library" is a DLL in OS/2
terms? And that a "static library" is a collection of functions which
is linked staticly into the executable (and not distributed)?
--
John Small
Dave Yeo
> On Fri, 30 Jan 2009 04:34:36 UTC, Dave Yeo<dave....@gmail.com>
> wrote:
>
>> On 01/29/09 05:25 pm, John Small wrote:
>>> ar.exe cru .libs/boinc_api.a boinc_api.o reduce_main.o
>>> graphics2_util.o
>>> echo .libs/boinc_api.a
>>> .libs/boinc_api.a
>>> creating libboinc_api.la
>>> (cd .libs&& rm -f libboinc_api.la&& ln -s ../libboinc_api.la
>>> libboinc_api.la)
>>> rm -f libboinc_api.a
>>> ln .libs/libboinc_api.a
>>> ln: accessing `.libs/libboinc_api.a': No such file or directory
>>> make: *** [libboinc_api.a] Error 1
>>>
>> Ok, the top line starting with ar.exe creates the static lib. The
>> libtool you are using drops the lib prefix so creates boinc_api.a
>> instead of libboinc_api.a. EMX didn't use the lib prefix (FAT
>> compatibility).
>
> The "libtool I am using"? Is there a libtool I should be using? The
> version I have says "ltmain.sh (GNU libtool) 1.5.26 (1.1220.2.493
> 2008/02/01 16:58:18)" in response to "sh libtool --version"
That is probably the one that you should be using. There are other older
versions around which have slightly different results. Before this one I
was using one that Knut ported which added the lib prefix.
And of course there is whatever libtool comes with the package.
>
>> Also libtool could be changed to output library names with the lib
>> prefix as even EMX was fixed to handle libraries both with the lib
>> prefix and without.
>
> Changed in what way? Reprogrammed or re-configured? I seriously doubt
> I could reprogram libtool. But I'd gladly try reconfiguring it if I
> knew how this was done.
Changing libtool is not for the faint of heart :) Usually it doesn't
really matter about the lib prefix as -lfoo will work with libfoo.a and
foo.a.
In your case you are dealing with makefiles that are migrating to
libtool and not quite right in a portable way. Personally I'd just hack
the makefile(.am) and get boinc to build. After you can think about
fixing the build system in a more portable way.
>
>> ps you might get a shared lib by adding -no-undefined to LDFLAGS
>
> Do I want shared libraries? I am using a script from the previous
> porter which uses "--disable-shared" when running the configure
> script.
You probably don't want a shared lib then, still it is interesting when
the auto tools actually build a DLL.
>
> Am I correct in thinking that a "shared library" is a DLL in OS/2
> terms? And that a "static library" is a collection of functions which
> is linked staticly into the executable (and not distributed)?
>
Yes, that is correct. Though in some cases the static lib is distributed.
Dave
John Small
wrote:
Yes, I noticed this. There are "libtool" and "ltmain.sh" files in the
main Boinc directory. Is it normal for software to provide there own
versions of these files?
Should I be concerned with differences between either of these files
and the corresponding ones I already had installed (elsewhere) on my
system?
Is is possible and would it be a good idea for me to tell Boinc (via
*.ac or *.am files or via environment variables or configure
parameters) to use the settings from my files instead?
--
John Small
Dave Yeo
>>> The "libtool I am using"? Is there a libtool I should be using? The
>>> > > version I have says "ltmain.sh (GNU libtool) 1.5.26 (1.1220.2.493
>>> > > 2008/02/01 16:58:18)" in response to "sh libtool --version"
>> >
>> > That is probably the one that you should be using. There are other older
>> > versions around which have slightly different results. Before this one I
>> > was using one that Knut ported which added the lib prefix.
>> > And of course there is whatever libtool comes with the package.
>
> Yes, I noticed this. There are "libtool" and "ltmain.sh" files in the
> main Boinc directory. Is it normal for software to provide there own
> versions of these files?
Usually releases come with their own versions of configure, libtool,
etc. If you download from cvs, svn etc you often have to generate them
yourself.
ltmain.sh is what generates libtool when configure is run.
>
> Should I be concerned with differences between either of these files
> and the corresponding ones I already had installed (elsewhere) on my
> system?
No, other then having a working version. A lot of the time the ones that
come with a package work fine with a little help from config.site.
>
> Is is possible and would it be a good idea for me to tell Boinc (via
> *.ac or *.am files or via environment variables or configure
> parameters) to use the settings from my files instead?
>
I'm not sure what you mean here.
Dave
John Small
wrote:
> On 02/12/09 02:21 am, John Small wrote:
> >>> The "libtool I am using"? Is there a libtool I should be using? The
> >>> > > version I have says "ltmain.sh (GNU libtool) 1.5.26 (1.1220.2.493
> >>> > > 2008/02/01 16:58:18)" in response to "sh libtool --version"
> >> >
> >> > That is probably the one that you should be using. There are other older
> >> > versions around which have slightly different results. Before this one I
> >> > was using one that Knut ported which added the lib prefix.
> >> > And of course there is whatever libtool comes with the package.
> >
> > Yes, I noticed this. There are "libtool" and "ltmain.sh" files in the
> > main Boinc directory. Is it normal for software to provide there own
> > versions of these files?
>
> Usually releases come with their own versions of configure, libtool,
> etc. If you download from cvs, svn etc you often have to generate them
> yourself.
> ltmain.sh is what generates libtool when configure is run.
>
> >
> > Should I be concerned with differences between either of these files
> > and the corresponding ones I already had installed (elsewhere) on my
> > system?
>
> No, other then having a working version. A lot of the time the ones that
> come with a package work fine with a little help from config.site.
Since I am having so much trouble building libraries I wonder if I
have "a working version".
"My" ltmain.sh has several sections of code which are specific to OS/2
while Boinc's ltmain.sh does not.
> > Is is possible and would it be a good idea for me to tell Boinc (via
> > *.ac or *.am files or via environment variables or configure
> > parameters) to use the settings from my files instead?
> >
>
> I'm not sure what you mean here.
There are dozens of assignment statements in the generated libtool
which assign different values than the ones assigned in "my" libtool.
(This includes variables as basic as "host". "My"
host=i386-pc-os2-emx. Boinc's host=i386-pc-os2.)
Also there are assignments in "my" libtool which are not even present
in Boinc's.
--
John Small
Dave Yeo
I think that you would find a lot of the values are close enough, eg
testing for *-os2* though I might be wrong.
Simplest is to test. I often compile without changing libtool and
usually it succeeds at creating a static lib. Lately when it creates a
DLL it goes the windows route creating the import lib which breaks the
compile.
For interest you can untar a fresh tarball, move your config.site out of
the way and try running configure and make.
You can set environment variables to fix failures, eg CC not found is
fixed by either set CC=gcc.exe or GCC=gcc.exe.
Dave
John Small
wrote:
When I try this, the configure script is not able to find programs on
the path. Apparently the "\b" of the bin directories is being
translated into a backspace. So path entries like U:\usr\bin turn into
U:\usr<backspace>in. (If I change the backslashes to forward slashes
the translation does not occur but configure still cannot find
programs on the path.)
Am I correct in thinking that the line:
PATH=`cmd.exe /c "echo %PATH%" | sed -e 's@\\\\@/@g'`
from %CONFIG_SITE% is critical.
Is there a way to simulate this without a CONFIG_SITE file? (I tried
running the line above in a sh shell and then running configure but it
did not solve the problem.)
--
John Small
Dave Yeo
>> For interest you can untar a fresh tarball, move your config.site out of
>> > the way and try running configure and make.
>> > You can set environment variables to fix failures, eg CC not found is
>> > fixed by either set CC=gcc.exe or GCC=gcc.exe.
>
> When I try this, the configure script is not able to find programs on
> the path. Apparently the "\b" of the bin directories is being
> translated into a backspace. So path entries like U:\usr\bin turn into
> U:\usr<backspace>in. (If I change the backslashes to forward slashes
> the translation does not occur but configure still cannot find
> programs on the path.)
>
> Am I correct in thinking that the line:
> PATH=`cmd.exe /c "echo %PATH%" | sed -e 's@\\\\@/@g'`
> from %CONFIG_SITE% is critical.
>
> Is there a way to simulate this without a CONFIG_SITE file? (I tried
> running the line above in a sh shell and then running configure but it
> did not solve the problem.)
>
It really seems to depend on the version of autoconf that originally
created configure. IIRC 2.59+ comes close to working out of the box.
I see the output where the \bin gets changed into a weird character but
often configure does find the program. It may also depend on the shell.
If configure seems to be lost in finding things then you can run
autoconf. Even that doesn't always work. I tried building wine out of
curiosity and the configure script failed bad and even after running
autoconf it still failed to find quite a few libraries that are usually
found. So it is really your mileage may vary.
I guess the PATH thing could be added directly to configure or you could
just create a minimal config.site.
Dave
John Small
wrote:
> On 02/14/09 12:17 pm, John Small wrote:
> >> For interest you can untar a fresh tarball, move your config.site out of
> >> > the way and try running configure and make.
> >> > You can set environment variables to fix failures, eg CC not found is
> >> > fixed by either set CC=gcc.exe or GCC=gcc.exe.
> >
> > When I try this, the configure script is not able to find programs on
> > the path. Apparently the "\b" of the bin directories is being
> > translated into a backspace. So path entries like U:\usr\bin turn into
> > U:\usr<backspace>in. (If I change the backslashes to forward slashes
> > the translation does not occur but configure still cannot find
> > programs on the path.)
> >
> > Am I correct in thinking that the line:
> > PATH=`cmd.exe /c "echo %PATH%" | sed -e 's@\\\\@/@g'`
> > from %CONFIG_SITE% is critical.
> >
> > Is there a way to simulate this without a CONFIG_SITE file? (I tried
> > running the line above in a sh shell and then running configure but it
> > did not solve the problem.)
> >
>
> It really seems to depend on the version of autoconf that originally
> created configure. IIRC 2.59+ comes close to working out of the box.
> I see the output where the \bin gets changed into a weird character but
> often configure does find the program. It may also depend on the shell.
When I run configure with %config_site% set I have no problems
completing the script.
> If configure seems to be lost in finding things then you can run
> autoconf.
Whenever I "restart" I
-- restore the source tree to it original state
-- run (a modified) _autosetup which, among other things, runs
autoconf
-- run configure
> I guess the PATH thing could be added directly to configure
Even if I modify the configure script by adding:
PATH=`cmd.exe /c "echo %PATH%" | sed -e 's@\\\\@/@g'`
PATH_SEPARATOR=';'
to it, it still fails to find programs on the PATH.
When I run configure with %config_site% set, the configure script runs
successfully.
> or you could just create a minimal config.site.
What would be required in a "minimal" %config_site%?
I have one with
PATH=`cmd.exe /c "echo %PATH%" | sed -e 's@\\\\@/@g'`
PATH_SEPARATOR=';'
and with the "test" function you sent me eariler. But it does not
help. The configure script still cannot find grep on the PATH.
--
John Small