php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #39187 libtool creates .o files in .libs subdir
Submitted: 2006-10-18 13:50 UTC Modified: 2006-10-19 12:26 UTC
From: lzsiga at freemail dot c3 dot hu Assigned:
Status: Not a bug Package: Compile Failure
PHP Version: 5.1.6 OS: AIX
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
48 - 14 = ?
Subscribe to this entry?

 
 [2006-10-18 13:50 UTC] lzsiga at freemail dot c3 dot hu
Description:
------------
I'm sorry to do such an unforgiveable thing, but I have to re-report an already closed (mis-closed) bug-report, as I have experienced the same problem and found the same workaround

See here: http://bugs.php.net/bug.php?id=38872

'tony2001@php.net' closed this report as 'bogus' but gave no clue how to solve it - the compilation uses the libtool attached to PHP-source.

Note: I do not know where libtool is supposed to create 'foo.o' compiling 'foo.c' to 'foo.lo' but actually on AIX creates '.lib/foo.o' whilst on linux creates both 'foo.o' and 'foo.o'.



Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-10-18 13:52 UTC] lzsiga at freemail dot c3 dot hu
I mean: creates both 'foo.o' and '.libs/foo.o'.
 [2006-10-18 13:54 UTC] tony2001@php.net
That's because you mis-read the report.
Use GNU compiler and GNU binutils, this way it works perfectly fine. Native tools are broken and we do not support them.
 [2006-10-18 14:18 UTC] lzsiga at freemail dot c3 dot hu
Help me a bit, please. You mean gcc (which I am using too) is supposed to copy the object modul into a directory which was not specified in its command line, or 'nm' is supposed to handle an object module, which does not exist in the given location but in the .libs subdirectory?
(Or in the simplest way then question is where *.o supposed to be created by libtool?)

(Note: According to 'truss', libtool calls gcc with:
execve("/usr/local/bin/gcc", "gcc", "-Iext/libxml/",... "/usr/local/src/php-5.1.6/ext/libxml/libxml.c", "-DPIC", "-o", "ext/libxml/.libs/libxml.o")
 [2006-10-18 14:26 UTC] tony2001@php.net
It is supposed to work with GNU ld (which is a part of GNU binutils), just like it does for me.
 [2006-10-19 08:32 UTC] lzsiga at freemail dot c3 dot hu
I've just entered a quite long text which somehow vanished in the nowhere (thanks to this advanced and user-friendly bug reporting interface!), the core of it was:

The problem can be fixed easily editing script 'configure' like this:
8777c8777
<     BUILD_CLI="echo '\#! .' > php.sym && echo >>php.sym && nm -BCpg \`echo \$(PHP_GLOBAL_OBJS) \$(PHP_CLI_OBJS) | sed 's/\([A-Za-z0-9_]*\)\.lo/\1.o/g'\` | \$(AWK) '{ if (((\$\$2 == \"T\") || (\$\$2 == \"D\") || (\$\$2 == \"B\")) && (substr(\$\$3,1,1) != \".\")) { print \$\$3 } }' | sort -u >> php.sym && \$(LIBTOOL) --mode=link \$(CC) -export-dynamic \$(CFLAGS_CLEAN) \$(EXTRA_CFLAGS) \$(EXTRA_LDFLAGS_PROGRAM) \$(LDFLAGS) -Wl,-brtl -Wl,-bE:php.sym \$(PHP_RPATHS) \$(PHP_GLOBAL_OBJS) \$(PHP_CLI_OBJS) \$(EXTRA_LIBS) \$(ZEND_EXTRA_LIBS) -o \$(SAPI_CLI_PATH)"
---
>     BUILD_CLI="echo '\#! .' > php.sym && echo >>php.sym && nm -BCpg \`echo \$(PHP_GLOBAL_OBJS) \$(PHP_CLI_OBJS) | sed 's/\([A-Za-z0-9_]*\)\.lo/.libs\/\1.o/g'\` | \$(AWK) '{ if (((\$\$2 == \"T\") || (\$\$2 == \"D\") || (\$\$2 == \"B\")) && (substr(\$\$3,1,1) != \".\")) { print \$\$3 } }' | sort -u >> php.sym && \$(LIBTOOL) --mode=link \$(CC) -export-dynamic \$(CFLAGS_CLEAN) \$(EXTRA_CFLAGS) \$(EXTRA_LDFLAGS_PROGRAM) \$(LDFLAGS) -Wl,-brtl -Wl,-bE:php.sym \$(PHP_RPATHS) \$(PHP_GLOBAL_OBJS) \$(PHP_CLI_OBJS) \$(EXTRA_LIBS) \$(ZEND_EXTRA_LIBS) -o \$(SAPI_CLI_PATH)"
 [2006-10-19 08:45 UTC] tony2001@php.net
>I've just entered a quite long text which somehow vanished
>in the nowhere (thanks to this advanced and user-friendly 
>bug reporting interface!)
Just don't spam the bug tracker with long texts.

File ./configure is autogenerated, so changing it doesn't make any sense.
Please explain what exactly you changed there, the patch is not human readable.

Also, it does work for me without any patches (yes, on AIX), so please make sure (I have to repeat, since you seem to ignore my comments) that you use GNU ld and other GNU build tools.
 [2006-10-19 09:15 UTC] lzsiga at freemail dot c3 dot hu
(> Just don't spam the bug tracker with long texts.
It wasn't _so_ long;) It's just that I first enter the text at in this "Add Comment" dialog, then 'bug.php' regocnizes me and give an other dialog with an empty textarea... but for now, I've found my ^C and ^V keys)

> File ./configure is autogenerated, so changing it doesn't make any sense.
Ok, I've taken a step back, and found file sapi/cli/config.m4 which contains the same (lines 21-24)

> Please explain what exactly you changed there, the patch is not human readable.
Sorry, the changed part was the following: 
-sed 's/\([A-Za-z0-9_]*\)\.lo/\1.o/g'
+sed 's/\([A-Za-z0-9_]*\)\.lo/.libs\/\1.o/g'
 [2006-10-19 09:22 UTC] tony2001@php.net
It does work for me without any patches (yes, on AIX), so please make sure (I have to repeat it 3rd time) that you use GNU ld and other GNU build tools.
 [2006-10-19 12:18 UTC] lzsiga at freemail dot c3 dot hu
At last I saw some improvement,
specifing 'LD=/usr/local/bin/gld' I've found out that

1. You guys are using a very own version of libtool which is generated in configure-time, and -of course- behaves differently when LD is set and when it is not.

2. Specifing both --enable-shared and --disable-static is not enough to get shared libraries (not-setting LD this works automagically).

3. Everything else is perfect
 [2006-10-19 12:26 UTC] tony2001@php.net
No bug -> bogus.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 20:01:28 2024 UTC